@程序员，多写点“坏”代码吧！

何为好代码？又何为坏代码？代码好坏的界限真的有那么明确吗？

与其固守于所谓好代码的“条条框框”，不若走出好坏的边界，拥抱简洁又直击功能需求的“坏”代码吧！

作者 | Jeremy William

译者 | 弯月

责编 | 仲培艺

出品 | CSDN（ID：CSDNNews）

以下为译文：

这篇文章的目的是让你开始怀疑你判断哪些是“好”代码哪些是“差”代码的标准。首先，我会剖析当有人说“这些代码很好”时的情况，然后从反向定义“差”代码。

当听到有人评价某段代码“很好”时，通常意味着这段代码与他们在职业生涯或教育中形成的原则性的经验相符。每个程序员都有不同的评判标准，而且使用不同编程范式（例如面向对象编程与功能编程）的程序员之间的差异可能非常大。下面会列出一些你听过且深以为然的规则示例：

• 不要使用全局变量

• 不要使用单件

• 重组合轻继承

• 每个方法的参数不应该超过 5 个

• 函数应该只处理一件事情

• 得墨忒耳定律（最少知识原则，是一个设计指导原则，特别是面向对象的程序）
  

• 单一责任原则

• 不要自我重复

• 使用目前流行的架构

• ……

好的代码常常会教条地遵循这些规则，而任何不遵守这些规则的代码就会被打上“非正规手段”，或“以后需要重构”的标签。与良好的代码相反，差代码是不遵循这些规则的代码。

我觉得这是因为我们作为工程师，需要量化事物。我们想要一种可重复的方法来解决所有问题，一种真正的方法，因此我们提出了“好”代码应该遵守的规则。

这有什么问题？第一个问题是你无法使用最直接的方式解决问题。你构建了一个限制代码的迷宫，最终只会导致你需要编写更多的代码。编写这样的代码花费的时间更长，因为你不仅需要思考你需要解决的问题，还必须采用满足你对自己施加的众多约束的方式。这就好似把一只手绑在背后写代码。

其次，正如我前面所述，最终只会导致你需要编写更多的代码。代码量增大，却无法解决你的问题。这样的代码只是在解决你为自己制造的假问题。这样的代码越多，你就越难以掌握项目的进展状况。为了处理那些本没有必要的代码所产生的问题，你需要添加更多的代码，随着此类代码的增多，代码里的干扰因素会迅速恶化。我曾在尝试遵循某些体系结构或在代码中引入模式时，遇到过一些非常糟糕的类似情况。

在我看来，很明显这些“好”代码的规则在人们心目中根深蒂固，以至于人们都不会意识到这些规则的存在。前几天，Hacker News 上有一篇这类典型的文章《通过一个玩具示例学习这个架构，它将解决你所有的问题》（http://iolivia.me/posts/24-hours-of-rust-game-dev/），文章说的是实体组件系统（ECS）。Jon Blow 在评论中指出这个实体组件系统完全没有必要，我们完全可以通过显而易见的方式编写代码，来更好地解决这个问题。我想通过这个例子来说明“好”代码给人们带来的心理枷锁：

很显然，我猜你会只选择单一类型的'实体'，并且将所有实体放在同一个数组中？虽然这种方式对你来说可能是显而易见的，但对于很多（包括我自己）在面向对象以及对现实世界的抽象和建模行为中成长起来的程序员来说，这并没有那么明显。

人们已经被灌输了对“好”代码的崇拜，他们甚至无法理解直截了当的代码。抛开对象和现实世界建模，他们就无法思考编程。让他们摆脱“好”代码束缚的唯一方法是将他们当前的规则换成另一个。你不需要实体组件就可以访问数据，你不需要遵循一开始就被隐藏了起来的规则。编写解决方案的显而易见的方式是什么？这不存在什么技巧，只需要编写出你所需功能的代码，编写可以完成工作的代码。实体与解决问题无关，我可以向你保证，《超级马里奥兄弟》的代码中没有实体的概念。

下面是一些“差”代码：

void jump() {
  mario.yvel = 10;
}

我猜你脑子里肯定响起了警钟：“如果是马里奥之外的其他东西需要跳呢？”或者“马里奥是全局变量吗？如果我需要多个马里奥该怎么办？”这些事都无关紧要。这段代码解决了我想解决的问题，马里奥需要跳起来。不是那个我没有的马里奥，也没有多个马里奥，以及马里奥之外的其他东西需要跳起来。不要想着解决你没有的问题，解决你所面临的问题，如果我确实需要多个马里奥，那么我可以以后再改代码，这也没什么大不了。这些“差”代码可能更短，更切中要害。

写差代码，不用担心其余的代码。忘记所有规则，你只需要编写代码来完成任务，解决你的实际问题，而不是让其他人告诉你将来可能出现的问题。有时你会写一个很大的 Switch 语句，因为这是最明显的解决问题的方法，那么就用 Switch 好了，不要浪费时间思考一种“更好”或“优雅”的方法。当你面对真正的维护困难时，可以写 abstraction，但是要写一些不需要“架构”的小型 abstraction。

我们编写软件是为了解决问题。如果你编写的代码并没有解决你需要解决的问题，而是为了解决你强加给自己的问题，那么请考虑编写一些差代码。也许你会成为令人刮目相看的 10x developer（10 倍效率的开发者）。

原文：http://www.oop.wtf/write-bad-code

作者：Jeremy William，软件开发。

本文为 CSDN 翻译，如需转载，请注明来源出处。

---

 热 文 推 荐 

System.out.println("点个在看吧！");
console.log("点个在看吧！");
print("点个在看吧！");
printf("点个在看吧！\n");
cout << "点个在看吧！" << endl;
Console.WriteLine("点个在看吧！");
Response.Write("点个在看吧！");
alert("点个在看吧！")
echo "点个在看吧！"

点击阅读原文，输入关键词，即可搜索您想要的 CSDN 文章。

喜欢就点击“在看”吧！