为什么干净的代码是富有同情心的代码

最初发表于BigCommerce 开发者博客。

这篇文章的想法是在喝啤酒时产生的。

在一个周五的欢乐时光里，我和 BigCommerce 软件工程团队负责人Dan Murrell聊了聊，聊到了 Dan 最近在做的一个项目。他告诉我，他曾经在一个项目上投入了很长时间，但最后还是放弃了，重新开始。他意识到除了他自己，其他人都无法理解代码，因此需要进行修改。这不仅是因为他觉得代码质量不符合他的标准，也是为了将来负责这个项目的工程师着想。他目前正在重新编写项目，根据一套指导原则组织代码，这些指导原则旨在让其他开发人员在最短的启动时间内轻松理解代码的功能。

这个想法让我很感兴趣，因为开发人员会发现自己身处其中的两面。在不同时期，我们可能是接手意大利面条式代码库的人——或者，无论我们是否愿意承认——是创建它的人。Dan 指出，一个项目在其生命周期中会多次易主。每个所有者都有机会让项目变得比最初创建时更好，也有可能制造出一团糟，让未来的开发人员咒骂他们的名字。

我想更多地了解 Dan 如何思考编写干净且可读的代码，因此我再次与他见面（这次没有喝啤酒），以更深入地探讨为未来的程序员编写代码的意义。

自己的生命

首先要明白的是，大多数软件的寿命远远超出了最初创建它的开发人员的寿命。

“现实情况是，如果你为一家公司开发任何类型的软件，它几乎肯定会比你预期的持续更长时间，”丹说道。但知道你的代码会继续存在并被多个所有者继承，会改变你对代码的看法。“你倾向于将自己编写的代码个性化，并将所有经验都投入其中。但你不会是唯一一个从事这项工作的人。”

无论你在哪里编写软件，你很少有机会从一开始就设计解决方案。更常见的情况是，你使用的是继承下来的代码库：要么是公司内部的遗留代码库，要么是客户的网站在你之前已经经过了多位开发人员的开发。作为代码库灾难的受害者，你能够亲身体验到忽视代码整洁最佳实践的后果。

Dan回忆道：“我在一家代理公司工作了五年，我参与的第一个项目是在公司从零开始的，但最初的开发人员离开了。他没有采用最佳实践，后来这个项目又换了三个开发人员才到我手上。我们开始添加新功能，我们必须了解这个项目的功能，因为现在我们必须添加与现有功能兼容的新功能。不可避免的是，我们不得不重写大量代码，因为这些代码可能已经过时，或者无法运行，或者根本就无法运行。大概在那家公司的第一年，我的主要任务就是在这个庞大的代码库中摸索方向。”

Dan 花了接下来的半年时间进行重构，添加了所需的新功能。随着代码库的清理，曾经看似不可能实现的新功能突然变得简单易行。

我不得不退一步认真思考到底发生了什么。我们所做的重构工作使得这个功能现在成为可能。这并不是说它很容易实现——而是在我们投入了这么多精力之后，它才变得容易实现。

为什么优秀的开发人员会写出糟糕的代码

如果我们假设开发人员是好意，那为什么会有这么多难以辨认的代码呢？是不是真的有那么多……糟糕的开发人员？

完全不是。事实上，即使是最有经验的开发人员，也会面临许多不利因素。你可能面临紧迫的截止日期，或者正在构建一个概念验证——而这个概念验证后来会成为永久的解决方案。在这种情况下，编写尽可能优雅、组织良好的代码可能会被放在次要位置，而更重要的是让它运行起来，让项目顺利完成。

另外，以后再清理项目的想法通常只是一厢情愿。

即使是经验丰富的开发人员也说过一千遍他们会回头去做这件事，但你永远都不会回头。有时你会回头，但更多的时候你不会。所以，处理好前端的事情是重要的考虑因素。一旦你意识到自己有多少时间可以处理某件事，或者意识到你不会总是一个人在处理这件事，你就能更好地决定如何构建你的代码，”Dan 说。

清理你的行为

我们都同意，与其等待未来可能永远不会发生的重构，不如从一开始就编写清晰易读的代码。但是，我们所说的清晰易读的代码究竟是什么意思呢？又该如何实现呢？接下来，Dan 分享了一些编写代码的技巧，让你的项目未来所有者感激你。

1.练习。

Dan 建议通过小规模的培训来培养简洁的编程技能。“你可以做一些叫做Code Katas的小练习，它会向你展示一个简单的问题。你可以在午休时间或 15 分钟内完成，它让你有机会解决一个非常简短的问题，从而练习简洁的代码开发。”

把它想象成锻炼肌肉。这些练习可以帮助你培养将代码提炼为最简洁形式的能力，当最佳实践成为你的第二天性时，维护起来就会更容易。

2. 提取、提取、提取。

提高代码可读性的最大优势之一是将代码提取到一次性函数中。Dan 举了一个例子：

假设你写了一个 20 行的函数，它执行四项不同的操作。你可以将这四项不同的操作提取到各自的函数中。这样做就完成了两件事：你把各个操作隔离到各自的容器中，并且简化了结构。

