问如何为重写应用程序的胶水做准备

EN

简单地说：不要把海洋煮沸。

换句话说，切断一些小的、可管理的块，而不是一次完成整个任务。在一个分支里。没有定期检查。

我一直喜欢这篇文章发表在Joel on上软件。它给出了非常好的具体例子，说明了可以针对代码库进行的小更改，以使代码逐渐变得更干净。

决定一个概念上相似的更改块，并为此创建一个分支。一个示例可能是将所有SQL代码移动到类中。在该分支中，您的工作流程如下所示：

• 删除一条SQL语句
• 做测试
• 签入您的代码
• 重复

一旦完成了这些更改，就将其合并到主分支中，并启动一个新的块。

这是假设你有测试。如果没有，您应该在开始之前创建它们(包括单元、回归和集成测试)。再说一遍，不是一次全部。如果您想重构一个没有测试的函数，那么编写测试，重构代码并运行测试，直到测试通过为止。这正是这些测试的目的所在。确保你在利用它们。

重要的是要知道您的产品是否已经发布，以及您想要接触的API是否以任何方式公开给单独发布的其他实体(模块、项目、产品、文档等)。如果其中任何一个答案都是“是”，则必须在过渡阶段保持API兼容性。与其取代旧的API，不如扩展它。在第二步中，您可以淘汰旧的API并给受影响的实体一个更新的机会。如果可以验证所有相关实体都已停止使用旧API，则只有这样才能将其从您的侧移除。(即使您没有外部依赖项，它仍然可以帮助您使用相同的方法进行重写)。

尽管如此，进行重大重写的一个好方法是尽可能多地将工作划分为较小的独立步骤。

很容易陷入同时处理多个目的的陷阱，但通常会以这样或那样的方式纠缠您的提交--最好的情况是，您必须跟踪多个分支和进展中的特性，这些特性需要在某个时候合并；最糟糕的情况是，所有新特性都是相互交织开发的，防止您对属于单个特性的提交进行清理，甚至阻止您进行任何提交，因为您始终拥有一半工作或不编译的特性。它还将“帮助”您介绍各种模糊的交互错误，在试图找到引入bug的确切位置时会给您带来很多麻烦。

这在很大程度上是一种心理训练，而且有不止一种方法。您可以从突出新API并记录预期用途和API细节开始。一旦完成，您就有了一个稳定的提交点。然后，您可以着手实现单个特性和单元测试(并且可以在此过程中多次提交)。最后，修改调用新API的模块，并完成所有“胶水”工作。此命令将帮助您在不破坏构建的情况下拥有可以提交的停止点。

再说一次，这只是一种方式，而不是唯一的方法。您的目的是模块化重写和最小化更改之间的交互。

我参与过不止一次有针对性的重写。在开始编写更多代码之前，您需要做一些分析：

• 设计得好和设计不好的零件有什么不同？
• 设计糟糕的代码是否可以与好代码的设计结构相匹配？
• 识别设计不良的代码的所有触点。即调用什么方法，如何调用它们(即对象实例或单例，等等)
• 这些触点中有多少是你能安全消除的？
• 确定您可以用来将坏代码与好代码隔离开来的任何接口。

从所有的原始数据来看，你的最终结果应该是什么样的呢？您需要知道什么时候完成，或者什么时候重写足够好给您一个高质量的产品，而不需要放弃每一行代码。

• 把工作分解成任务，你可以一次完成一个任务。
• 估计每项任务需要多长时间。如果你真的不能给出一个好的估计，那么这个任务可能需要更多的细分。包括用于自动化和/或单元测试的时间。
• 把你认为要完成的每一项任务的时间加起来，并把它增加三倍。我是认真的。会有隐藏的后果，你的重新设计，你没有办法在这一点上预期。
• 将您的活动限制在目标重写范围内。您没有时间使用新特性，也没有时间处理代码的其他部分。
• 一次只执行一个任务。在继续工作之前，确保每个任务都已完成并经过测试。

我可以说，经过我的有针对性的重写经验，很多次，最终的产品是更好和更容易维护，但时间表是最大的问题。如果你有有限的时间来完成这项工作，重写会使你的项目比你最初想象的要晚很多。