越“聪明”的代码，越是“一次性”
大多数程序员，面对复杂问题却能写出精简代码时，总会觉得颇有成就感。但本文作者指出：看似越精简的“聪明”代码，其可读性越低，越是得不偿失。
原文链接：https://www.joshwcomeau.com/career/clever-code-considered-harmful/
未经允许，禁止转载！
作者 | 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 编写的解决方法：
pe58 = nwherea p q = scanl (+) p $ iterate (+ 8) qb = [[x,y,z] | (x,(y,z)) <- zip (a 3 10) $ zip (a 5 12) (a 7 14)]c = zip (scanl1 (+) . map (length . filter isPrime) $ b) (iterate (+ 4) 5)[(n,_)] = take 1 $ dropWhile (\(_,(a,b)) -> 10*a > b) $ zip [3,5..] c
下面是一个用户使用 J 语言编写的代码：
gt;:-:>:1 i.~0.1>}.(>:i.$n)%~+/\n=. isprime +/\1,4#2*>:i.14000显然，用如此少的代码解决如此困难的问题需要大量技巧。如果我能够写出这样的解决方案，我会为自己感到高兴，但我的解决方案总是又长又不优雅。
不过，日常工作中一般不会出现这样的代码——这些代码只是为了娱乐，编写这样的代码多数是为了凸显自己的聪明、吓唬其他人或锻炼大脑。
上述这类问题的代码，你永远也不会阅读第二次，因为它们都是一次性的，我们也不会交给其他人来维护，这与我们日常编写代码的环境不同。
实习生测试
在谈论日常编写的代码时，我会按照下面这个标准来要求：初级开发人员、或者说刚开始职业生涯的人，是否能够理解这段代码？
所以对于共享的代码库而言，好代码就是简单的代码，不需要任何花里胡哨，便于向新手解释基本概念的代码。
例如几年前，我曾接到一个任务，是审查包含以下函数的拉取请求：
const extractDataFromResponse = (response) => {const [Component, props] = response;const resultsEntries = Object.entries({ Component, props });const assignIfValueTruthy = (o, [k, v]) => (v? { ...o, [k]: v }: o);return resultsEntries.reduce(assignIfValueTruthy, {});}
我给出的建议是，按照下面这样重写：
const extractDataFromResponse = (response) => {const [Component, props] = response;const output = {};if (Component) {output.Component = Component;}if (props) {output.props = props;}return output;}
平心而论，原始版本确实有很多优点：
▶ 代码量更少（只有 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”。我的收获之一是明白每个人都患有冒名顶替综合症，我们总是会想尽办法证明自己，如果我编写了一个超级聪明且难以理解的函数，同事就会觉得我很聪明。
然而，我逐渐意识到，任何人都可以编写看似复杂的代码，而最难的部分实际上是用简单的代码来解决复杂的问题。如果你真的掌握了这种本领，没有人会质疑你的能力。