遗留代码：拖得越久越痛苦

作为一名开发者，你一定遇到过这种情况：接手一个老项目，代码混乱、文档缺失、测试覆盖率几乎为零。望着那片"灰色地带"，心里只有一个念头——能不能假装没看见？

可惜，答案是：不能。

代码也会“老龄化”

遗留代码（Legacy Code）并不是指那些写了很久的代码，而是指那些没有测试保护、难以理解、难以修改的代码。它可能只写了几个月，但已经变成了一团乱麻。

我曾经遇到过一个项目，核心业务逻辑分散在数百个全局函数中，没有任何模块化设计。每次需求变更，都像在雷区里跳舞——改一个地方，不知道会爆炸哪里。

为什么我们总在逃避？

面对遗留代码，开发者普遍有几种心态：

1. 恐惧驱动

"这代码谁写的？算了，别动它。"

当代码没有测试保护时，任何修改都可能引发蝴蝶效应。这种不确定性让人本能地选择回避。

2. 短期主义

新功能多香啊！为什么要花时间重构旧代码？它还能跑，不是吗？

于是我们继续往废墟上盖房子，直到有一天，连门都找不到了。

3. 责任分散

遗留代码是"历史问题"，又不是我造成的。谁污染谁治理嘛！

越拖越贵的真相

让我们算一笔账。

假设一个功能在遗留代码中实现需要 3天。如果不做任何处理，3个月后，由于业务复杂度增加和代码继续腐化，同样的功能可能需要 5天。半年后？可能变成 1周。

这还没算上bug修复、紧急发布、生产事故的时间成本。

技术债是会复利的。

破局之道

说了这么多负能量，该来点解决方案了。

策略一：添加测试，稳住阵脚

面对遗留代码，第一步不是重构，而是写测试。

通过逆向工程理解代码行为，然后用测试把它"框"起来。这就像给正在漏油的飞机先补洞——不是为了好看，是为了让你能安全地继续飞。

策略二：小步快跑，持续重构

别想着毕其功于一役。把大重构拆成小任务，融入日常开发中。每次修改一个函数，每个类，逐步改善。

关键是让代码比你接手时更干净一点。

策略三：建立边界，逐步隔离

如果代码库太大，一时半会搞不定，那就先建立边界。通过接口、适配器等模式，把遗留代码和干净代码隔离开。

让它成为一个"孤岛"，而不是蔓延的瘟疫。

策略四：说服老板，这很重要

技术债不是技术问题，是商业问题。

给老板算账：开发速度下降多少？线上事故增加多少？招聘难度提高多少？用数字说话，而不是抱怨"代码太烂"。

心态的转变

最后，我想说的是心态。

遗留代码不是耻辱，而是每个成功产品的必经之路。Facebook、Google、Microsoft，所有大厂的代码库都有它们的"黑暗角落"。

重要的是意识到问题存在，并且开始行动。

不要等到代码已经病入膏肓才想起来抢救。从今天开始，每次提交代码，都让它比上一次更好一点点。

这样，等你的继任者接手时，至少不会在心里骂你。

结语

回到开头的问题：能不能假装没看见遗留代码？

不能。因为代码不会自己变好，只会越烂越深。

你我都是这条产业链上的一环。与其抱怨前人，不如做好自己。别让今天的优雅代码，变成明天的遗留噩梦。

共勉。