多用途函数总是会带来更大的认知负担，因为试图解读代码的开发人员必须弄清楚代码执行了四种不同的功能。当你将这些功能提取到单独的函数中时，阅读每段代码的功能就会变得容易得多。

“也许你的第一个函数在服务器上存储了一个设置。然后，你提取的第二个函数可能会使用该设置进行 API 调用。然后，下一个函数会根据结果做出某种反应，依此类推，”Dan 继续说道。“这四个函数读起来就像一本书，告诉你我在做什么。” Dan 建议将代码提取出来，直到每个函数都只有一个职责——就这样。

一旦你将所有内容提取到单一用途的函数中，你就可以将这些单一用途的函数推到文件底部，从而提高项目的可读性。“将它们放入私有函数中，这样它们就不会暴露在全局命名空间中，这样你的全局函数就非常简单、非常清晰：一个调用其他四个函数的函数。这使得它在文件顶部非常干净、线性，而那里实际上是有人会阅读的地方，尤其是在私有函数名称非常具有描述性的情况下，”Dan 说。

“如果你看到一个这样编写的文件，那么你几乎可以肯定地认为有人使用了干净的代码实践来提取、提取、提取，并留下顶部非常刻意、非常具体、易于阅读的内容。”

3.使用描述性名称。

以描述性的方式命名函数和变量，对于提高代码的可读性大有裨益。“当你命名得当，它就能自我记录你正在做的事情。没人愿意写文档，也没人愿意读文档。但如果你以描述性的方式命名函数和变量，就能让它自成文档，这样你就可以省去写文档这一步了。”

曾经有一段时间，为了节省内存，最佳做法是使用尽可能简洁的命名约定。但在当今资源丰富的计算环境下，情况已不再如此。

在过去，你会使用像两个字母一样的函数名，或者像 i、j 和 k 这样的变量名。现在，编译器会向下编译代码，而且存储空间基本上是免费的。所以，如果没有必要，真的没有必要让函数名和变量名太简洁。

Dan 也更喜欢代码注释的自文档化方式。“你确实需要记录所有框架使用者需要了解的信息。如果布尔值有默认值，就应该记录它的含义。但至于那种能准确解释代码功能的多行注释——我再也见不到了。”

4. 利用你的工具

当所有其他方法都失败时——那就自动化吧。依靠那些消除对干净代码的猜测的工具，为成功做好准备。

Dan 说：“我用的是 Xcode，Xcode 里其实有一些工具可以让你重构代码。它可以从更大的代码块中提取方法，将其放入一个新函数中，并找出需要输入的内容。”

一致性是另一个提升代码可读性的因素，而 Linter 是强制执行代码风格和格式规范的绝佳工具。但 Linter 只有在项目早期就建立起来，才会真正发挥作用。“Linter 是你应该在项目初期就加入的工具之一，因为它会标记出所有不符合项目标准的行为。如果你已经进行了六个月的项目，并且编写了 2 万行代码，那么你就在这个时候添加了 Linter……那就把下个月的时间留出来吧，因为你接下来要修复的只是合规性问题，”Dan 说。

如果你接手的是一个老项目，那么 Linter 暂时帮不上什么忙。但如果你足够幸运，从第一天就开始接手这个项目，那么引入 Linter 可以大大提升你的代码可读性，让下一位被分配到项目的开发人员更容易理解。

用同理心编码

我和 Dan 的对话真正让我感兴趣的是，这不仅仅是一种学术追求，为了写干净的代码而写干净的代码。让代码简洁易读，其中也包含人为因素。软件是由团队编写的，而不是由孤独的天才编写的。带着同理心编码意味着认识到其他开发人员将来会为你的代码做出贡献，并使你的代码易于他人理解。

当你做到这一点时，你就能开始创造超越个人、服务他人的作品。每个人都喜欢被认可，用一种特别巧妙的方式解决问题也会带来满足感。但归根结底，这不仅仅关乎你——这关乎项目的质量，也关乎所有其他团队成员的成功，无论是过去的、现在的还是未来的，他们也都与你息息相关。

Dan 总结道：

不要为了耍小聪明而写代码。不要试图给任何人留下深刻印象。如果你采用同理心驱动的开发方式，即为下一个做这件事的人着想，你做决定时就会考虑到他们。这样做的好处是，可以控制你的自负，并将你的自负排除在外。

结论

大多数开发者并非有意编写只有自己理解的代码，但现实情况是，有些因素会阻碍这些良好意图的实现。你可能正在构建一个概念验证或 MVP，打算稍后再进行改进——但最终却迟迟未能实现。又或者，你可能一开始是项目的唯一所有者，但最终还是离开了项目或扩大了团队。

一旦您认识到软件的寿命远远超出了其最初的创建者，您就可以开始采用干净的代码实践：

• 通过解决问题的练习进行训练
• 将函数提取到单一用途的块中
• 描述性地命名函数和变量
• 使用内置工具和 linters 来自动化一致性

…你编写的代码不会给项目后续的开发者带来任何困扰。这不仅仅是用同理心编写代码，更是一份美好的善缘。

感谢 Dan Murrell 的真知灼见以及促成本文的讨论。您可以在 Twitter 上关注 Dan @danimal99，或在 Twitter 上关注我们 @BigCommerceDevs。干杯！🍻