上大学时就该学会的那些软件开发真理

很多开发者在编程多年以后，总是在实际工作的惨痛教训中学会了一些本该在大学时期就掌握的软件开发真理。我太难了，早干嘛去了……

不要太在意“代码行数”

你可能听到过很多有关“代码行数”的疯狂理论，但请不要把它们当真。基于代码行数来做技术决策是一件很荒谬的事情。代码行数能够为我们提供的信息是很有限的。实际上，在大多数情况下，代码行数能够为我们提供的信息为零。基于代码行数来做技术决策无异于基于一本书的页数来判断书的质量。

有人认为，项目的代码越少就越容易读懂，但这个观点只说对了一部分。我认为，具有可读性的代码应该具备以下这些特点：

• 一致性；

• 自描述；

• 良好的文档；

• 使用了稳定的特性；

• 不会太复杂；

• 性能不会太差。

如果为了减少代码行数而破坏了这些原则，那才是问题。事实上，如果你尽量去遵循这些原则，代码行数自然会处在一个很完美的位置，根本不需要特意去计算究竟有多少行代码。

不一定要把编程语言分出“好坏”

人们经常会这样说：

C 语言比某某语言好，因为它的性能更好。

Python 比某某语言好，因为它更简洁。

Haskell 比某某语言好，因为它是异类。

使用一句话来评判和比较一门编程语言是对语言本身的侮辱。它们是编程语言，可不是什么口袋精灵。

编程语言之间确实存在差别，而且很少存在“没有用”的编程语言（除了那些过时或者已经死掉的语言）。每一门编程语言都在某些方面做出了权衡，它们就像工具箱里的工具。起子可以做锤子做不到的事情，但你能说起子比锤子更好吗？

在说出我的编程语言评判标准之前，需要先澄清一个问题。编程语言的选择很少会对一个项目起到实质性的作用。如果你写的是前端代码，选择不会太多，但通常来说，编程语言的选择只是决定项目成败的一个不那么重要的因素。

以下是我认为在选择编程语言时需要考虑的一些因素（已经排好序了）：

• 是不是有很多相关教程；

• 开发速度；

• 出现 bug 的几率；

• 库生态系统的质量和广度；

• 性能；

• 好不好招人。

不过，有一些场景是你无法掌控的。例如，如果你是一名数据科学家，那可能就得用 Python 、 R 语言或 Scala 。如果只是一个个人项目，那完全可以选择使用你喜欢的编程语言。我在选择编程语言时只有一条原则：如果 StackOverflow 上与这门语言相关的问题不多，我就不会使用这门语言。并不是说遇到问题自己解决不了，而是因为花太多时间在这些问题上面不值得。

阅读别人的代码是个麻烦事

阅读别人的代码其实并非易事。Robert Martin 在《整洁代码之道》里提到过这个问题：

事实上，人们花在阅读代码和花在写代码上的时间比率超过了 10 比 1。阅读旧代码是写新代码的一个组成部分……所以，容易读懂的代码会让写新代码的工作变得更容易些。

有很长一段时间，我被阅读别人的代码这件事所困扰。后来发现，其实有很多人都跟我一样，每天都要面对这个问题。阅读别人的代码就像是在阅读一本用外文写的书，即使代码是用你熟悉的语言写的，代码的风格和架构仍然会不一样。这个问题不太好解决，不过我发现下面这些做法可能会对你有所帮助。

评审别人的代码有助于提升阅读代码的能力。在过去两年中，我评审了很多 GitHub PR。每评审完一个 PR，我就越能够适应阅读别人的代码。GitHub PR 很适合用来提升代码阅读能力，因为：

• 随时都可以评审，只要找到你想加入的开源项目；

• 在划定的范围内进行练习（一个功能、一个 bug）；

• 需要专注细节，迫使你仔细查看每一行代码。

第二种方式有点特别，这也是我一直在践行的，可以帮我节省很多时间。在了解了某个项目的代码风格之后，就用这种风格来写代码，这样可以提升阅读这种风格代码的能力。因为你已经体验过类似的风格，所以再去阅读这样的代码就不会感到陌生。

不要试图写出“完美”的代码

在加入团队工作之前，我做了 4 年的“独行侠”。那个时候，我以为每一个程序员都会写出完美的代码，而写出“完美”的代码是需要付出时间和努力的。

我曾经为此感到焦虑，但在加入了团队之后，我才发现，没有人会写“完美”的代码。但为什么进入到生产环境的代码总是那么“完美”呢？答案是：代码评审。

我所在的团队里有很多聪明人，他们都是很有能力且自信的程序员。如果有人胆敢提交未经评审的代码，他们一定不会善罢甘休。即使你觉得自己是下一个比尔盖茨，也无法避免犯错。我说的不单单是逻辑错误，还包括拼写错误、丢字符之类的。

争取与那些愿意跟你抠细节和给你意见的人合作。忠言逆耳，但这也是提升自己的一条路径。在接受代码评审时要虚心，不要把它跟个人联系在一起。别人评审的是你的代码，而不是针对你。

在评审别人的代码时，我会用谷歌搜索解决方案，看看代码的解决方案与流行的解决方案有什么不一样的地方。通常，抱着“初学者”的心态会发现更多别人发现不了的问题。

程序员并非无时不刻都在写代码

这是个很普遍的问题，但从来没有人能够给出一个明确的答案。

很少有人每天写代码的时间会超过 4 个小时。

如果有人不是这样的，那说明他们的公司应该对他们更好一些。编程是一项很耗费脑力的活动，一个人一周 5 天、每天 8 个小时都在写代码是完全不合理的，除非是为了赶进度，但这种情况不应该是常态。如果一家公司因为管理上的问题或者不想招更多的人而让你加班，你就没必要容忍！

其次，即使你每天花 8 个小时写代码，对你的公司来说也不一定有好处。你的老板可能会认为这样子很好，但其实这是一种短视，因为从长远来看，这样做会影响到生产力和员工的健康。

需要说清楚的是，我并不是建议你每天只工作 4 个小时。另外的 4 个小时你还需要：

• 做调研；

• 与同事讨论；

• 帮助别人解决问题；

• 计划未来的工作；

• 参加代码评审；

• 开会。

我个人强烈建议每天都要定时休息，做一些运动，哪怕是简单的运动。我发现，运动有助于缓建精神压力，帮你更好地集中精神。

原文链接

https://dev.to/taillogs/what-developers-should-actually-learn-in-college-2ne