實現的妥協
記得剛開始工作那會，也正好是項目剛起步不久，我總是覺得公司原有的代碼髒亂差，架構混亂，完全不符合我們在書上看到的標準。一直有把項目代碼重構一番的念頭。
工作幾年後開始逐漸明白了一個道理，寫代碼不是造藝術品。代碼的本質是功能的實現，在bug可控，能滿足用戶需求的前提下，其實並不需要那麼完美。
打造完美的代碼是需要成本的，在項目前期，人少活多，一個人頂三個人用，怎麼也寫不出花樣來。這個階段主要的目標就是儘快實現功能，搶佔市場。那在設計和實現上必然會有妥協。
該不該重構
當你想重構現有代碼的時候，需要問自己三個問題
- 重構的目的是什麼？
爲了換新框架增長技能還是對項目真的有益 - 現有的架構是否嚴重的制約了後續功能的開發和性能支撐？
如果是，那重構就非常有必要。在項目進行到某一階段的時候，由於產品的策略調整，會帶動功能在原有的基礎上有較大改動。如果現有架構無法滿足新策略，那麼就到了必須要重構的時候。但前提是重構後的代碼結構確實要優於現有的，所以重構前要做充分的評審。 - 是否有時間，有人力去重構？
即使滿足上面的第一條件，但是項目上根本就不給足夠的時間和人員去做這個事情，那也是無法完成的。從新架構的設計到評審，需要花費很多的時間。在重構的過程中，還得將原有的功能保質的遷移過來，又得花費很多的時間。後面還得加上回歸測試的時間等等。這些成本的消耗，老闆是否買單呢？
重構是一個比較重大的決定，牽扯到項目的方方面面。不是可以由技術人員單方面去決定是否能重構的。當然，如果真的很閒，重構不失爲一個充實工作，提升技術的好方式。
如何實施重構
決定重構後，如何實施？
從我個人的實踐經驗來看，代碼重構需要提前規劃和佈局，才能優雅的進行。項目技術負責人需要儘量提前預知在未來什麼節點下，當前的架構無法滿足業務，並提前協調資源開始規劃重構。整個過程可以有以下兩種模式：
- 整體重構，一氣呵成。將團隊分成AB組，A組繼續在當前分支開發，滿足業務發版本的需求。B組負責在新分支上在新架構的基礎上開發並遷移舊功能。當B組的功能完成並測試通過過，AB組合並，在新架構上開發。
- 局部重構，小步前進。在項目的新功能採用新架構，同時兼容舊功能。在產品迭代的過程中按功能模塊逐步遷移舊功能。
上面的方法不一定適用在所有的項目組，具體情況還得具體分析。