重构的成本是否超过了重写的成本？答案

【问题标题】：Is there a point where cost of refactoring outweighs the cost of re-writing?重构的成本是否超过了重写的成本？
【发布时间】：2009-02-23 10:01:41
【问题描述】：

在我目前的工作地点，我们有一些非常令人震惊的代码被吹捧为下一代框架。

问题是，只有一个人有这种观点，而且是写了大部分观点的那个人。该部门的其他人都认为它编码很糟糕，需要调试的皮塔饼，一般来说有点不合时宜。

写这篇文章的人在管理层有一个相当有影响力的职位，所以他们在阵营的那一边。

我们已经向管理层强调了（真正的）顾虑，但显然他们不愿意将更多时间投入到对底线没有直接贡献的项目上。

在此框架上部署了多个应用程序，因此任何重构都需要包含这些应用程序。

整个事情是如此交织在一起，以至于我们不能只是撕掉一个特定类的实现并以这种方式重写它，所以即使对核心 api 进行简单的更改也意味着一个大型项目。

然而，它确实有 3 年的实时部署和许多错误修复、极端情况和边界条件。

考虑到这将是几个大型项目，我们是分部分重写并尝试重构，随着时间的推移进行重构，这可能需要另外 3 年的时间才能形成，还是我们只是重写我们的特定需求现有框架？

【问题讨论】：

【解决方案1】：

重写一些东西几乎是一个普遍的坏主意——你花了几个月的时间工作，直到你完成之前没有任何东西可以展示。这假设您不会成为第二系统效应的牺牲品，并且您实际上确实完成了。

重构几乎肯定是正确的答案。我没有任何重构 PHP 的经验（我做 C++ 和 C#），所以我不能提供任何具体的建议。你必须从小步骤开始。

但是：不要放弃一切来重写代码。逐步重构。它会让你慢一点，但你仍然会在你前进的过程中创造价值。

请参阅this article，这将帮助您向管理层解释技术债务。它还将解释为什么他们似乎不在乎。

【讨论】：

【解决方案2】：

重写的好处是你可以在分析阶段考虑所有新的东西，创建一个更适应当前需求的模型。另一方面，如果它只是糟糕的编码，而不是糟糕的设计，那么完全重写是没有意义的。只需清理/重构代码即可。

【讨论】：

接口真的很糟糕并且有交叉问题（例如，auth 知道它的调用上下文）。一些公共方法最多需要 15 个参数，因为它们是公共的，我们不能在没有对 500Mb 代码库进行全面影响分析的情况下更改它们:(

【解决方案3】：

这是一个非常艰难的决定......

我在这里看到的问题是，该框架被使用和修复了很长时间，因此其中包含了很多知识，并且正在运行的项目的质量显然是可以接受的。所以如果你用你知道的所有要求从头开始重写它——你可以肯定你会忘记一些已经奏效的东西（很难向客户或你的老板解释这一点；））

重构它——它认为——也是一项艰巨的任务，因为只有一个人真正了解代码中的联系——他不想改变它......

有三个选项：

无论你怎么说 - 这对每个人来说都是一个糟糕的情况......因为随着时间的推移，负责框架的人将不得不自己处理它，然后可能为时已晚。

【讨论】：

【解决方案4】：

在一个小层面上，是的：提供一个新版本的函数，验证它是否适用于新版本以及旧版本，删除旧版本。这通常比重构函数本身要快得多。但在那个层面上，它正在重构:)

重写的战略成本几乎总是超过重构。

您无法交付。在开发新版本时，您必须维护旧版本。如果财务说您必须终止重写项目，那么您一无所获-您的工作代码库处于糟糕的状态，就好像什么都没做一样。可能更糟，因为所有更改都被拼凑起来，因为“无论如何我们都会在重写完成时将其丢弃”。

是的，可以构建更便宜的重写场景：

不过，经验表明，代码不好是有原因的，而且编码人员并不总是如此，如果您不识别并更改原因，重写将是重复历史的练习。

【讨论】：

【解决方案5】：

重写是非常冒险的。您将用尚未调试的新代码替换调试良好的旧代码。这将引入大量错误，您必须修复它们。最好逐步重构 - 首先非常详细地了解某些部分的用途，然后重构它。这样，您替换的代码更少，并降低了引入太多新错误的风险。

【讨论】：

【解决方案6】：

补充已经说过的内容：尝试获得管理层的支持。重构时有的底线好处 - 编程新功能的工时将随着时间的推移而减少而不是增加，从而导致工资成本降低，并且可能还会降低服务器成本。如果您的管理人员都没有理解为什么重构是值得的并且会让您更快乐地工作，那么您是否在正确的地方工作？

【讨论】：