前言
近期面對許多陳舊代碼維護的問題，碰巧我翻找到這個部落格：Understand Legacy Code，紀錄一下「重寫」陳舊系統可能會遇到的困境與解套方案。以我自己手上的專案為例，在進行專案升級評估時發現事情比原先想像還要複雜！
- 框架版本升級：說好的向後兼容呢？版本一換代碼風格與架構全都要改，舊版本的套件框架將被永遠拋棄。
- 不存在的文件：因為太匆忙了沒有時間紀錄文件，「學習」累積成為每個團隊成員必經的痛，上手專案之前都要消化大量的學習債務。
- 根深蒂固的反模式：錯誤的開發模式已經深植到成為整個專案的文化，現有的反模式也容易造成破窗效應的發生。
總之到達一個無法回頭的地步，或許只剩下重寫這個高風險的選項，因為……
- 程式間耦合性過高牽一髮動全身…
- 無測試或難以被測試…
- 重寫都比重構還要低成本…
- 專案再也承受不起變化…
於是你踏上了專案重寫的道路。
重寫專案的陷阱
- 你跟管理層討論了停止推出新功能的策略，用這段時間重寫現有的應用程式。
- 你估計重寫將需要 6 個月的時間來覆蓋現有應用程式的功能。
- 幾個月後，發現了嚴重的錯誤，絕對需要在舊代碼中進行修復。因此，你修補了舊代碼和新代碼。
- 幾個月後，一個全新的功能被銷售給客戶，但由於新版尚未準備好，只能先在舊代碼中實現，並且也要在新版本中添加此功能。
- 經過 5 個月，你意識到項目將延遲。舊應用程式做了比預期多得多的事情。你開始更加努力。
- 經過 7 個月，你開始測試新版本。QA 提出了很多應該修復的問題。
- 經過 9 個月，業務無法忍受「不開發功能」的狀況了。領導層對這種情況感到不滿，你感到很疲憊。你開始對令人痛苦的舊代碼進行更改，同時努力跟上重寫進度。
- 最終，你們在生產環境中擁有了兩個系統。長期目標是淘汰舊系統，但新系統還沒準備好。每個功能都需要實現兩次。
故事中重寫造成兩套完全獨立的系統，可以想像重寫在這個例子當中帶來多大多沉重與負擔。
忒修斯之船模式
如果船舶部件隨著腐爛而逐步更換，那麼船舶完全更換後還是原來的船嗎？先不討論哲學，這種做法的觀點在於漸進的替換重寫片段，代表更快的反饋、更少的工作（至少更少的心理負擔）以及避免失去功能！
- 讓新代碼作為舊代碼的代理，用戶使用新系統只是導向到舊系統中。
- 逐步實踐舊代碼的行為到新代碼當中
- 漸進的淡出舊代碼，取代上新代碼
總結
我們對重寫的概念通常是「打掉全部重做」，但這麼做過於理想化，並且在有些規模需要重寫的專案上，這樣的做法可能會讓專案陷入無底深淵。退一步思考，並重新審視重寫的最終目的，忒修斯之船模式是簡單但極容易被忽略的選項。
延伸閱讀
- The Ship of Theseus to NOT rewrite a legacy system from scratch - Understand Legacy Code
- 面對 Legacy Code ，該重構還是重寫？ - 網站製作學習誌