所有开发人员在大学都应该学习的东西

忘记“代码行”

作为一名开发人员，你会听到很多关于“代码行数”含义的疯狂、难以置信的理论。千万别相信这些理论。代码行数是一个荒谬的决策指标。在极少数情况下，它能说明一些问题，而在所有其他情况下，它什么都说明不了。用代码行数来做决策，就像用页数来评价书籍的质量一样。

有些人可能会认为，应用程序中的代码行数越少，就越容易阅读。这种说法并不完全正确，我衡量代码可读性的指标是：

• 代码应该一致
• 代码应该是自描述的
• 代码应该有详细的文档
• 代码应该利用稳定的现代特性
• 代码不应该过于复杂
• 代码不应该性能低下（不要故意编写缓慢的代码）

一旦减少代码行数与上述任何一项相冲突，就会出现问题。实际上，它几乎总是会干扰，因此几乎总是会成为问题。但问题是，如果你努力满足上述标准，你的代码行数将是完美的，无需计数。

语言不一定有“好”或“坏”

我看到人们经常说这样的话：

C 比 X 更好，因为性能

Python 比 X 更好，因为简洁

Haskell 比 X 更好，因为外星人

把语言的比较简化成一句话，这种想法简直是侮辱。它们是语言，不是宝可梦。

别误会，不同语言之间确实存在差异。只是“不可用”的语言很少（尽管有很多过时/已消亡的语言）。每种语言都有其独特的权衡利弊。从这个角度来看，语言就像工具箱里的工具。螺丝刀能做到锤子做不到的事情，但你会说螺丝刀比锤子好吗？

显然锤子更好

在谈论我如何评估语言之前，我想先明确一点。语言选择真正重要的情况非常少。有些事情显然无法用某些语言实现。如果你写前端代码，你就没有语言选择的权利。但总的来说，语言选择通常是项目最不重要的问题之一。

以下是我认为应该决定您选择的语言的核心方面（按顺序排列）（这些是它的 Pokemon 统计数据）

• 可用在线资源的密度（StackOverflow 密度）
• 发展速度（呜呜）
• 漏洞易发性（呃）
• 软件包生态系统的质量和广度（是的，npm，它说的是质量）
• 性能特征（更多点）
• 可雇佣性（抱歉，COBOL）

还有一些强耦合是你无法控制的。如果你从事数据科学工作，你实际上需要使用 Python、R 或 Scala（或许还有 Java）。如果这是一个业余项目，那就用任何让你感觉最开心的语言吧。我只有一个不可妥协的规则：我拒绝使用那些我遇到的大多数问题没有在 StackOverflow 上直接解决的语言。不是我解决不了，只是不值得花时间。

阅读别人的代码很难

阅读别人的代码很困难。Robert C. Martin 在《代码整洁之道》一书中谈到了这一点：

事实上，阅读与写作所花费的时间比例远远超过 10:1。我们不断地阅读旧代码，作为编写新代码的努力的一部分。……[因此]使其易于阅读，使其更容易编写。

很长一段时间以来，我都以为自己很不擅长阅读别人的代码。随着时间的推移，我意识到这几乎是每个程序员每天都在面对的问题。阅读别人的代码几乎就像阅读一门外语。即使你对作者选择的编程语言感到满意，你仍然需要适应不同的风格和架构选择。这还假设作者编写的代码是一致且可靠的，而代码的质量可能参差不齐。这是一个很难克服的问题。我发现有一些方法非常有帮助。

审查其他人的代码将极大地提高你的代码阅读能力。在过去的两年里，我审查了不少 Github PR。每审查一次 PR，我都会感觉阅读其他人的代码更加得心应手。Github PR 之所以如此重要，是因为：

• 可以随时练习，只需找到您想要贡献的开源项目即可。
• 在一定范围内练习阅读（驱动特性或 PR 的错误）。
• 需要注意细节，这将迫使您评估每一行。

第二个技巧可以帮助你阅读别人的代码，它有点独特。这是我自己发明的，它确实减少了我适应陌生代码库所需的时间。在了解了我想要阅读的代码风格后，我会先打开 vi，开始用项目使用的风格编写代码。当你用新的风格编写代码时，你的阅读能力也会提高。这种风格会让你感觉不那么陌生，因为你已经真正体验过了。即使我只是在 Github 上浏览一个随机项目，我也会快速地这样做。试试吧。

你永远写不出“完美”的代码

在加入团队之前，我曾做过四年的“独狼式”开发者。在那段时间的大部分时间里，我都假设业内每个程序员都能写出完美的代码。我想我写出“完美”代码只是时间和精力的问题。我以前总是
为此焦虑。但加入团队后，我很快就发现没有人能写出“完美”的代码。但进入系统的代码几乎总是“完美”的，这是怎么回事呢？答案就是代码审查。

我和一支才华横溢的工程师团队共事。他们都是金钱能买到的最有能力、最自信的程序员。我们团队的每个成员（包括我自己）一旦有人提议提交未经审查的代码，都会惊慌失措。即使你认为自己是下一个比尔·盖茨，你也会犯错。我说的甚至不是逻辑错误，而是拼写错误、字符缺失。你的大脑会走神，永远无法察觉这些错误。你需要另一双眼睛来审视这些错误。

努力与那些注重细节并愿意批评你工作的人一起工作。一开始听取批评可能会很困难，但这是唯一持续改进的方法。在代码审查期间，尽量不要采取防御态度，也不要把任何评论当成针对你个人的。你的代码不是你自己的。

当我审查别人的代码时，我会用谷歌搜索他们做的每一个选择，看看是否与主流观点不同。很多时候，用“初学者的心态”审视同一个问题，就能发现一些别人可能永远不会回头去看的东西。

程序员的工作并不意味着每天编程 8 小时

这是一个非常常见的问题，但人们似乎从未给出明确的答案。

很少有人每天写代码超过 4 个小时

不同意这一点的人要么是例外，要么就是所在公司应该对他们更好一些。编程是一项耗费脑力、需要高度集中注意力的工作。要求一个人每周5天、每天8小时写代码是完全不合理的。偶尔也需要赶截止日期或加班，但这种情况很少见。我说的“很少”，是指几乎从未发生过。不要容忍一个因为计划不周或招聘不足而虐待你、让你加班的工作场所。

需要说明的是，你每天花 8 个小时积极地编程甚至不符合公司的最佳利益。你的老板或许会这么想，但这种做法是短视的，而且忽视了对生产力和心理健康的长期影响。

需要说明的是，我并不是建议你每天只工作四个小时。另外四个小时通常可以这样安排：

• 研究工作相关和不工作相关的主题
• 与同事讨论你的工作
• 帮助那些在工作中遇到困难的同事
• 规划未来的工作
• 代码评审
• 会议

我还强烈建议您在白天定期休息，并进行锻炼（即使只是短暂的）。运动对缓解精神疲劳的益处已得到充分证实。我个人发现，当我难以集中注意力时，运动尤其有帮助。

更新：/u/terriblesarcasm 建议我添加“开发人员在不编程的 4 小时内应该做什么”这个主题。我添加了一个部分来专门讨论这个问题。

结论

这些是我希望大学里教的东西，而不是纯理论。在写这篇文章的过程中，我还想到了许多其他点子，但这些必须在下一篇文章里再说！