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

　　这个阶段也可以修改变量和函数命名、修改数据结构，以提高代码清晰度和一致性。记得添加相关测试代码(根据需要，可进行单元测试)。

　　修复 bug

　　现在你准备好进行一些最终用户可见的变化，第一件事情将是修复多年来积累在队列中的 bug。

　　像往常一样，首先确认 bug 仍然存在，然后编写一个测试并修复 bug，你的持续集成和端到端的测试可以帮你避免由于缺乏理解或某些错误而导致的任何错误及外围问题。

　　数据库升级

　　如果上述工作都已经完成，你可以再次拥有可靠且可维护的代码库，你可以选择更改数据库 schema 甚至替换数据库。

　　已经完成的上述工作都将有助于您以无负担的方式进行变革，而无需担心任何意外，你可以使用新的代码和所有的测试来测试新的数据库，以确保你的迁移没有任何问题。

　　更稳健的重构之路

　　在路线图上前行

　　恭喜，到这里你已经走出了丛林，现在已经准备好可以实施任何新功能了。

　　不要尝试彻底重写

　　彻底重写是一种几乎保证会失败的项目。

　　一方面，你是在未知的领域开始，你甚至不知道要重构什么。

　　另一方面，你也将所有的问题推到最后一天，就在你用新系统启用之前的那一天。很悲剧的是，那也是你失败的时刻。

　　业务逻辑的假设最终会证实存在问题，那时你将突然了解到为什么旧系统会用某种奇怪的方式来工作，最终也会意识到能将旧系统放在一起工作的人也不都是白痴。

　　如果你真的想要将公司(以及你自己的信誉)带向一个泥潭，就来一个彻底大重写吧!但如果你足够聪明，彻底重写系统通常不会成为会议桌上的一个讨论选项。

　　替代方案：迭代式改进

　　要解开这些线团最快的方法就是从你已经理解的代码入手(它可能是一个外围设备，但也可能是一些核心模块)，并在它的旧的上下文的范围内尝试逐步改进。

　　如果旧的构建工具不再可用，你将不得不使用一些技巧(见下文)，但至少在你开始更改时，尽可能多地保持旧的系统工作。一个典型的提交通常只包含数行代码。

　　发布到生产环境

　　所有修改尽可能发布到生产环境，即使修改的代码是最终用户不可见的，因为当你对系统了解不足时，只有生产环境才会告诉你，新的修改哪里会有问题。

　　如果这个问题只是在小的改变之后出现，你将获得几个优势：

　　很容易弄清楚出了什么问题

　　处于改善流程的良好状态

　　立即更新文档，以记录获得的新见解

　　合理使用代理服务器

　　如果你正在重构一个 Web 系统，你可以在最终用户和旧系统之间部署一个代理服务器。你可以精确控制每个 URL，哪些请求进入旧系统，哪些请求路由到新系统，从而可以更轻松，更精细地控制运行的内容。