遗留代码会随时间推移而恶化

遗留代码不会随着时间的推移而变得更好。它只会变得更糟。

上周，我花了三个小时修复一个 bug。本来只需要 20 分钟。问题出在 2019 年的一个验证模块上。因为“它能运行”，所以大家都忽略了它。但它根本没法运行。我在文件里发现了一个 2020 年的 TODO 注释。

许多人将遗留代码视为一种“可选债务”。他们认为等有时间了再还。但遗留代码更像霉菌。它会蔓延，并污染系统的其他部分。你忽视它的时间越长，清理它的成本就越高。

这会形成一个恶性循环：

• 你接手了一个混乱的项目。
• 为了让你的功能正常运行，你又多加了一个 if 语句。
• 六个月后，别人也做了同样的事。
• 一年后，这个文件有了 800 行代码，而且一个测试都没有。

这种“能运行”的代码隐藏着成本：

• 开发速度下降。你花在阅读上下文上的时间比写代码的时间还多。
• Bug 增加。修好一个问题，却搞坏了另一个。
• 上手变得困难。新开发者很难理解为什么逻辑在到处重复。

注意这些危险信号：

• 无用或具有误导性的注释。
• 不同文件中重复的业务逻辑。
• 循环依赖和高耦合。

不要试图重写一切。全量重写有 80% 的失败率。你会花费数月时间去重建已经存在的东西，而业务方却在苦苦等待新功能。

使用带有特征测试（characterization tests）的增量重构：

• 用测试来捕捉当前的逻辑行为，哪怕它很奇怪。
• 在不改变该行为的情况下进行重构。
• 重复此过程，直到代码变得易读。
• 只有在那之后，才通过真正的测试来改变行为。

遵循这些规则以避免陷阱：

• 永远不要在没有测试的情况下进行重构。
• 重构期间不要改变行为。一个 bug 可能是客户赖以生存的、未记录的功能。
• 别动那些“安静”的代码。如果一个模块三年没变过且没出过问题，就别碰它。

把精力集中在你经常接触的代码上。

Source: https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h