JeremyWilliam译者
弯月责编
仲培艺以下为译文：这篇文章的目的是让你开始怀疑你判断哪些是“好”代码哪些是“差”代码的标准。首先，我会剖析当有人说“这些代码很好”时的情况，然后从反向定义“差”代码。当听到有人评价某段代码“很好”时，通常意味着这段代码与他们在职业生涯或教育中形成的原则性的经验相符。每个程序员都有不同的评判标准，而且使用不同编程范式（例如面向对象编程与功能编程）的程序员之间的差异可能非常大。下面会列出一些你听过且深以为然的规则示例：不要使用全局变量不要使用单件重组合轻继承每个方法的参数不应该超过5个函数应该只处理一件事情得墨忒耳定律（最少知识原则，是一个设计指导原则，特别是面向对象的程序）单一责任原则不要自我重复使用目前流行的架构……好的代码常常会教条地遵循这些规则，而任何不遵守这些规则的代码就会被打上“非正规手段”，或“以后需要重构”的标签。与良好的代码相反，差代码是不遵循这些规则的代码。我觉得这是因为我们作为工程师，需要量化事物。我们想要一种可重复的方法来解决所有问题，一种真正的方法，因此我们提出了“好”代码应该遵守的规则。这有什么问题？第一个问题是你无法使用最直接的方式解决问题。你构建了一个限制代码的迷宫，最终只会导致你需要编写更多的代码。编写这样的代码花费的时间更长，因为你不仅需要思考你需要解决的问题，还必须采用满足你对自己施加的众多约束的方式。这就好似把一只手绑在背后写代码。其次，正如我前面所述，最终只会导致你需要编写更多的代码。代码量增大，却无法解决你的问题。这样的代码只是在解决你为自己制造的假问题。这样的代码越多，你就越难以掌握项目的进展状况。为了处理那些本没有必要的代码所产生的问题，你需要添加更多的代码，随着此类代码的增多，代码里的干扰因素会迅速恶化。我曾在尝试遵循某些体系结构或在代码中引入模式时，遇到过一些非常糟糕的类似情况。在我看来，很明显这些“好”代码的规则在人们心目中根深蒂固，以至于人们都不会意识到这些规则的存在。前几天，HackerNews上有一篇这类典型的文章《通过一个玩具示例学习这个架构，它将解决你所有的问题》（