在軟體開發的曆史上有很多公司試圖重寫應用,最後大部分都失敗了。回到2000年,Netscape公司決定重寫整個4.0的軟體架構并更新到6.0。整整花了三年的時間完成這份工作,然後就在這段時間,Microsoft憑借着IE悄悄的進入了浏覽器市場最後侵占了本屬于Netscape的大半江山。後面的幾年裡,Netscape漸漸的銷聲匿迹了。
Microsoft同樣也犯過這樣的錯誤,當年微軟試圖想用一款神秘的項目叫做“Pyramid”來代替現在的Word。經過了幾年的開發之後,他們意識到,這是一個完全失敗的項目,最終終止了開發。幸運的是他們仍然在開發Word,并繼續不斷的釋出新版本。
最近,一個私營的小公司叫做Macromates,該公司開發了一款很成功的文本編輯器産品叫做TextMate,他們決定重寫已有的應用并更新到TextMate 2。這項決定出乎意料的花了整個開發團隊六年的時間才釋出了第一個beta版,在這六年内,TextMate損失掉了大學分的市場。當他們釋出beta版後,他們意識到産品釋出得太遲了已經不能扭轉乾坤了,大勢已去,六個月後,TextMate 2出現在 Github上,走上了開源之路。

快速的釋出版本,響應市場變化,抓住核心客戶比重寫軟體為了加入更多的功能好得多。第一, 市場變化快,競争激烈,産品必須能對這些變化做出快速的調整,并指定出解決方案。第二,滿足使用者增量式的需求,間歇性短周期的釋出産品來穩住使用者比抛棄使用者很長一段時間閉門造車好得多。最後,完成大項目需要的時間總是比預期的藥廠,長期的等待,缺陷的積壓可能會讓使用者越來越失望,怎麼給使用者解釋為什麼需要那麼長的時間,怎麼解釋使用者為什麼值得等新産品的釋出。
重寫應用可能導緻的一個經典的誤區就是畫蛇添足。開發第二個系統的設計師設計出來的系統是最危險的,一種普遍傾向是過分地設計第二個系統,向系統添加很多修飾功能和想法,來代替已有的系統功能。
設計人員在完成目前任務之前計劃了一些事情,試圖在“最後一次”完成所有的事情,就這樣周而複始的,項目任務不斷的推遲。這不僅影響到了開發人員,還設計到了所有的設計人員。所有的不利因素在重寫應用的過程中發生,能抵擋得住這些消極的因素嗎 ?
作者尼爾·岡頓認為有三個因素可以決定你是否需要做重寫:
1. 人力
2. 新特性在舊版本不相容的厲害程度
3. 有多少人樂意使用舊版本,有多少人會被應用更新影響
考慮這些因素,你就可以很清楚的認識到是否需要重新應用。把它看成是一個活的有機體,這也許可以被恢複,而進化的。您可以重構,您可以重寫部分的内部結構以讓它能夠更好工作,在不放棄現有的功能和缺陷的情況下,許多事情也可以實作并融入到目前的代碼。當你試圖重寫應用的時候你就是在大部分的否定現有的應用,并試圖抛棄它。 說得好。
git了一個,編譯。奉上 編譯好的 程式檔案:
TextMate