假设您有一个当前以预期方式运行的程序.该应用程序背后的代码非常糟糕,占用大量内存,不可扩展,并且需要进行大量重写才能实现功能上的任何更改.
在什么时候重构变得不那么合乎逻辑了？
乔尔写了一篇关于这个话题的好文章:
你不应该做的事情,第1部分
我从中得到的关键教训是,虽然旧代码很糟糕,会伤害你的眼睛和你的美感,很有可能很多代码都修补了无证错误和问题.也就是说,它嵌入了很多领域知识,你很难或不可能复制它.你会不断地打击遗漏的错误.
我发现一本非常有用的书是Michael C. Feathers 有效地使用遗产代码.它提供了接近甚至真正丑陋的遗留代码的策略和方法.
Robert L. Glass建议这样做
重用代码的修改特别容易出错.如果要修改超过20%到25%的组件,从头开始编写它会更有效率.
重构重建的一个好处是,如果您可以逐步进行重构,即以增量方式进行重构,则可以在整个系统的上下文中测试增量,从而加快开发和调试速度.
旧的和部署的代码,即使在丑陋和缓慢的情况下,也具有彻底测试的好处,如果从头开始,这种好处就会丢失.
渐进式重构方法还有助于确保始终有可用的产品(并且不断改进).
网上有一篇关于Netscape 6是如何从头开始编写的好文章,这在商业上是一个坏主意.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
