Content deleted Content added
m Reverted 1 edit by 2405:204:7187:4C:D9C1:8141:EF24:2001 (talk) to last revision by ToBeFree. (TW) |
|||
Line 15:
==Risks==
Several software engineers, such as [[Joel Spolsky]]<ref>{{cite web|last1=Spolsky|first1=Joel|title=Things You Should Never Do, Part I|url=http://www.joelonsoftware.com/articles/fog0000000069.html|website=Joel on Software|accessdate=2015-01-23}}</ref> have warned against total rewrites, especially under schedule constraints or competitive pressures. While developers may initially welcome the chance to correct historical design mistakes, a rewrite also discards those parts of the design that work as required. A rewrite commits the development team to deliver not just new features, but all those that exist in the previous code, while potentially introducing new bugs or [[Software regression|regressions]] of previously fixed bugs.<ref>{{cite web | url=http://www.ronkes.nl/blog/?2005-04-15-neverrewritecode | title=Never Rewrite Code From Scratch | first=Joost | last=Ronkes Agerbeek | date=April 15, 2005 | accessdate=2008-09-11 |
The incremental rewrite is an alternative approach, in which developers gradually replace the existing code with calls into a new implementation, expanding that implementation until it fully replaces the old one. This approach avoids a broad loss of functionality during the rewrite. [[Cleanroom software engineering]] is another approach, which requires the team to work from an exhaustive written specification of the software's functionality, without access to its code.<ref>{{cite web | url=http://www.perlmonks.org/?node_id=115511 | title=Rewriting, from scratch, a huge code base | first=Ben | last=Tilly | date=September 29, 2001 | accessdate=2008-09-11}}</ref>
|