【发布时间】：2010-10-11 13:33:59
【问题描述】：
假设您有一个程序当前按应有的方式运行。该应用程序背后的代码非常糟糕，占用大量内存，不可扩展，并且需要大量重写才能实现功能上的任何更改。
在什么时候重构变得比完全重建更不合逻辑？
【问题讨论】：
标签： refactoring scalability maintainability rebuild
【发布时间】：2010-10-11 13:33:59
【问题描述】：
乔尔就这个话题写了一篇很好的文章：
Things You Should Never Do, Part 1
我从中学到的关键教训是，虽然旧代码很糟糕，会伤害您的眼睛和审美意识，但很有可能很多代码都在修补未记录的错误和问题。即，它嵌入了很多领域知识，你很难或不可能复制它。你会经常遇到遗漏的错误。
Michael C. Feathers 的《Working Effectively With Legacy Code》是我发现非常有用的一本书。它提供了处理真正丑陋的遗留代码的策略和方法。
【讨论】：
-
Fred Brooks 说要“构建一个扔掉” - 但他没有使用敏捷技术，并且添加的任何功能都被记录和理解，因此可以毫无损失地重写。
-
更不用说，在您草拟大项目时，您需要实施的细节总是远远多于您没有想到的。
重构优于重构的一个好处是，如果您可以逐步进行重构，即以增量方式进行重构，您可以在整个系统的上下文中测试增量，从而加快开发和调试速度。
旧的和部署的代码，即使是丑陋和缓慢的，也有经过彻底测试的好处，如果你从头开始，这种好处就会失去。
增量重构方法还有助于确保始终有可交付的产品可用（并且不断改进）。
网上有一篇关于how Netscape 6 was written from scratch and it was business-wise a bad idea的好文章。
【讨论】：
嗯，最简单的答案是，如果重构比重建需要更长的时间，那么你应该重建。
如果它是一个个人项目，那么无论如何您都可能希望重新构建它，因为您可能从零开始构建而不是从重构中学到更多，这是个人项目的一大目标。
但是，在专业的限时环境中，从长远来看，您应该始终选择花费公司最少的钱（为了相同的回报），这意味着选择花费更少的时间。
当然，它可能比这更复杂一些。如果其他人可以在重构完成时处理功能，那么这可能是一个更好的选择，而不是让每个人都等待构建一个全新的版本。在这种情况下，重建可能比只是重构花费的时间更少，但您需要考虑整个项目和项目的所有贡献者。
【讨论】：
当您花费更多时间进行重构而不是实际编写代码时。
【讨论】：
在软件没有做它应该做的事情的时候。当且仅当功能“符合预期”时，重构（更改代码而不更改功能）才有意义。
【讨论】：
如果您有时间完全重建应用程序，不需要逐步改进功能，并且不希望保留任何现有代码，那么重写无疑是一种可行的选择。另一方面，您可以使用重构来进行增量重写，方法是用编写更好、效率更高的等效函数慢慢替换现有函数。
【讨论】：
如果应用程序非常小，那么您可以从头开始重写它。如果应用程序很大，永远不要这样做。逐步重写它，一次一步验证你没有破坏任何东西。
应用程序是规范。如果你从头开始重写它，你很可能会遇到很多隐蔽的错误，因为“没有人知道在那种非常特殊的情况下，对该函数的调用应该返回 3”（未记录的行为......）。
从头开始重写总是更有趣，因此您的大脑可能会欺骗您认为这是正确的选择。小心，很可能不是。
【讨论】：
我过去曾使用过此类应用程序。我发现最好的方法是循序渐进的：当你编写代码时，找到多次完成的事情，将它们组合成函数。保留一个笔记本（你知道，一个真正的，有纸，铅笔或钢笔），这样你就可以标记你的进步。将它与您的 VCS 结合使用，而不是代替它。 Notebook 可用于概述您在重构过程中创建的新功能，VCS 当然会为详细信息填补空白。
随着时间的推移，您会将大量代码合并到更合适的位置。在这段时间内重复代码几乎是不可能的，所以尽你所能做到最好，直到你可以真正开始重构过程，审计整个代码库并作为一个整体进行工作。
如果您没有足够的时间进行该过程（这将花费很长时间），那么使用测试优先的方法从头开始重写可能会更好。
【讨论】：
一种选择是编写单元测试来覆盖现有的应用程序，然后开始一点一点地重构它，使用单元测试来确保一切都像以前一样工作。
在理想情况下，您已经对程序进行了单元测试，但考虑到您对应用程序质量的评价，我猜您没有...
【讨论】：
没有文档，没有原创作者，没有测试用例，还有一堆遗留的错误。
【讨论】：
Uncle Bob weighs in 带有以下内容：
什么时候重新设计才是正确的策略？
很高兴你问了这个问题。这是答案。 从不。
看，你弄得一团糟，现在清理它。
【讨论】：
当我继承的代码非常糟糕时，我对小的增量更改不太幸运。从理论上讲，小增量方法听起来不错，但在实践中，它最终得到的只是一个更好但设计不佳的应用程序，每个人都认为现在是你的设计。当事情破裂时，人们不再认为是因为以前的代码，现在它变成了你的错。所以，我不会使用重新设计、重构或其他任何暗示经理类型你正在按照自己的方式改变事情的词，除非我真的要按照自己的方式去做。否则，即使您可能已经解决了数十个问题，任何仍然存在（但未发现）的问题现在都将归因于您的返工。请放心，如果代码不好，那么您的修复将发现更多以前被忽略的错误，因为代码一开始就很糟糕。
如果您真的知道如何开发软件系统，那么我会重新设计整个系统。如果你真的不知道如何设计好的软件，那么我会说坚持小的增量更改，否则你可能会得到一个和原始代码库一样糟糕的代码库。
重新设计时经常犯的一个错误是人们忽略了原始代码库。但是，重新设计并不一定意味着完全忽略旧代码。旧代码仍然必须执行新代码必须执行的操作，因此在许多情况下，您需要的步骤已经在旧代码中。复制和粘贴然后调整在重新设计系统时会产生奇迹。我发现在许多情况下，重新设计和重写应用程序并从原始代码中窃取 sn-ps 比小的增量更改要快得多且可靠得多。
【讨论】：