查看原文
其他

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

CSDN 2023-06-11

大多数程序员,面对复杂问题却能写出精简代码时,总会觉得颇有成就感。但本文作者指出:看似越精简的“聪明”代码,其可读性越低,越是得不偿失。

原文链接: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”。我的收获之一是明白每个人都患有冒名顶替综合症,我们总是会想尽办法证明自己,如果我编写了一个超级聪明且难以理解的函数,同事就会觉得我很聪明。

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

推荐阅读:

GitHub 前 CTO 再创业,起步便获 2600 万美元投资,唯一竞争对手只有 OpenAI!

资深开发者眼中的开源云原生数仓 ByConity

资料下载丨一图看懂Serverless架构的资源平衡管理


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存