在我目前的工作地点，我们有一些令人震惊的代码被吹捧为下一代框架。
事实上，这个意见中只有一个人就是那个写了大部分内容的人。该部门的其余部分给人的印象是编码错误，调试的皮塔饼和一般的naff。写这篇文章的人对管理层有很大的影响力，所以他们就在营地的那一边。
我们已向管理层强调（真实）关注，但显然他们不愿意花更多时间参与一项不会直接影响盈利的项目。
此框架上部署了多个应用程序，因此任何重构都需要包含这些应用程序。
整个事情是如此交织在一起，以至于我们不能扯掉特定类的实现并以这种方式重写它，所以即使对核心api进行简单的更改也意味着一个大项目。
然而，它确实有3年的实时部署和许多错误修复，角落案例和边界条件。我们是否重写部分并尝试重构，因为这将是几个大型项目，随着时间的推移重构，可能需要3年才能完成它或我们只是重写我们的特定要求在顶部现有框架？
答案 0 :(得分：5)
重写一些东西几乎是一个坏主意 - 你花了几个月的时间工作，在你完成之前没有任何东西可以显示。并且假设您不会成为第二系统效应的牺牲品，并且您实际上做完成。
重构几乎肯定是正确的答案。我没有任何重构PHP的经验（我做C ++和C＃），所以我不能提供任何具体的建议。你必须继续婴儿步骤。
但是：不要放弃所有内容来重写代码。逐渐重构。它会让你慢下来，但随着你的进展，你仍然会提供价值。
请参阅this article，以帮助您向管理层解释技术债务。它也解释了为什么他们似乎并不关心。
答案 1 :(得分：1)
重写的优点是您可以在分析阶段考虑所有新内容，创建更适合当前需求的模型。另一方面，如果它只是编码错误，设计不是很糟糕，那么完全重写是没有意义的。只需清理/重构代码即可。
答案 2 :(得分：0)
这是一个真正艰难的决定......
我在这里看到的问题是，框架已经使用并修复了很长时间，所以有很多知识进入它，并且运行项目的质量显然是可以接受的。所以，如果你从头开始重写它，你知道所有要求 - 你可以肯定你会忘记已经有效的东西（很难向客户解释 - 或者你的老板;）重构它 - 它认为 - 也是一项艰巨的任务，因为只有一个人真正了解代码中的连接 - 谁不想改变它......
有三种选择：
无论你是哪种方式 - 这对每个人来说都是一个糟糕的情况......因为随着时间的推移，负责框架的人将不得不自己处理它，然后可能为时已晚。
答案 3 :(得分：0)
在一个较小的层面上，是的：提供一个新版本的函数，验证它是否适用于新版本以及旧版本，删除旧版本。这通常比重构功能本身要快得多。但在那个层面上，它正在重构：）
重写的战略成本几乎总是超过重构。
你无法交付。在开发新版本时，您必须维护旧版本。如果财务状况说你必须杀掉重写项目，你就什么也没做到 - 你的工作代码库状况不好，好像什么都没做过。可能更糟糕的是，因为所有的变化都被克服了，因为“当重写完成时我们会抛弃它”。
可以构建重写更便宜的场景：
尽管如此，经验表明代码是有原因的，并且它并不总是编码员，当你不识别和改变原因时，重写将是重复历史的练习。
答案 4 :(得分：0)
重写风险很大。您将使用尚待调试的新代码替换旧的经过良好调试的代码。这将引入大量的错误，你将不得不修复它们。逐渐重构更好 - 首先要非常详细地了解某些部分的用途，然后重构它。这样就可以替换更少的代码并降低引入太多新bug的风险。
答案 5 :(得分：0)
添加已经说过的内容：尝试并获得管理层的支持。当你重构时， 有利于底线 - 编程新功能的工时会随着时间而不是上升而下降，从而降低工资成本和服务器成本。如果您的管理层都不了解为什么重构是值得的，并且会让您更快乐地完成工作，那么您是否在正确的地方工作？