重新审视：通过应用这7条规则来清理你的代码

Source: Dev.to

大约五年前，我写了一篇题为《通过应用这七条规则来清理代码》的文章。当时，我专注于编写更清晰、更易读的代码，并分享了一些帮助我提升日常工作效率的实用技巧。

回顾过去，这种专注是有道理的。干净的代码承诺了清晰性、可维护性以及对日益增长的复杂性的控制感。当时，我主要从个人贡献者的角度出发，探讨如何编写更好的软件。

五年后，我仍然认同那篇文章的初衷，但我对何时以及如何应用这些理念的理解已经有所演进。

如果你想先阅读原始版本，可以在这里找到：
Clean Up Your Code by Applying These 7 Rules

什么仍然适用

原帖中的几个想法经久不衰，因为它们根植于沟通而非具体技术。

• 可读的代码仍然是你能做的最佳投资之一。清晰的命名、简单的控制流以及小而专注的逻辑单元，使得他人（以及未来的自己）更容易理解代码想要实现的功能。
• 童子军规则——把代码稍微改进后再交还——依然很有共鸣。小的改进会随时间累积，代码库因细心维护而受益，而不是因疏忽而衰退。
• 这些原则之所以有效，是因为它们 与工具无关。它们帮助下一个阅读代码的人，而这往往是你的未来自我——甚至是尝试基于你的代码生成可读代码的 LLM。

今天感到不完整的地方

原先认为清理总是显而易见的下一步的假设已不再成立。

• 在职业生涯早期，我把清理视为本地活动：我看到不喜欢的东西，套用规则，然后继续。随着时间的推移，我了解到清理很少仅仅关乎代码；它涉及上下文、所有权、时机和意图。
• 在不了解代码存在原因的情况下进行重构可能存在风险。看似冗余或过度防御的代码可能是在防护你未意识到的约束。删除它可能引入细微的错误或撤销有意的决定。
• 技术决策往往受到产品需求、截止日期或组织约束的驱动。在这些情况下，“干净”并非首要目标；交付可工作的东西才是。
• 规则本身并没有错，但没有上下文时它们是不完整的。

对清理的演变视角

在处理更大、更老的系统时，我被迫放慢脚步，重新审视我的方法。

• 继承 我未编写的代码凸显出，理解通常比立刻改进外观创造更大的价值。
• 我开始将清理视为共同责任而非个人责任。在团队中，即使是出于好意的重构也可能产生副作用；小的局部更改会向外扩散，以意想不到的方式影响他人。
• 知道某事为何存在比知道如何改进它更重要。

干净的代码不是清单；它是理解的副产品。

规则是有用的起点，但判断才使它们有价值。有时正确的选择是重构；有时是记录意图；有时则是保持现状，稍后再审视。

目标

目标不是完美。目标是管理并为客户提供价值。

我仍然相信编写干净的代码，也相信尊重前人的工作是这份责任的一部分。代码是当时在压力下、依据当时可得信息、常常在我们现在已不再看到的约束条件下所作决定的记录。

重新阅读我以前的帖子让我意识到，学习并不总是关于新想法。有时重新构建旧想法甚至更有价值。

总体而言，这些规则在过去五年里帮助我写出更好的代码，但经验教会了我何时应用它们。