作者 | Ryland Goldstein
译者 | 弯月，责编 | 郭芮
出品 | CSDN（ID：CSDNnews）
以下为译文：
作为开拓职员，你会听到许多有关“代码行数”的令人难以置信的猖獗理论——不要相信他们！
以代码行数作为决策依据是一件非常荒谬的事情。在极少数情形下，代码行数可能还有那么一丁点意义，在绝大数情形下，代码行数什么都代表不了。根据代码行数做决策就彷佛按照页数评价书本的水准。
有些人可能会认为，运用程序中的代码行越少，就越随意马虎阅读。这句话只有部分精确，我认为代码可读性的度量标准包括：
代码应具备同等性
代码应具备自我描述性
代码应具备良好的文档
代码应利用稳定的当代功能
代码不应过于繁芜
代码的性能不能有问题（不要故意编写速度过慢的代码）
如果减少代码行数会影响到上面任何一条，那么就有问题。实际上，基本上减少代码行数都会影响到上面的标准，因此总会出问题。不过，如果你能够设法知足上述条件，那么代码行数便是完美的，根本用不着统计数量。
措辞没有好坏之分
除了PHP（开个玩笑）。
总是有人会说：
“C比X更好，由于C的性能更好。”
“Python比X更好，由于Python更简洁。”
“Haskell比X更好，由于Haskell是外星措辞。”
一言以蔽之，比较编程措辞本身便是无稽之谈。它们是措辞，又不是口袋妖怪。
别误会，措辞之间的确有差异，只不过“一无是处”的措辞毕竟是少数（只管有很多过期的措辞）。每种措辞都有其独特的优点，从这个角度来说，措辞就彷佛工具箱中的工具。螺丝刀能够胜任锤子做不到的事情，但是你会说螺丝刀比锤子好吗？（显然锤子更好使）。
在评论辩论如何评估措辞之前，我想先解释一点。在少数情形下，措辞的选择确实很主要，某些措辞显然无法处理某些情形。如果你编写前端代码，那么连选择措辞的权利都没有。在某些特定的情形下，性能很主要，那么就不能选用X措辞了，但这种情形很少见。常日，措辞的选择都是项目中最不主要的问题之一。
以下是我认为在选择措辞时，你应该考虑的核心成分（优先级从高到低）：
在线资源的数量（比如StackOverflow上的问题数量）
开拓速率
出错的概率
软件包生态系统的质量和广度
性能特色
招聘人才的难度（对不起，COBOL）
还有一些无法掌握的紧密联系。如果你从事数据科学事情，那么就须要利用Python、R或Scala（大概是Java）。如果是一个业余项目，那么就为所欲为选择自己喜好的。只有一条规则我以为没有商量的余地：如果碰着的大多数问题都无法通过StackOverflow直接办理，那么我会谢绝利用这种措辞。不是说我没有办理问题的能力，而是我以为不值得花那么多韶光。
读懂别人的代码是一件难事
读懂别人的代码是一件困难的事情。Robert C. Martin在“干净的代码”中谈到了这一点：
“实际上，读代码和写代码所花费的韶光之比远超过10：1。在编写新代码的时候，我们一贯在阅读旧代码。……[因此，]我们的代码该当易于阅读，易于编写。”
很长一段韶光里，我一贯以为自己不长于阅读别人的代码。随着韶光的流逝，我意识到险些每个程序员每天都在为阅读别人的代码而苦恼。
阅读别人的代码就像学一门外语。纵然你很熟习某种措辞，但仍旧须要利用别人的不同风格以及体系构造。而且我们一样平常都会假设写代码的人贯彻了同等性和可靠性，但有时并非如此，这确实是一个很难战胜的问题。但是我创造了很多有帮助性的技巧。
阅读别人的代码可以极大地提高你阅读代码的能力。在过去的两年中，我查看了很多Github中的PR。每读一个PR，就会以为阅读别人代码的能力又提高了一点点。Github中的PR特殊具有帮助性，缘故原由如下：
可以随时练习，只需找到自己想贡献的开源项目即可。
在一定范围内练习阅读别人的代码（功能性的PR或改bug的PR）。
把稳所需的细节，努力读懂每一行。
还有一种对阅读别人的代码有帮助行的技巧，这种技巧更加独特。我想到的这种技巧可以大幅减少阅读陌生代码库所需的韶光。在看到我想阅读的风格的代码后，我首先我会打开vi，然后开始用项目中利用的风格编写代码。这样会减少对代码的陌生感。纵然我在Github上浏览随机项目，我也会这样做。一起来试试看吧。
你永久无法编写出“完美”的代码
在加入团队事情之前，有4年的韶光里我这个开拓职员都是“独行狼”。在大多数韶光里，我会假设每位程序员编写的代码都是完美的。我以为稍加努力和假以时日，我也会编写出“完美”的代码。
以前，我曾经常常为此而感到焦虑。在加入团队后，我很快就创造没人能够编写“完美”的代码。但是，进入系统的代码险些总是“完美”的，为什么会这样呢？答案就在于代码审查。
我们团队拥有非常出色的工程师。他们都是最有能力，最有信心的程序员。如果有人建议提交未经审查的代码，那么我们团队中的每个成员（包括我）都会群起而攻之。纵然你以为自己是下一个比尔·盖茨，你也会犯错。乃至都无需上升到逻辑上的缺点，就连错字、漏字的问题都无法避免，这些都是你的大脑无暇顾及的问题，以是须要由别人来帮你检讨。
努力与看重细节并乐于指摘你的代码的人一起事情。虽然刚开始听到批评时，你会以为很难熬痛苦，但这是持续改进的唯一方法。尽最大努力避免在代码审查过程中产生抵抗感情，也不要揭橥针对个人的评论。努力做到对事不对人。
审核代码时，如果代码的作者做出的选择我并不熟习，那么我会立即通过Google查看他们的选择是否与盛行不雅观点不符。我并不是说盛行不雅观点永久是对的，只不过盛行不雅观点是默认的选择。如果有人决定不采纳盛行的不雅观点，那也很好啊，只不过我须要知道这是否合理。在审查代码时，有一点至关主要：你必须理解决策背后的基本事理。其余，用“初学者的头脑”看同样的问题，每每可以创造被这个人抛诸脑后的东西。
程序员的事情并不虞味着每天要坚持8个小时的编程
一样平常的开拓职员或“伟大的”开拓职员每天须要做多永劫光的编程事情呢？这是一个非常普遍的问题，但是从来没有人给出明确的答案。
每天写代码的韶光超过4小时的人非常少。
不赞许这一点的人要么是个例外，要么公司该当珍惜他们。编程是一项耗费精力的事情，须要精神高度集中。哀求程序员每天写5-8小时的代码是不近人情的做法。在极少数情形下，为了按时完成任务或为了加班费，有人会延长事情韶光，但这种情形很少见。实在我这里说的“极少数情形”的意思是险些没有。如果由于公司操持上的问题或招聘的人手不敷而导致你加班，那么请不要容忍。
坦白来说，每天编写8个小时的代码，对你和公司都没有好处。如果你的老板有这种哀求，那么只能说他目光短浅，由于从长期来看，这种高强度的工为难刁难生产力和生理康健都有恶劣的影响。
请把稳，我并不是建议你每天只事情4个小时。常日，我们该当把剩下的4小时用在如下事情上：
研发与事情有关以及无关的主题
与同事谈论事情
帮助其他努力事情的同事
操持未来的事情
代码审核
开会
除此之外，我强烈建议你在白天的事情韶光里定时安歇并磨炼身体（纵然只是短暂的磨炼）。事实证明，运动对缓解精神疲倦有很大的帮助。我创造，我在无法集中精力的时候，磨炼特殊有帮助。
原文：https://stackoverflow.blog/2019/08/07/what-every-developer-should-learn-early-on/
本文为 CSDN 翻译，转载请注明来源出处。
【END】
