越“聪明”的代码，越是“一次性”

作者 | Josh Comeau

译者 | 弯月    责编 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

不可否认，遇到难题能想到巧妙的解决方案会让人很有成就感。例如，挑战自己使用递归而不是迭代，或者创建优雅的级联抽象层以确保代码永远不会重复，你一定会感到很高兴。

对于这类编程，我最喜欢的一个资源是Project Euler（地址：https://projecteuler.net/）。

Project Euler 是一个基于高等数学的挑战库，旨在通过软件解决问题，要求程序在 2004 年左右的硬件上运行时间不超过 1 分钟。这意味着，你不能靠蛮力解决问题，必须想出一个更聪明的解决方案。

下面是一个例子：

问题 58：螺旋质数

从 1 开始，按如下方式逆时针旋转，形成一个边长为 7 的正方形螺旋。

有趣的是，奇数的平方数都位于右下对角线；更有趣的是，位于两条对角线上的 13 个数字中有 8 个是质数，总体占比为：8/13=62%。

如果在上面的螺旋之上再加一层，就会形成一个边长为 9 的正方形螺旋。如果继续这个过程，那么当正方形螺线的边长为多少时，两条对角线上的质数百分比将首次低于 10%？

解决这个问题后，你还可以查看其他人共享的解决方案。你会感到很惊讶：哇！居然有人能想出如此简洁、如此聪明的解决方案？！

下面就是一个用户使用 Haskell 编写的解决方法：

下面是一个用户使用 J 语言编写的代码：

显然，用如此少的代码解决如此困难的问题需要大量技巧。如果我能够写出这样的解决方案，我会为自己感到高兴，但我的解决方案总是又长又不优雅。

不过，日常工作中一般不会出现这样的代码——这些代码只是为了娱乐，编写这样的代码多数是为了凸显自己的聪明、吓唬其他人或锻炼大脑。

上述这类问题的代码，你永远也不会阅读第二次，因为它们都是一次性的，我们也不会交给其他人来维护，这与我们日常编写代码的环境不同。

实习生测试

在谈论日常编写的代码时，我会按照下面这个标准来要求：初级开发人员、或者说刚开始职业生涯的人，是否能够理解这段代码？

所以对于共享的代码库而言，好代码就是简单的代码，不需要任何花里胡哨，便于向新手解释基本概念的代码。

例如几年前，我曾接到一个任务，是审查包含以下函数的拉取请求：

我给出的建议是，按照下面这样重写：

平心而论，原始版本确实有很多优点：

▶ 代码量更少（只有 4 个语句，而第二个版本中有 7 个语句）；

▶ 没有重复（在第二个版本中，两个 if 语句的作用基本相同）；

▶ 没有修改任何变量；

▶ 更具可扩展性：重写后可轻松处理 10 个字段，而不止 2 个。

但是，原始版本更难理解——我不得不浪费大量脑细胞来理解这些代码究竟在干什么，对于许多初级开发人员而言，应该也无法很好地理解。

在我看来，函数式版本的可读性成本太高了，得不偿失。

为什么可读性如此重要？

为了说明我认为可读性是好代码的一个重要属性，下面我们来看看流行的开源库 lodash。

lodash 是一个非常流行的库，每周仅通过 NPM 的下载量就超过 2600 万次，Github 上的 Star 数更是超过了 4.2 万个。然而，有一个很奇怪的地方是：这个库未解决的问题始终不会超过 10 个。

尽管我们一直都提倡 Inbox Zero（收件箱归零），但热门项目的问题永远不会归零。但 lodash 的未解决问题经常为零，并且多年来一直如此。

有个主要原因可能是主作者 John-David Dalton 是一位热情的维护者，他花费了大量时间对问题进行分类。但我觉得，无论是任何人，就算是超人，都无法做到让如此热门的一个库的问题数归零——直到在多年前，我在播客上听到 John-David Dalton 谈论管理这类项目的关键是，如何鼓励很多人为代码库做贡献。

