进化或革命来修复写得不好的代码

Question

我已经为我的个人项目做了一些工作，现在我理解为什么人们会告诉我们计划我们所有的接口并在编码之前设计。我有一些好的课程，已经有一些工作代码，但总的来说组织（架构）有点乱，我已经说过“如果我再做一次，我会这样做。 ..“。问题是，我是否应该勾画出一个关于我希望我的代码看起来如何的计划，并将现有代码重构为新模型，或者我是否应该采用有效的方法，并为缺陷部分编写所有新代码（基本上开始）从头开始，从这个项目中获得相当数量的复制和粘贴。）

我有git历史我不确定我想失去，但慢慢重写一切的任务似乎令人生畏。所以我要问的问题是：在重构一个年轻的项目时，是否应该使用进化或革命来使其第二次正确？

Answer 1

重构旧代码（evolution）。重写代码总是会引入您没有想到的问题。我确信现有代码已经有了更新，而且很多更新都是错误修复增强等。您可能不知道为什么当时进行了更改，但是您需要，并且重写代码可以删除所需的更改。

采取小步骤还可以帮助您避免“哦'咒骂'”场景，在这种场景中，您尝试进行一些大规模的更改并遇到一种情况，即它的行为方式与您预期的不同。随着进化，您可以退出更改并仍然拥有一个工作系统，因为架构已经有些最终确定。

Answer 2

你如何解决一个大而蹩脚的项目？那么，你如何清理Augean Stables ......

稳定清洁技术：

1. 如果你是赫拉克勒斯，你就是这么做的 曾经在一个巨大的，呃，华丽的 办法。
2. 如果你不 Hercules，你会抓一把铲子， 并开始慢慢改善事物 一次一个角落。

诀窍是提前识别你是否有足够的力量和能力来解决重写问题。低估自己，你会浪费很多时间趟过粪便。高估了，你只会弄得一团糟......

Answer 3

取决于你的情况 - 如果你有时间重写......并且不那么明显地重新测试一切......把它吹走并重新开始。但要坦诚相信这个时间会是什么样子。

进化通常效果更好 - 因为时间就是金钱，从头开始可以代表巨大的投资......

许多人没有得到的另一点 - 进化实际上可以很好地工作 - 它需要更多的思考......你必须弄清楚如何模块化现有的东西 - 但通常它很可能 - 只是额外的在白板上的时间。

Answer 4

制作一张放在墙上的图表，尝试考虑所有细节。

当您做进行更改时，请尝试了解每项更改如何让您更接近最终目标。如果您在进行更改时想到了这个目标，那么您可以编写和测试与您想要去的地方一致的内容。我经常发现我可以引入一些不那么激进（但必要）的变化，并仍然可以获利。

因此，我提倡进化，但要清楚地了解你想要去的地方。无论如何，你最终会在其他地方结束。

Answer 5

通常情况下，我会使用进化，但步骤很大，两者都有。

Answer 6

你需要比较缓慢重写所有内容（你可能在精神上夸大其词）的任务，以及尝试快速重写所有内容（你可能会严重低估）的任务。不要低估保持工作代码的价值，这是通过逐步重构得到的。

由于您没有描述您的平台，我不知道哪些软件可用于重构支持。例如，Java有很多，但对C ++来说很少。

对你和你的项目几乎一无所知，我建议以更加进化的方式进行重构，并且在你厌恶旧代码之前要相当快地进行重构，或者编写太多依赖于糟糕旧事物的新代码。您可能会发现代码太难以生存并且需要重写;在这种情况下，请继续。

Answer 7

革命的问题是需要很长时间，在此期间不会给最终用户带来任何价值。随着增量变化（演变），可以改进系统并使其始终保持运行。

鲍勃叔叔对此事的看法： http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky

Answer 8

我认为这取决于几个因素：

1. 你有单元测试吗？这支持重构。
2. 原来需要多长时间？一两天要求重写，一两周要重构。
3. 你是否每天都依赖它 - 你需要让它继续运行吗？如果是，重构。如果没有，请重写。
4. 它有多糟糕？如果真的不好，请重写它。

在所有情况下，在开始之前知道你的目标！

（就个人而言，我并不认为你不应该重写这个论点。我也不会认为精心设计的系统完全可以通过重构而产生的论点......）

Answer 9

在Fred Brooks的（释义）单词中，“计划扔掉第一个”。如果您还没有计划这样做，那么无论如何你最终都会把它扔掉。唯一的问题是，经过多少工作？