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

　　自动化你的所有测试，如果你已经有 CI 的经验则尽快使用它，并确保您的测试运行足够快，以便在每次提交后运行全套测试。

　　Instrumentation 和日志

　　如果旧平台仍然可以增加 Instrumentation，在一个全新的数据库表中执行此操作，为你可以考虑的每个事件添加一个简单的计数器，并添加一个单个函数来实现此功能，以根据事件的名称来增加这些计数器。

　　这样，你可以使用一些额外的代码行实现带有时间戳的事件日志，你将了解到有多少事件导致另一种事件。

　　举例来说，用户打开应用程序，用户关闭应用程序。如果两个事件导致一些后端请求，那么这两个计数器应该在长期上保持不变，差异是当前打开的应用程序的数量。

　　如果你看到更多的应用程序打开，而不是应用程序关闭，你知道必须有另一种应用程序结束的方式(例如崩溃)。

　　这个简单的技巧可以将每个后端应用程序变成一个类似的簿记(bookkeeping)系统，就像一个真正的簿记系统那样，所有的数字必须匹配，确保它们在所有用到的地方没有问题。

　　随着时间的推移，这个系统的健康监控变得非常宝贵，并且将成为源代码控制系统变更日志的一个很好的伴侣，你可以在其中确定每个错误引入的时间点，以及对各种情况产生影响的计数。

　　我通常保留这些计数器的分辨率为 5 分钟(因此每小时记录 12次)，但如果你的系统有更少或更多事件，则可能需要修改这个时间间隔。所有计数器使用同一个数据库表，因此每个计数器只是该表中的一列。

　　每次只修改一个点

　　在添加新功能或修复错误的同时，不要陷入同时改进代码以及修改代码运行平台的陷阱。这会导致很多头大的问题。

　　平台迁移

　　如果你决定将应用程序迁移到另一个平台，那么请先执行此操作，但要保持一切功能完全一样。你可以添加更多的文档或测试，但不能超过这一点，所有业务逻辑和相互依赖关系应该保持原样。

　　架构变化

　　接下来要解决的是改变应用程序的架构(如果需要)。这个时候，你可以随意更改代码的较高级别结构，通常通过减少模块之间的水平链接数量，从而减少与最终用户进行任何交互时代码活动的范围。

　　如果旧代码本质上是一体的，现在将是一个很好的时机使其更加模块化，将大型功能分解成较小的功能，但是保留变量和数据结构的名称。

　　架构修改并不总是可行，如果特别不幸运，那么可能需要非常深入理解代码才能进行任何架构更改。

　　如果你同时进行高级别更改和低级别更改，至少需要将其限制在一个文件，或最坏情况下限制在一个子系统，以便尽可能限制更改的范围。否则你可能很难调试刚才所做的更改。

　　低级重构

　　到目前为止，你应该对每个模块的功能有很好的了解，并为实际工作做好准备：重构代码以提高可维护性，并使代码具备扩展新功能的能力。

　　这很可能是项目中耗时最多的一部分，文档需要随之进行，在完整编写文档介绍并彻底了解一个模块之前，不要随意更改模块。