實現的妥協
記得剛開始工作那會，也正好是專案剛起步不久，我總是覺得公司原有的**髒亂差，架構混亂，完全不符合我們在書上看到的標準。一直有把專案**重構一番的念頭。
工作幾年後開始逐漸明白了乙個道理，寫**不是造藝術品。**的本質是功能的實現，在bug可控，能滿足使用者需求的前提下，其實並不需要那麼完美。
打造完美的**是需要成本的，在專案前期，人少活多，乙個人頂三個人用，怎麼也寫不出花樣來。這個階段主要的目標就是盡快實現功能，搶占市場。那在設計和實現上必然會有妥協。
該不該重構
當你想重構現有**的時候，需要問自己三個問題
重構的目的是什麼?
為了換新框架增長技能還是對專案真的有益 現有的架構是否嚴重的制約了後續功能的開發和效能支撐?
如果是，那重構就非常有必要。在專案進行到某一階段的時候，由於產品的策略調整，會帶動功能在原有的基礎上有較大改動。如果現有架構無法滿足新策略，那麼就到了必須要重構的時候。但前提是重構後的**結構確實要優於現有的，所以重構前要做充分的評審。 是否有時間，有人力去重構?
即使滿足上面的第一條件，但是專案上根本就不給足夠的時間和人員去做這個事情，那也是無法完成的。從新架構的設計到評審，需要花費很多的時間。在重構的過程中，還得將原有的功能保質的遷移過來，又得花費很多的時間。後面還得加上回歸測試的時間等等。這些成本的消耗，老闆是否買單呢?
重構是乙個比較重大的決定，牽扯到專案的方方面面。不是可以由技術人員單方面去決定是否能重構的。當然，如果真的很閒，重構不失為乙個充實工作，提公升技術的好方式。
如何實施重構
決定重構後，如何實施?
從我個人的實踐經驗來看，**重構需要提前規劃和布局，才能優雅的進行。專案技術負責人需要盡量提前預知在未來什麼節點下，當前的架構無法滿足業務，並提前協調資源開始規劃重構。整個過程可以有以下兩種模式：
整體重構，一氣呵成。將團隊分成ab組，a組繼續在當前分支開發，滿足業務發版本的需求。b組負責在新分支上在新架構的基礎上開發並遷移舊功能。當b組的功能完成並測試通過過，ab組合並，在新架構上開發。 區域性重構，小步前進。在專案的新功能採用新架構，同時相容舊功能。在產品迭代的過程中按功能模組逐步遷移舊功能。
上面的方法不一定適用在所有的專案組，具體情況還得具體分析。
關於重構（三）
今天不是太忙就索性將何為重構一併講完！上一節我們講到，為何重構？重構的好處 優點？我們接著將什麼是重構？其實這一解釋應該放在最前面，其實從我們上學開始都是這麼學習的，先說這是個什麼東東，然後再去說這個東東的優點，為什麼用它？為什麼我沒有這麼做？因為我就想不按常理出牌 自己yy一下，其實自我感覺我們打...
重構之維 關於重構及《重構》的隨想
重構之維 關於重構及 重構 的隨想 重構 究竟重構了什麼？不止一次地，我聽到我們這個行業裡的大師們對重構技術提出 至少是 置疑 那是我們過去十五年裡一直在做的事 我從 上世紀 70年代就已經開始這樣做了 unix上的黑客們一直都是這樣做的 這些說辭讓我很有興趣探其究竟。在這本 重構 裡，martin...
關於軟體工程文件解析
軟體工程文件主要涉及到軟體文件管理指南 計算機軟體產品開發編制指南和計算機軟體需求說明編制指南。把軟體開發過程中的一些 不可見的 事物轉 換成 可見的 文字資料。以便管理人員在各個階段檢查開發計畫的實施進展，使之能夠判斷原定目標是否已達到，還將繼續耗用資源的種類和數量 軟體文件可分為開發文件 產品文...