架構重構的一般步驟和注意事項---學習筆記

同樣是筆記摘錄自---極客時間 李運華 《從0開始學架構》。   

           系統的架構是不斷演化的，少部份架構演化可能需要推倒重來進行重寫，但絕大部份的系統是通過架構重構來實作的。相比全新系統的架構設計，重構的特殊困難主要展現在：1、業務已經上線，必須保證其正常（至少是照舊，不能更差）運作 2、關聯方衆多，至少已經有使用者在用、運維人員、老闆等已經關注；3、新架構必然受到原有架構限制：例如必須考慮舊架構的資料重用或遷移、既有的一些組織結構和人員工作習慣。

          所有演化架構的步驟：

1、梳理問題，做到有的放矢。

首先收集系統存在的問題，這一步一般簡單，會采到一堆問題，不然就不用重構了；關鍵是接下來要把問題進行歸類，分析出來關鍵的和需要重點解決的。當然一些問題應該通過優化解決；一些問題是必須采購擴容的；最後一般最難啃的就是要動架構的。把這些架構重構的羅列出來，但别期望一次性解決所有問題。找出最關鍵的，一般一次重構周期不要超過3個月。可以通過不斷演化來逐漸解決問題。

2、溝通協調，争取資源支援。

這就是一個合縱連橫的事情，要讓相關方同意架構重構這件事情，讓大家聽得明白、看得到好處、幹得心甘情願。

3、分步實施，階段展現效果。

其實就是前面說的，不要期望一次性解決所有問題，要每一步都讓人看到成果。政策如下：

3.1.優先級排序

将明顯且又比較緊急的事項優先落地，解決目前遇到的主要問題。例如，架構重構前，先做一些基礎性的優化。不要讓系統隔三差五出大問題，導緻重構項目組的人要同時話費大量的人力和精力去救火，而沒法集中精力做重構的事情．

3.2. 問題分類

将問題搜照性質分類，每個階段集中解決一類問。 例如，X 系統的第二階段，我們将多個底層 系統切換到公司統一的公共元件，提到整體可用性．

3.3. 先易後難

一般不建議一上來就解決最難的問題，原因是：

• 一開始就做最難的部分，會發現想要解決這個最難的問題，要先解決其他容易的問題．
• 最難的問題解決起來耗時都比較麻煩，占用資源比較多，不容易出成果，時間長了，會影響相關人員對項目的評價和看法，也可能影響團隊士氣．
• 剛開始的分析并不一定全面，是以一開始對最難的或者最關鍵的事項的判斷可能會出錯

而先易後難恰恰有相對的好處：容易見成果，提升士氣，形成正回報。而且有些問題在逐漸演進中消失了。

3.4.循序漸進

       按照前 3個步驟劃分了架構重構的實施階段後，就需要評估和重新劃分工作量。一般盡量把不同階段的工作計劃分解均勻， 

按照固定的步驟和節奏，更有利于項目推進 。建議每個階段在1~3個月，如果評估超過 3個月的，那就再拆為更多階段。每個階段還可以劃分任務子集，當任務子集比較小的時候，多個任務子集可以并行；當任務子集比較大的時候，就當成一個獨立的裡程碑推進。其實有點類似SCRUM的以周為機關的工作。