好代码的科学定义

    英文原文： What is good code? A scientific definition.

你如何定义好的代码？本文通过咨询 65 个开发人员同一个问题从而得出了一个伪科学的答案。

首先我们相信写好代码是非常重要的。为什么呢？首先，好代码比差代码更有趣，成本更低。其次，代码好，就意味着你正在构建的产品有可能会更好。第三，也是非常关键的一点，写出好的代码是我们的职责：毕竟，我们的工作就是写代码。

方法

由于此 65 名开发人员都是我们某个职位的应聘者，所以这意味着这些样品开发人员大多偏向于使用 Java 或 Scala 技能，并且通常有着 5 年及以上的工作经验。

问题统一：“怎样写好代码？你如何定义好代码？”并且在面试时由同一人（面对面或通过电话），历时约 1 年，从 2014 年 1 月至 2015 年 1 月，来执行此地调查。

梳理这些问题的答案之后，可以分为 31 个不同的类，每组至少有 2 个相似的答案。例如，下面这些答案通通归纳为可读一类：

可读。

• 人脑可阅读。
• 能自我解释。
• 人们能读懂。
• 很容易理解。
• 不用 5 分钟就能了解。
• 没有文档，你也可以阅读并理解。
• 可读，新来的开发人员也能够理解。
• 就如同文本一样可读。
• 易于阅读，直线化的思维。

结果

这 65 位开发人员的答案总共统计出 288 条不同的内容，平均一个人 4.43 条。

当然，目前最常见的答案是，代码必须可读（78.46％），几乎 10 分之 8 的开发人员认为，好的代码应该易于阅读和理解。

然后是可测试的/测试过的（29.23％），这说明好的代码应当是经过自动化测试的（或至少是有可能执行测试的）。25% 的受访者认为，良好的代码还应该是简单的——不过于复杂，当然还应该是可以工作的，意味其能够按照我们的意愿正常执行功能。前五条是，代码应该是可维护的 （21.54％）。

奇怪的是，我们发现有两项内容是关于同一主题的：文档和代码注释。有的开发人员认为代码应该自文档化（不需要用文档解释），而有些开发人员则表示应该在代码中着重于注解，说明代码目的。

其他的，如，可扩展的/可重复使用的，恰当的命名规律，代码解耦或者称为小方法的重要性——当然这个“小”在不同开发人员的眼中概念还不一样：“10-15 行”到“<50 行”莫衷一是。

探讨

面试中的回答给了我们很多有趣的可用于分析的定量数据，而有些数据非常值得一提。下面这些是我们点赞量最多的答案，有的让我们会心一笑，有的有理有据值得深思：

• 再怎么测试也不会发生崩溃。
• 不要创建那些并不需要的玩意儿。
• 任何人都需要写点注释。好不好以后自然会知道。
• 你看到它，它才有意义。
• 你需要了解业务目的。
• 你需要做的不仅仅是写代码。
• 不需要太过于特立独行。
• 差的代码也能做很多事情，但就是通通做不好。

开发人员重视代码的可读性和可理解性并不奇怪。但是令人有一点点惊讶的是，其余的回答却差不多至少有 50％ 的差异！

以下这四条就属于让人惊讶的后者：

• 可维护：因为我们大多数人都有过维护别人代码的经历（或者一段时间以后维护自己的代码），并且很有可能度过了一段非常悲惨的日子。所以，我们期待更多的开发人员能够编写出可维护的代码。可能有的人假设代码可读，那么一定易于维护，所以就忽略了这一条。
• 可工作：编写代码的目的，就是能够为他人提供价值。编写可工作的代码，是我们的首要任务之一。所以我们很惊讶为什么并不是每一个开发人员的答案中都囊括这一条。
• 可测试/已测试过的：测试的重要性在这里我就不多说了，相信大家已经听到过不知道几百遍了。
• 高效：话说，答案中包含“高效”的开发人员比强调“不可过早优化”的开发人员，要多两倍，而众所周知，“过早的优化是万恶之源”，所以，这太让人纳闷了。

最后，我们总结出好代码的定义：

“好的代码是可读的，可理解的，覆盖了自动化测试的，不过于复杂，并且能办好我们需要它做的事情。”

听起来就相当美，right？

译文链接：http://原网站已经失效/article/what-is-good-code.html
翻译作者：码农网 – 小峰