经典难题解析：重写还是重构？

在处理遗留应用时，到底重写更好还是重构更好?对于二者间的具体取舍，Erik Dietrich作为技术作家给出了自己的观点。

重写 还是 重构?

“我们已经拥有基础应用，但很难决定到底对其进行重写还是重构?”相信很多朋友都面临着这样的困扰。

事实上，几乎每一位CIO、开发主管乃至董事会成员都需要处理这类问题。Erik Dietrich就此收集并整理了大量数据，希望帮助大家在重写、淘汰、重构乃至重新设计等选项当中找到最适合自己的解决办法。

用对“术语”

首先，我们把这个问题进行简化。一款应用程序已经陈旧、笨重甚至开始出现故障，这时大家该怎么办?是将其丢弃、注销还是重新开始?又或者，大家打算以更为简洁、现代且可行的方式对其进行再次建模?无论如何，这里首先纠正一点——最后一种办法并不属于“重构”。

概括地讲，“重构”代码的基本定义是在不改变代码外部活动特征的前提下进行结构重塑。举例来说，选取一种大型方法并从中提取部分代码添加至另一方法。但如果大家想用“重构”来代表“重写”，请注意，二者指的并不是同一种处理办法。

假设大家拥有一套陈旧的Web表单应用，其中包含粗糙的代码且逻辑本身将GUI与数据库绑定在一起。更糟糕的是，大家可能使用了某些早已信用的支付处理库，意味着其无法被更新至.NET 2.0以上版本。在这种情况下，“重写还是重构”问题的实质并非“我是否应当对应用中的某些代码进行调整或者重写”，而是“我是否应当对其进行替换或者重写”。

在此为例，重构发生在持续性且规模相对较小的基础之上。如果大家对构成项目中的某些部分进行替换，那么软件本身也将发生改变。这意味着大家会改变其与数据库的交互方式、更换依赖关系乃至更新代码框架等等。这实际上属于对应用程序的改造。

改造?还是 重写。

立足于此，我们可以更进一步审视问题。

企业不应负担太多技术债务，导致开发者无法有效完成应用重写。如果开发者由于原本的烂摊子而不得不选择从零开始，那么企业本身必须为此承担责任。因此，如今我们说起重写时，提到的其实是正常且应当定期进行的应用更新调整举措。在这种情况下，开发团队应当积极学习如何清理并推动软件更新。

但面对同样的背景，有些团队会选择从零开始，而有些则更倾向于进行重写——为什么会出现这样的区别?

之所以选择重写，可能是因为软件一直运行在早已过时的硬件之上，或者其依赖于早已落伍的软件。这意味着该软件可能在根本上与现有架构之间无法交互。

无论实际情况如何，我们都可以将答案简单归结为：如果改造成本比从零开始更高，则选择重写。因此，价值判断就成了最为核心的决定因素。

重构还是重写?商业案例

要准确判断这个问题，大家应当立足于系统的最终运行状态预期，并根据如何从当前状态起步逐渐推进至最终构建结果勾勒出实施路线图。

首先，如果这项工作根本无法完成，那么大家应当考虑重写。很明显，把COBOL这类绿屏数据库应用转化为iPhone上的“愤怒的小鸟”几乎是不可能的，因此直接编写预期应用更为科学。

如果能够归纳出较为明确的改造途径，那么请整理出改造相关步骤与需要重写的组件。另外，尽可能立足于项目规模引入敏捷化概念——具体来讲，不要纠结于各项任务需要多少个工时才能完成，而应比较具体规模。如果“构建一套数据访问层”需要3个时间单位，那么“解耦全部GUI依赖性”同样需要3个时间单位还是更长一些?总之，不要考虑具体时间，而应着眼于相对复杂程度。

这样的实践思路能够帮助大家提早进行完整性检查。当然，在此之后还会有中断时间、人员状态以及许可费用等问题给任务推进造成影响。另外，大家还需要通过扇入及耦合等指标论证改造的实施难度。

但至少在起步阶段，我们已经找到了正确的推进思路。“重写还是重构”的问题解决之后，接下来余下的将只是规模调整之类能够按部就班处理的任务。