原标题：拯救你的旧代码库，不得不看的 11 条军规
每个程序员、项目经理或团队负责人的职业生涯中至少会遇到一次这样的事件：你接手一坨超过百万行代码的系统，原来的程序员很久以前就离职，现在也许正在某个阳光明媚的地方度假，文档（如果有的话）最有可能的情况就是与现有的系统不同步。而你的工作则是带领团队脱离这个混乱。
在经历逃离的本能回应之后，你开始对项目进行了了解，通过你手头现有的东西，失败是大概率发生的事件。但是，公司高层领导是不能容忍项目失败的结果发生。你该如何应对？
这时，如果能够把这些垃圾代码变成健康的可维护的项目，实际上是非常值得一试的事情。以下是我们总结的改进旧版代码库的一些经验（或者叫军规）。
改进旧代码库的 11 条军规 ——
数据备份
我们很难记得每天修改了哪些东西，特别是配置数据容易受到这种问题的影响。配置通常不会进行版本控制，如果能够进行定期备份，则可以规避很多麻烦。
在开始做任何事情之前，你需要备份所有可能相关的内容，放到一个非常安全的地方，确保不管发生什么情况都不会丢失数据。
构建一个真实的仿真环境
构建一个真实的仿真环境是重要的先决条件，第一步是你确保知道现在正在生产环境运行的是什么，这意味着你能够构建一个软件版本和你的真实环境保持一致，相同的软件环境与二进制版本。
如果你找不到一个方法来实现这一点，假如你提交代码到生产环境，就可能会遇到一些令人不快的意外。确保新的代码在合适环境尽可能地被测试，然后你才会有足够的信心将其运行到生产环境。
上线时做好准备可以随时切换回老的代码，并确保通过日志记录可以了解相关重要内容，以便在后续排查问题时能派上用场。
冻结 DB 修改
尽可能冻结数据库修改，当完成第一阶段的改进，直到团队对代码库有了彻底的了解，遗留代码已经弃之不用时，才考虑修改数据库结构。在此之前任何的数据库修改都可能会导致一些棘手的问题，让你失去并行运行旧系统和新的代码库的能力。
保持 DB 完全不变，你可以比较新的业务逻辑代码与旧的业务逻辑代码，如果所有这些效果都与预期一样，则应该完全没有区别。
编写测试
在进行任何修改之前，编写尽可能多的端到端以及集成测试，确保这些测试能够产生正确的输出，并覆盖所有潜在的情况。
这些测试将具有两个重要功能：一方面，帮助技术在早期阶段清除任何误解;另外一方面，一旦你开始编写新代码来替换旧代码，这些测试将可以更好保护您的系统。
自动化你的所有测试，如果你已经有 CI 的经验则尽快使用它，并确保您的测试运行足够快，以便在每次提交后运行全套测试。
Instrumentation 和日志
如果旧平台仍然可以增加 Instrumentation，在一个全新的数据库表中执行此操作，为你可以考虑的每个事件添加一个简单的计数器，并添加一个单个函数来实现此功能，以根据事件的名称来增加这些计数器。
这样，你可以使用一些额外的代码行实现带有时间戳的事件日志，你将了解到有多少事件导致另一种事件。
举例来说，用户打开应用程序，用户关闭应用程序。如果两个事件导致一些后端请求，那么这两个计数器应该在长期上保持不变，差异是当前打开的应用程序的数量。
如果你看到更多的应用程序打开，而不是应用程序关闭，你知道必须有另一种应用程序结束的方式(例如崩溃)。
这个简单的技巧可以将每个后端应用程序变成一个类似的簿记(bookkeeping)系统，就像一个真正的簿记系统那样，所有的数字必须匹配，确保它们在所有用到的地方没有问题。
随着时间的推移，这个系统的健康监控变得非常宝贵，并且将成为源代码控制系统变更日志的一个很好的伴侣，你可以在其中确定每个错误引入的时间点，以及对各种情况产生影响的计数。
我通常保留这些计数器的分辨率为 5 分钟(因此每小时记录 12次)，但如果你的系统有更少或更多事件，则可能需要修改这个时间间隔。所有计数器使用同一个数据库表，因此每个计数器只是该表中的一列。
每次只修改一个点
在添加新功能或修复错误的同时，不要陷入同时改进代码以及修改代码运行平台的陷阱。这会导致很多头大的问题。
平台迁移
如果你决定将应用程序迁移到另一个平台，那么请先执行此操作，但要保持一切功能完全一样。你可以添加更多的文档或测试，但不能超过这一点，所有业务逻辑和相互依赖关系应该保持原样。
架构变化
接下来要解决的是改变应用程序的架构(如果需要)。这个时候，你可以随意更改代码的较高级别结构，通常通过减少模块之间的水平链接数量，从而减少与最终用户进行任何交互时代码活动的范围。
如果旧代码本质上是一体的，现在将是一个很好的时机使其更加模块化，将大型功能分解成较小的功能，但是保留变量和数据结构的名称。
架构修改并不总是可行，如果特别不幸运，那么可能需要非常深入理解代码才能进行任何架构更改。
如果你同时进行高级别更改和低级别更改，至少需要将其限制在一个文件，或最坏情况下限制在一个子系统，以便尽可能限制更改的范围。否则你可能很难调试刚才所做的更改。
低级重构
到目前为止，你应该对每个模块的功能有很好的了解，并为实际工作做好准备：重构代码以提高可维护性，并使代码具备扩展新功能的能力。
这很可能是项目中耗时最多的一部分，文档需要随之进行，在完整编写文档介绍并彻底了解一个模块之前，不要随意更改模块。
这个阶段也可以修改变量和函数命名、修改数据结构，以提高代码清晰度和一致性。记得添加相关测试代码(根据需要，可进行单元测试)。
修复 bug
现在你准备好进行一些最终用户可见的变化，第一件事情将是修复多年来积累在队列中的 bug。
像往常一样，首先确认 bug 仍然存在，然后编写一个测试并修复 bug，你的持续集成和端到端的测试可以帮你避免由于缺乏理解或某些错误而导致的任何错误及外围问题。
数据库升级
如果上述工作都已经完成，你可以再次拥有可靠且可维护的代码库，你可以选择更改数据库 schema 甚至替换数据库。
已经完成的上述工作都将有助于您以无负担的方式进行变革，而无需担心任何意外，你可以使用新的代码和所有的测试来测试新的数据库，以确保你的迁移没有任何问题。
更稳健的重构之路
在路线图上前行
恭喜，到这里你已经走出了丛林，现在已经准备好可以实施任 功能了。
不要尝试彻底重写
彻底重写是一种几乎保证会失败的项目。
一方面，你是在未知的领域开始，你甚至不知道要重构什么。
另一方面，你也将所有的问题推到最后一天，就在你用新系统启用之前的那一天。很悲剧的是，那也是你失败的时刻。
业务逻辑的假设最终会证实存在问题，那时你将突然了解到为什么旧系统会用某种奇怪的方式来工作，最终也会意识到能将旧系统放在一起工作的人也不都是白痴。
如果你真的想要将公司(以及你自己的信誉)带向一个泥潭，就来一个彻底大重写吧!但如果你足够聪明，彻底重写系统通常不会成为会议桌上的一个讨论选项。
替代方案：迭代式改进
要解开这些线团最快的方法就是从你已经理解的代码入手(它可能是一个外围设备，但也可能是一些核心模块)，并在它的旧的上下文的范围内尝试逐步改进。
如果旧的构建工具不再可用，你将不得不使用一些技巧(见下文)，但至少在你开始更改时，尽可能多地保持旧的系统工作。一个典型的提交通常只包含数行代码。
发布到生产环境
所有修改尽可能发布到生产环境，即使修改的代码是最终用户不可见的，因为当你对系统了解不足时，只有生产环境才会告诉你，新的修改哪里会有问题。
如果这个问题只是在小的改变之后出现，你将获得几个优势：
很容易弄清楚出了什么问题
处于改善流程的良好状态
立即更新文档，以记录获得的新见解
合理使用代理服务器
如果你正在重构一个 Web 系统，你可以在最终用户和旧系统之间部署一个代理服务器。你可以 控制每个 URL，哪些请求进入旧系统，哪些请求路由到新系统，从而可以更轻松，更精细地控制运行的内容。
如果你的代理足够强大，你甚至可以控制将某个 URL 一定百分比的流量发送到新系统，以便观察新系统的运行情况。如果你的集成测试也能够连接到这个代理，那就更好了。
结语
如果按照这些步骤进行，确实存在不少工作，但是它的确有效，而且这个过程的任何优化都让你进一步彻底了解整个系统。
有时候如果公司系统已经出现问题，而且可能会影响客户时，如果按照这个流程进行可能使事情好转，我宁愿完全控制和使用这个过程，而不是为了表面的节省几天或几周时间的方式。
如果你更多地是激进的做事方式，你的老板也同意，也许那是可以接受的高风险方式，但是大多数公司宁愿采取稍慢一点，更稳健的重构之路。
[责任编辑:毛青青]
