我承认有些标题党，事实上写下此文时，我还没有从被老代码坑出故障带来的低落心情中走出来。本文来简单探讨下维护历史代码尤其是历史业务代码时，有哪些原则和思考点可以帮助我们减少被坑的概率。

项目开发流程的现状决定了你本次上线的风险

代码的核心逻辑有单测覆盖吗？单测是基于 TDD 或者 BDD 编写的还是只是打印结果靠人肉 assert ？平时团队的大段代码改动会做好拆分再提 pull request 吗？团队审阅 pull requests 时有没有人认真看内容？代码结构和具体的实现问题有人提出疑问并得到作者解决了吗？QA 团队平时愿意给技术改造做测试吗？QA 团队有设计相对完善的自动化测试用例吗？

如果当你审视这些问题时，有超过 2 项问题的答案都是否定的，那你就要小心了，你改动的可能是一段除了原作者之外其他人都是知其然不知其所以然的代码，改动和上线带来的风险骤增。

永远不要无限信任历史业务代码

我们常常称历史业务代码为屎山，但不得不承认，这些代码如果没人改动，大部分都会本本分分地在线上运行数年。

然而作为历史代码，常常存在交接、奇葩需求的代码设计取舍、不规范的编程语言使用方式和较差的编程习惯。我们常常会体验到看到自己几年前所写代码时的陌生感，同样，历史代码是危机四伏的，可能仅仅一个异常类型的差异，就会给你带来不小的线上事故。因此我们在对历史代码进行修改、或迭代其底层代码依赖时，必须对其设计和逻辑进行逐行地重新审视，对于缺少单测的核心逻辑也要补全测试。不要觉得这会拖慢进度，事实上再快的进度在线上故障的影响下都是苍白无力的。

尝试让测试团队发挥真正的作用

如今国内大部分互联网公司和软件公司仍然在建设测试团队，我们必须要和测试团队做好沟通、拉近关系、讲清利弊，做 CI/CD 系统、搞稳定性建设固然比编写测试用例、测需求更容易晋升和拿好绩效，但这是以系统平稳运行为基础的，长期的忽视基础测试能力最终也会影响测试团队本身的发展。测试向来是个技术活，自测的最大问题就在于你永远也无法发现你默认没问题的问题，测试与研发协力发展才能真正地保障线上质量。

对于历史代码则更是这样，团队几经变革、代码多次易手、文档可能早已滞后，但 CI/CD 流程中的强制自动化用例检测却是提交代码的硬性门槛，只要守住了这个门槛，历史代码的维护总能少些心惊肉跳。

小心！监控可能早已无效

正如当前的稳定性手段在未来却有可能成为稳定性隐患一样，过去帮了团队大忙的监控随着业务的发展可能早已不能满足需求。而对于历史代码来说，年久失修的指标和采集都是一颗定时炸弹。

比起修改历史代码导致的故障，更可怕的是故障已然发生许久，你却没有任何感知，原因就在于历史逻辑的监控可能早已失效或根本就没设置过！

上线之心态

我常常觉得后端服务的上线犹如驾驶飞机，过度的自信总能招致各种问题的叠加酿成惨剧，而谨慎则总能为我们构筑我们能把控的一道底线。无论你是 L8 、P7 还是 2.2 甚至更高的职级，只要你面对的是历史代码且存在上文提到的风险和隐患，上线就总是危险的。端正态度，做好事前准备和事中预案，谨慎总是没错的。