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