Rewrite (programming): Difference between revisions

Browse history interactively

← Previous edit

Content deleted Content added

VisualWikitext

Revision as of 12:59, 18 March 2015 edit 193.227.170.194 (talk) →Motivations ← Previous edit		Latest revision as of 14:33, 5 June 2025 edit undo Amire80 (talk \| contribs) Edit filter managers, Administrators 20,560 edits →External links: + academic source Tag: Visual edit: Switched
(34 intermediate revisions by 30 users not shown)
Line 1: {{Short description\|Concept in programming}} A '''rewrite''' in [[computer programming]] is the act or result of re-implementing a large portion of existing functionality without re-use of its [[source code]] or [[writing inscription]]. When the rewrite is not using existing code at all, it is common to speak of a '''rewrite from scratch'''. When instead only parts are re-engineered, which have otherwise become complicated to handle or extend, then it is more precise to speak of [[code refactoring]].▼ {{About-distinguish\|code rewrites, where it is expected that the behavior will change\|Code refactoring}} ▲A '''rewrite''' in [[computer programming]] is the act or result of re-implementing a large portion of existing functionality without re-use of its [[source code~~]] or [[writing inscription~~]]. When the rewrite ~~is not~~uses ~~using~~no existing code at all, it is common to speak of a '''rewrite from scratch'''~~. When instead only parts are re-engineered, which have otherwise become complicated to handle or extend, then it is more precise to speak of [[code refactoring]]~~. the DMS told pms she must do the regula report every quarter and to project what will happen in July. He also said the CFO should show him the draft instructions and make sure that everyone has their tasking orders. ==Motivations== A piece of software is typically rewritten when one or more of the following apply: its [[Orphaned work\|source code is not available]] or is only available under an [[License compatibility\|incompatible]] [[license]] its code cannot be adapted to a new target platform its existing code has become too difficult to handle and extend the task of [[debugging]] it seems too complicated the programmer finds it difficult to understand its source code developers learn new techniques or wish to do a big feature overhaul which requires much change the [[programming language]] of the source code has to be changed ==Risks== Several software engineers, such as [[Joel Spolsky]]<ref name=":0">{{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\|date=6 April 2000 \|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~~}}</ref><ref~~ ~~name~~\| url-status=~~"spolsky">{{cite web~~dead \| ~~url~~archiveurl=https://web.archive.org/web/20081010211819/http://www.~~joelonsoftware~~ronkes.~~com~~nl/~~articles~~blog/~~fog0000000069.html~~?2005-04-15-neverrewritecode \| ~~title~~archivedate=~~Things~~October ~~You Should Never Do \| first=Joel \| last=Spolsky \| authorlink=Joel Spolsky \| date=April 6~~10, ~~2000~~2008 ~~\| accessdate=2008-09-11~~}}</ref><ref name=":0" /> A rewrite also interferes with the tracking of unfixed bugs in the old version.<ref>{{cite web \| url=http://www.jwz.org/doc/cadt.html \| title=Cascade of Attention-Deficit Teenagers \| first=Jamie \| last=Zawinski \| authorlink=Jamie Zawinski \| accessdate=2008-09-11}}</ref> 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> ==Examples== ~~==Notable examples==~~ [[Netscape]]'s project to improve HTML layout in [[Netscape Navigator\|Navigator]] 4 has been cited as an example of a failed rewrite. The new layout engine ([[Gecko (layout engine)\|Gecko]]) had developed independently ~~from~~of Navigator and did not integrate readily with Navigator's code; hence, Navigator itself was rewritten around the new engine, breaking many existing features and delaying release by several months. Meanwhile, [[Microsoft]] focused on incremental improvements to [[Internet Explorer]] and did not face the same obstacles.<ref name="~~spolsky~~:0" /><ref>{{cite web \| url=http://www.jwz.org/gruntle/nomo.html \| title=resignation and postmortem \| first=Jamie \| last=Zawinski \| authorlink=Jamie Zawinski \| date=March 31, 1999 \| accessdate=2008-09-11}}</ref> Ironically, Navigator itself was a successful cleanroom rewrite of [[NCSA Mosaic]] overseen by that program's developers. See [[Browser wars]]. ==See also==▼ [[Code refactoring]]▼ * [[Open source software development]]▼ * [[Technical debt]]▼ * [[Development hell]]▼ * [[Porting]]▼ Some projects mentioning major rewrites in their history: {{~~Multicol~~colbegin}} * [[Apache HTTP Server]] (1) * [[AOL Instant Messenger]] (1) * [[BIND]] (1) * [[Freenet]] (1) * [[Fusebox (programming)\|Fusebox]] (2) * [[GNU GRUB\|GRUB]] (1) * [[Majordomo (software)\|Majordomo]] (1) * [[History of Wikipedia#Hardware and software\|MediaWiki]] (1) * [[History of Mozilla Application Suite\|Mozilla/Netscape]] (1) ~~{{Multicol-break}}~~ * [[Icecast]] (0–1) * [[netcat]] (1) Line 39 ⟶ 41: * [[WebObjects]] (1) * [[Zope]] (1) {{~~Multicol-end~~colend}} == Techniques == * [[Strangler fig pattern]] ▲==See also== ▲* [[Code refactoring]] ▲* [[Open source software development]] ▲* [[Technical debt]] ▲* [[Development hell]] ▲* [[Porting]] * [[Game engine recreation]] * [[Reverse engineering]] ==References== {{reflist\|30em}} ~~<references/>~~ ==External links== * {{Cite journal \|last=Sneed \|first=Harry \|last2=Verhoef \|first2=Chris \|date=2019-09-01 \|title=Re-implementing a legacy system \|url=https://www.sciencedirect.com/science/article/pii/S0164121219301050 \|journal=Journal of Systems and Software \|volume=155 \|pages=162–184 \|doi=10.1016/j.jss.2019.05.012 \|issn=0164-1212}} * [http://www.c2.com/cgi/wiki?RewriteCodeFromScratch RewriteCodeFromScratch at C2 Wiki] * [http://www.joelonsoftware.com/articles/fog0000000069.html Things You Should Never Do, Part I] by [[Joel Spolsky]] [[Category:Computer programming]]