【.com快译】 处理遗留应用，重写好还是重构好？对于两者的具体取舍，ErikDietrich作为一名技术作家给出了自己的看法。 重写还是重构？ "我们已经有了基本的应用，但是很难决定是重写还是重构呢？"相信很多朋友都面临着这样的困扰。 事实上，几乎每个CIO、开发主管，甚至董事会成员都必须处理这类问题。ErikDietrich为此收集整理了大量资料，希望能帮助大家在重写、淘汰、重构甚至重新设计等选项中找到最合适的解决方案。 使用正确的术语 首先，让我们简化问题。当应用程序陈旧、笨拙甚至开始崩溃时，您会怎么做？您是将其丢弃、注销还是重新开始？或者，您是否计划以更清洁、更现代和可行的方式重建它？模型？无论如何，这里首先要纠正的是——最后一种方法不是“重构”。 广义上讲，“重构”代码的基本定义是在不改变代码外部活动特性的情况下重塑结构。例如，取一个大方法并从中提取部分代码并将其添加到另一个方法中。但是如果你想用“refactoring”来表示“rewriting”，请注意这两者指的不是同一种方法。 假设您有一个旧的Web表单应用程序，其中包含原始代码和将GUI绑定到数据库的逻辑本身。更糟糕的是，您可能正在使用一些完善的支付处理库，这意味着它无法更新到.NET2.0+。在这种情况下，“重写或重构”问题的本质不是“我是否应该调整或重写应用程序中的某些代码”，而是“我是否应该替换或重写它”。 在这个例子中，重构发生在持续且相对较小的基础上。如果您更换了构成项目的某些部分，软件本身也会发生变化。这意味着我们将改变它与数据库交互的方式，替换依赖项，更新代码框架等等。这实际上是对应用程序的修改。 改造？或者重写。 在此基础上，我们可以更仔细地看问题。 企业不应该背负如此多的技术债，以至于开发者无法有效完成应用程序的重写。如果开发者因为当初的烂摊子而不得不选择从头开始，那么企业自己就必须为此承担责任。所以，当我们最近谈论重写时，我们谈论的是应该定期进行的正常应用程序更新调整。在这种情况下，开发团队应该积极学习如何清理和推送软件更新。 但面对同样的背景，有的团队会选择从头开始，而有的团队则更倾向于重写——为什么会有这样的差异呢？ 选择重写的原因可能是因为软件一直运行在过时的硬件上，或者依赖过时的软件。这意味着该软件可能无法从根本上与现有体系结构互操作。 不管是什么情况，答案都可以简单地归结为：如果重新发明比从头开始更昂贵，那就重写。因此，价值判断成为最核心的决定因素。 重构还是重写？业务案例 要准确判断这个问题，你应该立足于对系统最终运行状态的预期，根据如何从当前状态逐步推进到最终的构建结果，勾勒出一个实施路线图。 首先，如果工作根本无法完成，那么应该考虑重写。显然，将COBOL等绿屏数据库应用程序转换成iPhone上的《愤怒的小鸟》几乎是不可能的，所以直接编写预期的应用程序更为科学。 如果你能总结出一个比较清晰的改造路径，那么请梳理一下改造相关的步骤和需要重写的组件。另外，尽可能引入基于项目规模的敏捷的概念——具体来说，不要执着于完成每项任务需要多少工时，而是比较具体的规模。如果“构建数据访问层”需要3个时间单位，那么“解耦所有GUI依赖项”也需要3个时间单位或更长？总之，不要考虑具体的时间，而是关注相对的复杂度。 这样的实用想法可以帮助您及早进行完整性检查。当然，之后还会有中断时间、人员状况、执照费用等问题影响任务的进行。另外，你还需要通过fan-in、coupling等指标来论证实现转型的难度。 但至少在起步阶段，我们找到了正确的前进方式。一旦解决了“重写或重构”问题，剩下的就是调整大小等可以逐步处理的任务。【翻译稿件，合作网站转载请注明原译者和出处.com】
