在什么时候重构变得不值得呢？

Question

假设您有一个当前以预期方式运行的程序.该应用程序背后的代码非常糟糕,占用大量内存,不可扩展,并且需要进行大量重写才能实现功能上的任何更改.

在什么时候重构变得不那么合乎逻辑了？

Answer 1

乔尔写了一篇关于这个话题的好文章:

我从中得到的关键教训是,虽然旧代码很糟糕,会伤害你的眼睛和你的美感,很有可能很多代码都修补了无证错误和问题.也就是说,它嵌入了很多领域知识,你很难或不可能复制它.你会不断地打击遗漏的错误.

我发现一本非常有用的书是Michael C. Feathers 有效地使用遗产代码.它提供了接近甚至真正丑陋的遗留代码的策略和方法.

Answer 2

重用代码的修改特别容易出错.如果要修改超过20%到25%的组件,从头开始编写它会更有效率.

Answer 3

重构重建的一个好处是,如果您可以逐步进行重构,即以增量方式进行重构,则可以在整个系统的上下文中测试增量,从而加快开发和调试速度.

旧的和部署的代码,即使在丑陋和缓慢的情况下,也具有彻底测试的好处,如果从头开始,这种好处就会丢失.

渐进式重构方法还有助于确保始终有可用的产品(并且不断改进).