拯救你的旧代码库，不得不看的 11 条军规

    原标题：拯救你的旧代码库，不得不看的 11 条军规

    每个程序员、项目经理或团队负责人的职业生涯中至少会遇到一次这样的事件：你接手一坨超过百万行代码的系统，原来的程序员很久以前就离职，现在也许正在某个阳光明媚的地方度假，文档（如果有的话）最有可能的情况就是与现有的系统不同步。而你的工作则是带领团队脱离这个混乱。

　　在经历逃离的本能回应之后，你开始对项目进行了了解，通过你手头现有的东西，失败是大概率发生的事件。但是，公司高层领导是不能容忍项目失败的结果发生。你该如何应对？

　　这时，如果能够把这些垃圾代码变成健康的可维护的项目，实际上是非常值得一试的事情。以下是我们总结的改进旧版代码库的一些经验（或者叫军规）。

　　改进旧代码库的 11 条军规 ——

　　数据备份

　　我们很难记得每天修改了哪些东西，特别是配置数据容易受到这种问题的影响。配置通常不会进行版本控制，如果能够进行定期备份，则可以规避很多麻烦。

　　在开始做任何事情之前，你需要备份所有可能相关的内容，放到一个非常安全的地方，确保不管发生什么情况都不会丢失数据。

　　构建一个真实的仿真环境

　　构建一个真实的仿真环境是重要的先决条件，第一步是你确保知道现在正在生产环境运行的是什么，这意味着你能够构建一个软件版本和你的真实环境保持一致，相同的软件环境与二进制版本。

　　如果你找不到一个方法来实现这一点，假如你提交代码到生产环境，就可能会遇到一些令人不快的意外。确保新的代码在合适环境尽可能地被测试，然后你才会有足够的信心将其运行到生产环境。

　　上线时做好准备可以随时切换回老的代码，并确保通过日志记录可以了解相关重要内容，以便在后续排查问题时能派上用场。

　　冻结 DB 修改

　　尽可能冻结数据库修改，当完成第一阶段的改进，直到团队对代码库有了彻底的了解，遗留代码已经弃之不用时，才考虑修改数据库结构。在此之前任何的数据库修改都可能会导致一些棘手的问题，让你失去并行运行旧系统和新的代码库的能力。

　　保持 DB 完全不变，你可以比较新的业务逻辑代码与旧的业务逻辑代码，如果所有这些效果都与预期一样，则应该完全没有区别。

　　编写测试

　　在进行任何修改之前，编写尽可能多的端到端以及集成测试，确保这些测试能够产生正确的输出，并覆盖所有潜在的情况。

　　这些测试将具有两个重要功能：一方面，帮助技术在早期阶段清除任何误解;另外一方面，一旦你开始编写新代码来替换旧代码，这些测试将可以更好保护您的系统。