【译】好的代码是给继任的情书

我们经常把编程浪漫化，把它描述成一种抽象的艺术形式、一门科学，甚至一种魔法。然而，真相是更实际的。代码在本质上是一种交流。在我写的《学习JavaScript设计模式》书中，我提过“好的代码就像是写给系统将来维护者的情书”。这是一种亲密的通信，从一个工程师到另一个工程师，跨越时空。

爱的语言

情书往往是私人的，它真诚而又体贴。它是感情的诗意见证，往往经过精心制作，意在准确传达情感。好的代码应该也有这些特点。它是私人的，因为它反映了工程师的逻辑和思考。它是真诚的，没有不必要的复杂炫技。它是体贴的，会为将来阅读它的人考虑。最重要的是，它经过精心制作，以期高效解决问题。

就像我们用语法将我们的词句、情感组织成可理解的句子一样，我们也有设计模式和原则来塑造我们的代码。这些模式使得代码更易扩展、维护，提高效率，同时也让代码更容易阅读、理解。它们为工程师构建了共同的语境，让大家能用通用的、被认可的结构来完成复杂的软件设计。

因此，好的代码应该战略性地使用这些模式，就像经验老道的诗人会用修辞手法来引发共鸣一样。不是为了用而用，而是因为它们本身带来了价值，它们让代码更容易理解，并确保了代码仓库的长期稳定。

SOLID、DRY、KISS和YAGNI不只是干巴巴的原则，它们是编写好代码的基石。它们引导工程师做出明智的决策，在过度设计和设计不足之间寻求平衡，最终写出一封令接收者珍视的“情书”。

好的代码应该遵循已有的最佳实践，就像一封情书会遵循已有的社交礼仪一样，包括恰当的命名规范、模块化的组织，以及详尽的注释。这些是应该遵守的规则，同时也是判断工程师写代码对继任有多体贴的标准，它们的存在是为了确保编码者的意图不会在传播中遗漏。

就像作家会反复阅读检查自己的信件一样，工程师也应该这样对待代码。测试是否严格、是否遵循测试驱动开发（TDD），可以用来衡量“情书”是否是精心制作。测验代码在不同场景下的性能，揭示潜在的缺陷和盲点。使用了强劲的测试框架往往可以证明代码的质量。

最重要的是，一封情书的核心是对读者的同情和尊重，好的代码也该如此。编写其他人方便阅读、理解和维护的代码，是一种职业尊重的表现。它表明编码者理解他的工作是一个更大的、持续付出努力的一部分，软件是一个不断发展的生命体，随着时间推移会有很多人参与其命运的塑造。

其实，编程是一种创作行为，就像写诗或绘画一样。然而，这其间的创作之美不仅由算法的优雅或代码的效率来衡量，还要看别人能否在我们的基础上愉快、便捷地持续构建。作为工程师，我们不仅要解决今天的问题，还要确保我们自己不会成为明天的问题。

因此，好的代码不仅是一封情书，它也是我们留给继任的遗产。