程序员的代码行数越少越好？

点击关注公众号，Java干货及时送达

点击上方 Java技术迷，选择 设为星标

作者 | Ryland Goldstein

译者 | 弯月，责编 | 郭芮

出品 | CSDN（ID：CSDNnews）

代码行数越少越好？读懂别人的代码很困难？如何编写出“完美”的代码？每天要坚持8小时编程？......拜托，这些编程误区程序员应该尽早知道！

以下为译文：

作为开发人员，你会听到许多有关“代码行数”的令人难以置信的疯狂理论——不要相信他们！以代码行数作为决策依据是一件非常荒谬的事情。在极少数情况下，代码行数可能还有那么一丁点意义，在绝大数情况下，代码行数什么都代表不了。根据代码行数做决策就好像按照页数评价书籍的水准。

有些人可能会认为，应用程序中的代码行越少，就越容易阅读。这句话只有部分正确，我认为代码可读性的度量标准包括：

• 代码应具备一致性

• 代码应具备自我描述性

• 代码应具备良好的文档

• 代码应使用稳定的现代功能

• 代码不应过于复杂

• 代码的性能不能有问题（不要故意编写速度过慢的代码）

如果减少代码行数会影响到上面任何一条，那么就有问题。实际上，基本上减少代码行数都会影响到上面的标准，因此总会出问题。不过，如果你能够设法满足上述条件，那么代码行数就是完美的，根本用不着统计数量。

1、语言没有好坏之分

除了PHP（开个玩笑）。

总是有人会说：

“C比X更好，因为C的性能更好。”

“Python比X更好，因为Python更简洁。”

“Haskell比X更好，因为Haskell是外星语言。”

一言以蔽之，比较编程语言本身就是无稽之谈。它们是语言，又不是口袋妖怪。

别误会，语言之间的确有差异，只不过“一无是处”的语言毕竟是少数（尽管有很多过时的语言）。每种语言都有其独特的优点，从这个角度来说，语言就好像工具箱中的工具。螺丝刀能够胜任锤子做不到的事情，但是你会说螺丝刀比锤子好吗？（显然锤子更好使）。

在谈论如何评估语言之前，我想先说明一点。在少数情况下，语言的选择确实很重要，某些语言显然无法处理某些情况。如果你编写前端代码，那么连选择语言的权利都没有。在某些特定的情况下，性能很重要，那么就不能选用X语言了，但这种情况很少见。通常，语言的选择都是项目中最不重要的问题之一。

以下是我认为在选择语言时，你应当考虑的核心因素（优先级从高到低）：

• 在线资源的数量（比如StackOverflow上的问题数量）

• 开发速度

• 出错的概率

• 软件包生态系统的质量和广度

• 性能特征

• 招聘人才的难度（对不起，COBOL）

还有一些无法控制的紧密联系。如果你从事数据科学工作，那么就需要使用Python、R或Scala（也许是Java）。如果是一个业余项目，那么就随心所欲选择自己喜欢的。只有一条规则我觉得没有商量的余地：如果遇到的大多数问题都无法通过StackOverflow直接解决，那么我会拒绝使用这种语言。不是说我没有解决问题的能力，而是我觉得不值得花那么多时间。

2、读懂别人的代码是一件难事

读懂别人的代码是一件困难的事情。Robert C. Martin在“干净的代码”中谈到了这一点：

“实际上，读代码和写代码所花费的时间之比远超过10：1。在编写新代码的时候，我们一直在阅读旧代码。……[因此，]我们的代码应该易于阅读，易于编写。”

很长一段时间里，我一直以为自己不善于阅读别人的代码。随着时间的流逝，我意识到几乎每个程序员每天都在为阅读别人的代码而苦恼。

阅读别人的代码就像学一门外语。即使你很熟悉某种语言，但仍然需要使用别人的不同风格以及体系结构。而且我们一般都会假设写代码的人贯彻了一致性和可靠性，但有时并非如此，这确实是一个很难克服的问题。但是我发现了很多有帮助性的技巧。

阅读别人的代码可以极大地提高你阅读代码的能力。在过去的两年中，我查看了很多Github中的PR。每读一个PR，就会觉得阅读别人代码的能力又提高了一点点。Github中的PR特别具有帮助性，原因如下：

• 可以随时练习，只需找到自己想贡献的开源项目即可。

