Legacy Code Base如何做重构？

根据我的经验，遗留系统一般具备以下一些特征：

1. 代码成坨
2. 命名混乱
3. 过度冗余
4. 无效注释
5. 缺少测试
6. ....

这些特征如果同时出现在你面前，我猜你离崩溃的边缘不远了，如果后边还跟着一个PM催进度，你估计要怀疑IT人生了。不过，如果你有机会遇到这样的场景，那首先恭喜你，你这个时候已经很资深了，作为一个资深程序员，这些问题你可能会经常遇到，而且你还要带头解决掉。那怎么办，不能再像刚毕业那会儿任性了，再难也要硬着头皮干下去，家里还要一家让你等着你糊口呢.....

面对一些难搞的遗留系统，ThoughtWorks的王健曾经总结过重构的十六字心法：

旧的不变，新的创建，一键替换，旧的再见

在遗留系统中，通常自动化测试都很难添加，为了安全起见，首先保持旧的不变，创建新的，然后让新的功能测试通过后，再用其替换老的功能。那么新的部分，你就可以一开始尝试尽量规避难以测试的问题，虽然也是举步维艰，但至少已经有了之前糟糕的体验，你怎着找也要让自己更加舒服一点。

有时候光标跳来跳去，看到一些你实在想爆粗口的SHI一样代码，忍住，先想想，这个地方会影响我去添加新功能吗？看了一眼提交记录，已经3年没有动了，多半是稳定的代码，不到必须动它，就随他而去吧。

业务方要加一个功能，时间没那么紧急，但必须要动某个模块的代码，而这个模块的代码实在是不敢直视。虽然没法逃避，也不要直接埋头开干，先了代码的解业务上下文，尝试去将代码做一些重构，尝试添加测试，这个过程也能帮助你去理解代码。实在不行，加一个高层的端到端测试也比没测试好，然后尝试Timebox做重构，将要做的事情做一个梳理，拆分成小的重构任务，比如2个小时或者半天，提前规划好退路，实在不行就退回去。

对于一些很大很难搞遗留系统，十六字心法是一些行业资深的同仁总结出来的经验，其实也是一种无奈的举措，中间要付出的心血仍然非常巨大。有些善于总结的大师，总结出了绞杀者和修缮者等模式来提供一些思考，比如：抽象分支

平均下来，绝大多数程序员面临的遗留系统没并那么可怕，针对这样的系统，我提三条小的建议：

1. 首先，我觉得你应该重构自己的心态：不畏惧它，不抱怨它，静下心来，其实问题已经解决一大半了。
2. 其次，重构自己的协作方式，多发挥团队的力量，找业务人员沟通，了解业务背景，找老同事沟通，了解方案的原因，毕竟你不是一个人在做交付。
3. 最后，重构自己的技能，让自己的重构技法和编码Sense日渐增强，这是程序员的硬核。

面对遗留系统，你是如何做的呢？