他的方法之一是将代码保持在非常基础的水平，使用简单、基本的结构，确保贡献者无论经验深浅都能理解代码并为其做出贡献。我记得，John-David Dalton 提到他们更喜欢 if/else，而不是三元运算符，因为很少有人有使用三元运算符的经验。换句话来说，如果你的目标是保持代码简单易懂，那么用三元运算符的表达方式就是有害的。

如果你正在构建开源工具，那么记住这一点很重要；如果你正在与其他人一起开发生产代码库，那么这一点就尤为重要，特别是当队友的经验不如你时。

bug数与代码长度

你听过下面这句话吗？

“更少的代码意味着更少的错误隐藏空间。”

这句话的意思是，代码要越短越好，因为这样更容易发现错误，而每多敲一个字符，都会增加出错的可能性。

对于拼写错误这类的 bug，上述论点固然没错，但拼写错误往往很容易被发现和修复。真正麻烦的 bug 是由代码过于复杂而引发的，开发人员遇到这类 bug 就好像拿到烫手山芋，恨不得立即甩锅给别人。

在调试问题时，你必须全神贯注，仔细理解每一行代码。当你创建一个抽象来减少重复（所谓“DRY 原则”，Don't Repeat Yourself，不要重复你自己）时，无形中就添加了一个间接层，理解起来也就多了一重障碍。思维模型越难解释每一个边缘情况和可能的状态，就越难诊断出问题的关键所在。

“每个人都知道调试比写程序要难一倍。所以，如果你在编写代码时机关算尽，那么将来要如何调试呢？”

—— Brian Kernighan，《The Elements of Programming Style》

抽象的成本

如果目标是降低复杂性，而抽象增加了复杂性，那么我们是否应该完全废除抽象呢？并不是。因为抽象无处不在：循环是抽象，函数是抽象，编程语言本身就是对机器代码的抽象，而机器代码本身则是晶体管的抽象。

所以说，一切都是抽象。关键在于，我们需要权衡抽象的成本与收益。

假设我们正在构建一个 React 应用，我们有一个列表，其中包含 100 个需要渲染的东西。我们可以选择复制/粘贴同一个 JSX 100 次，也可以将其映射到一个数组，这样只需编写一次 JSX。在这种情况下，“复杂”的解决方案是完全值得的，因为底层的复杂性众所周知，而替代方案维护起来会很麻烦。

在构建产品时，我们总是需要做出这样的权衡决定。我个人的看法是，我们在权衡利弊时应该考虑年轻队友，想一想我们为他们增加了多少复杂性？这样值得吗？

不可避免的复杂性

有时，有些代码本身就很复杂，因为现实世界就很复杂，我们的软件必须对其建模。我们无法确保总是能写出初级工程师可以轻松解析和贡献的代码。有时是因为业务逻辑真的很棘手，有时是因为我们不得不使用理解起来有难度的 API 等等。

我认为，一个最好的解决这类问题的方法是尝试隔离复杂性。在简单与复杂之间设置清晰的界限。不要让复杂性渗透到周围区域。

John-David Dalton 在 lodash 中做到了这一点。他在播客采访中表示，绝大多数 lodash 代码都简单易懂，他们将复杂的部分集中到了一起，组成核心代码，用于处理难题。这意味着，大多数贡献者不必在意这些复杂的代码，因为这种复杂性不会散布到整个应用中。

如果你的应用架构合理，复杂的问题都集中在一个地方处理，那么应用的绝大部分代码都可以保持简单。如果初级工程师需要处理那个复杂的核心，该怎么办？那么就只能找一个更资深的人来指导他们完成了。

冒名顶替综合症

去年的 React Rally 上，Chantastic 发表了一篇我最喜欢的演讲，题目是“Hot Garbage; Clean Code is Dead”。我的收获之一是明白每个人都患有冒名顶替综合症，我们总是会想尽办法证明自己，如果我编写了一个超级聪明且难以理解的函数，同事就会觉得我很聪明。

然而，我逐渐意识到，任何人都可以编写看似复杂的代码，而最难的部分实际上是用简单的代码来解决复杂的问题。如果你真的掌握了这种本领，没有人会质疑你的能力。