• 在一定范围内练习阅读别人的代码（功能性的PR或改bug的PR）。

• 注意所需的细节，努力读懂每一行。

还有一种对阅读别人的代码有帮助行的技巧，这种技巧更加独特。我想到的这种技巧可以大幅减少阅读陌生代码库所需的时间。在看到我想阅读的风格的代码后，我首先我会打开vi，然后开始用项目中使用的风格编写代码。这样会减少对代码的陌生感。

3、你永远无法编写出“完美”的代码

在加入团队工作之前，有4年的时间里我这个开发人员都是“独行狼”。在大多数时间里，我会假设每位程序员编写的代码都是完美的。我以为稍加努力和假以时日，我也会编写出“完美”的代码。《Java开发手册（嵩山版）》建议你看下。

以前，我曾经常常为此而感到焦虑。在加入团队后，我很快就发现没人能够编写“完美”的代码。但是，进入系统的代码几乎总是“完美”的，为什么会这样呢？答案就在于代码审查。

我们团队拥有非常出色的工程师。他们都是最有能力，最有信心的程序员。如果有人建议提交未经审查的代码，那么我们团队中的每个成员（包括我）都会群起而攻之。即使你觉得自己是下一个比尔·盖茨，你也会犯错。甚至都无需上升到逻辑上的错误，就连错字、漏字的问题都无法避免，这些都是你的大脑无暇顾及的问题，所以需要由别人来帮你检查。

努力与注重细节并乐于指摘你的代码的人一起工作。虽然刚开始听到批评时，你会觉得很难受，但这是持续改进的唯一方法。尽最大努力避免在代码审查过程中产生抵抗情绪，也不要发表针对个人的评论。努力做到对事不对人。

审核代码时，如果代码的作者做出的选择我并不熟悉，那么我会立即通过Google查看他们的选择是否与流行观点不符。我并不是说流行观点永远是对的，只不过流行观点是默认的选择。如果有人决定不采纳流行的观点，那也很好啊，只不过我需要知道这是否合理。在审查代码时，有一点至关重要：你必须了解决策背后的基本原理。另外，用“初学者的头脑”看同样的问题，往往可以发现被这个人抛诸脑后的东西。

4、程序员的工作并不意味着每天要坚持8个小时的编程

一般的开发人员或“伟大的”开发人员每天需要做多长时间的编程工作呢？这是一个非常普遍的问题，但是从来没有人给出明确的答案。

每天写代码的时间超过4小时的人非常少。

不赞同这一点的人要么是个例外，要么公司应该珍惜他们。编程是一项耗费精力的工作，需要精神高度集中。要求程序员每天写5-8小时的代码是不近人情的做法。在极少数情况下，为了按时完成任务或为了加班费，有人会延长工作时间，但这种情况很少见。其实我这里说的“极少数情况”的意思是几乎没有。如果由于公司计划上的问题或招聘的人手不足而导致你加班，那么请不要容忍。

坦白来说，每天编写8个小时的代码，对你和公司都没有好处。如果你的老板有这种要求，那么只能说他目光短浅，因为从长期来看，这种高强度的工作对生产力和心理健康都有恶劣的影响。

请注意，我并不是建议你每天只工作4个小时。通常，我们应该把剩下的4小时用在如下工作上：

• 研发与工作有关以及无关的主题

• 与同事讨论工作

• 帮助其他努力工作的同事

• 计划未来的工作

• 代码审核

• 开会

除此之外，我强烈建议你在白天的工作时间里定时休息并锻炼身体（即使只是短暂的锻炼）。事实证明，运动对缓解精神疲劳有很大的帮助。我发现，我在无法集中精力的时候，锻炼特别有帮助。

原文：https://stackoverflow.blog/2019/08/07/what-every-developer-should-learn-early-on/

往
期
推
荐
1、灵魂一问：你的登录接口真的安全吗？
2、HashMap 中这些设计，绝了~
3、在 IntelliJ IDEA 中这样使用 Git，贼方便了！
4、计算机时间到底是怎么来的？程序员必看的时间知识！
5、这些IDEA的优化设置赶紧安排起来，效率提升杠杠的！
6、21 款 yyds 的 IDEA插件
7、真香！用 IDEA 神器看源码，效率真高！
点分享
点收藏
点点赞
点在看