2021-09-26

编写好代码的 10 条原则

---

将一个领域的想法、原则和概念应用到另一个领域总是很有趣的。尤其是当这两个领域非常不同时。

例如，软件和产品设计在表面上看起来非常不同。虽然前者被认为是关于纯粹的数学理性，但后者至少在表面上是关于情感、心理学的，即关于理解人类思想和物理世界的混乱。

真的吗？我不这么认为。代码主要是为人类阅读而编写的 [1]。代码通常还修复来自物理世界的问题，因此继承了它的一些非理性。

那么，如果我们将最受推崇的设计师原则之一应用到代码中会发生什么？也就是说，Dieter Rams 的十项优秀设计原则[2] 如何使我们能够编写更好的代码？

好代码就是创新

无论如何，进步的可能性都没有用尽。技术发展总是为原创设计提供新的机会。但富有想象力的设计总是随着技术的进步而发展，它本身永远不会成为目的。

我们的代码正在解决的一些问题非常古老（例如在城市中移动人员）。我们如何使用软件和机器的能力来更好地解决这些问题？即使我们已经在使用计算机（例如扫描签名的文件），我们如何使用它们更进一步（例如要求电子签名），为最终用户提供更好的体验？

即使您拥有一个在今天被认为非常具有创新性的成熟产品，您仍然受制于一个超越您的新竞争对手。科技行业充满了这样的例子。保持成功的公司是那些不害怕通过技术创新不断破坏自己的公司。

好的代码使产品有用

购买产品是为了使用。它不仅要满足功能性标准，还要满足心理和审美标准。好的设计强调产品的实用性，同时忽略任何可能有损它的东西。

编写代码以供使用。正如我在我们不应该发布代码中所写的那样，我们不会为了编码而编码。我们编码是因为这样可以解决很多问题。

因为代码是一种智力产品，它的可用性需要更加关注。前端接口和后端 API 需要提供良好的可供性，即它们的能力对用户来说是不言而喻的。

使用帕累托原则在这里很有用：代码库应该专注于有问题的问题，其 LOC 的 80% 以上与业务问题有关。否则，这些其他功能需要放在图书馆或其他服务中。

好的代码是审美的

产品的美学品质是其实用性不可或缺的一部分，因为产品每天都在使用，并且会对人们及其福祉产生影响。只有制作精良的物品才能美丽。

请注意，虽然这显然适用于 Web 界面或移动应用程序的界面，但它也适用于后端 API。

由于编写代码的目的主要是供人类阅读，因此它没有理由不能从文学中汲取灵感。描述如何使代码在美学上令人愉悦将需要更长的博客文章，但这里有一些想法：

• 代码风格的一致性
• 结构显示思路清晰
• 缺少 cruft ( TODO, FIXME, 等)
• 注释的正字法和语法
• 恰当的命名
• 代码、注释、命名、功能的简洁性
• 概念和例程的可重用性

好的代码使产品易于理解

它阐明了产品的结构。更妙的是，它可以利用用户的直觉使产品清楚地表达其功能。充其量，它是不言自明的。

最重要的是，代码有偏离业务现实的趋势。这是一种技术债务。当代码中使用的抽象不能映射物理世界的现实时，它们需要重构。

识别代码何时妨碍产品的可理解性的一种好方法是对其进行记录。如果你发现自己不得不给出太多关于代码和现实如何不同的上下文，那么这意味着可以改进代码。

文档有过时的趋势，所以如果你需要投入一些时间，投资它来重构代码可能更安全（趁着改进产品的机会，为了重构而重构很少能带来足够的价值) 使其更具自我记录性。

好的代码不引人注目

实现某种目的的产品就像工具。它们既不是装饰品也不是艺术品。因此，他们的设计应该既中性又克制，为用户的自我表达留出空间。

代码可以走得太远。过度使用抽象（这是一篇关于Go 是一种反抽象语言的有趣文章），使用花哨的数据结构，过于复杂的库（例如，在不需要的地方使用 ORM），重新发明轮子：所有这些都会妨碍拥有实际可维护的代码。

这是我在马斯洛的代码审查金字塔中提出的另一点。为了优雅而以牺牲正确为代价而优雅的代码只是碍手碍脚，应该重构或删除。

好的代码是诚实的

它不会使产品比实际情况更具创新性、功能性或价值。它不会试图用无法兑现的承诺来操纵消费者。

过度设计解决方案是一种非常强大的诱惑。即使一家公司的发展速度非常快，而且似乎离过度设计还很远，它仍然可能投资于错误的领域：过早地投资错误的工具，在有更好的现成产品时从头开始构建 -货架替代品等

好的代码是持久的

它避免时尚，因此永远不会显得过时。与时尚的设计不同，它可以持续很多年——即使在今天的一次性社会。

与任何其他领域相比，软件开发受到短期编程库、框架、模式的困扰。选择经过实战考验的解决方案，并在技术选择上保持保守。

编写测试，以便在未来的维护者没有得到有关它的明确反馈的情况下无法删除和更改功能。

好的代码是彻头彻尾的细节

没有什么是武断的或任凭偶然发生的。设计过程中的细心和准确性体现了对用户的尊重。

需要考虑边缘情况，而不是过度设计。虽然在构建 MVP 时牺牲某些用例是可以的，但这并不是让最终产品令人愉悦的原因。当代码优雅地考虑所有边缘情况时（例如，通过使用诸如strategy 之类的模式），维护很容易并且可以在边缘情况出现时进行修复，从而带来惊人的用户体验。

此外，代码是不够的。有很多围绕代码的上下文需要存在：

• 文档
• 监控（运营和业务监控）
• 警报
• 测试（单元、集成、端到端、容量）
• 日志记录和内省和调试的能力

好的代码是环保的

设计对保护环境做出了重要贡献。> 它在产品的整个生命周期内节约资源并最大程度地减少物理和视觉污染。

代码消耗电力，这是有限的资源。当代码变得更高效时，它不仅会对客户产生影响，还会对环境产生影响。

好的代码还可以有效利用数据结构和算法，促进可重用性。同一块功能经常在代码库之间复制粘贴，导致开发人员效率的巨大损失。它们应该放在库中，并在可能的情况下开源。

好的代码是尽可能少的代码

更少，但更好——因为它专注于基本方面，产品没有非必需品的负担。回归纯洁，回归简单。

这是我的首选原则。我已经在我们不应该发布代码中讨论过它，但基本思想是软件工程主要不是编写代码。这是关于解决问题。碰巧的是，很多问题都可以通过代码解决——但这并不意味着代码可以解决所有问题。

我们如何编写更少的代码？

• 通过寻找现有的现成解决方案并避免 NIH（此处未发明）综合症。
• 通过关注危急的问题，逃避 YAGNI（你不需要它）综合症。
• 通过花足够的时间思考问题，而不是编写代码，从而设计出最简单的解决方案（但不是更简单）。

从长远来看，为什么代码越少越好是显而易见的：更少的维护，（通常）更高的性能，新开发人员的认知负担更少，等等。

结论

因为代码既是一种文学体验，也是一种理性的事业，所以使用来自产品设计的原则对于思考和谈论代码很有用。

参考：

• [1]：Harold Abelson，计算机程序的结构和解释
• [2]：维基百科贡献者，“Dieter Rams”，维基百科，免费百科全书，https://en.wikipedia.org/w/index.php?title=Dieter_Rams&oldid=682540168（2015 年 10 月 1 日访问）。
• [3]：Vitsoe at en.wikipedia [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)]，来自维基共享资源