開發過程當中項目是否須要重構？又須要注意什麼？

重構是須要慎重考慮的，不是拍腦子決定的事情！

1、引言

程序員都有一顆工程師的心，因此當他們到一片新的場地想作的第一件事就是，將舊的一切推倒重來。是的，他們以爲舊代碼異常混亂，由於讀代碼更難，寧願丟掉舊代碼從新寫，也不肯意修修補補，他們認爲舊代碼簡直一團糟。

我以爲這個出發點是好的，但我觀察了很是多的案子，那些重構的項目大多數是失敗的，至關一部份都成了爛尾。他們從頭開始再寫一遍並不意味着會寫出比之前更好的代碼，由於很多人沒有參與到上一個版本的建立，因此其實根本不算有經驗。一旦推倒重寫，可能會再犯一遍版本一犯過的錯，甚至會產生更多的新問題。

2、咱們的項目是否須要重構？

對處於團隊 Leader的我來講，重構考慮的是人力、時間、項目風險等因素，在商業項目中，推倒重來是很是危險的行爲,重寫項目的代碼也是一個異常艱難的決定。固然，若是隻是在作實驗，想到新算法、SDK能夠隨時重寫。

通過慎之又慎的考慮，重構也不是不能夠的，但不是一會兒推翻項目以前的全部代碼，否認一切，你可能不必定會寫出比之前更好的代碼。結合自已的工做經驗（移動端開發經驗），重構主要工做從如下幾個方面展開：

• 刪除沒用到的第三方庫
• 刪除不合理的第三方庫，使用系統自帶的或者本身造輪子
• 刪除定義好可是沒有用到的變量
• 刪除 import 進來可是沒有用到的頭文件
• 刪除更舊項目留下來的用不到的邏輯
• 代碼的結構重構，項目工程、View、Service等層級不合理
• 代碼的效率不高的重構，循環、編譯速度優化
• 代碼寫得很醜的重構，命名不合理
• 內存泄露的重構
• 消除項目中的 warning

3、架構的重構

前面提到重構是慎之又慎的決定，這裏就提到必要性，是否是自相矛盾呢？其實這並不矛盾，而是承上啓下的。隨着應用的不斷髮展，最初的架構每每面臨着各類問題，好比沒法知足客戶的需求、沒法實現應用的擴展、沒法實現新的特性等等。在這種狀況下，咱們如何避免一些坑，儘可能比較成功地實現架構的重構。

3.1 肯定重構的目的和必要性

每一次架構的重構都是「傷筋動骨」，就像作手術同樣，即便再成功，也會傷元氣，因此決策者們首先要分析架構重構的理由和其餘備選方案，明確重構的目的是爲了知足業務需求，而且是不得不作的最佳方案，而後再考慮其餘問題。 有時候，通過分析就會發現，也許還有其餘解決方案，好比增長計算資源，或者重構的目的不是爲了業務需求，那就沒有必要作了。檢查清單：

• 架構重構的緣由是什麼，是爲了知足業務的須要仍是隻是以爲架構很差看？
• 除了架構重構以外，還有其餘備選方案嗎？是否都分析過這些方案的利弊？

3.2 定義「重構完成」的界限

若是肯定要重構，那麼要把目標明確下來，也就是重構的邊界條件，怎麼纔算是「完成」了重構，目標要有數據量化，或者有可以測試的辦法。這也是一個需求分析的過程，若是需求不明確，那麼規格說明書無法寫清楚，負責重構的團隊也沒有明確的目標，不能以重構的時間或者主觀的判斷爲結束的依據。檢查清單：

• 重構的目標能夠量化，或者說能夠測試嗎？
• 重構完成的標準是什麼？獲得業務部門或者領導的承認了嗎？

3.3 漸進式重構

如今軟件研發最流行的就是快速迭代、持續交付、儘早反饋。這一樣能夠用在架構的重構上，重構過程的難度不亞於構建一個新產品，因此在設計重構的時候，要引入持續交付的流程，每個重構步驟或者模塊都要快速部署並獲得反饋，以便評估重構的效果，及時做出策略調整。通過謹慎測試以後，將數據和業務遷移過去。檢查清單：

• 可否把重構過程分紅小的迭代，每一次改進都能儘快獲得反饋？
• 重構過程當中的效果可以按期展現給業務部門或者領導嗎？

3.4 肯定當前的架構狀態

在啓動重構以前，團隊要對當前的架構狀態有清晰的瞭解，也就是設定好基準，以便評估重構的效果。據個人觀察，負責重構的架構師或者開發者，每每尚未搞清楚現有的架構設計，就開始重構了，結果常常出現這樣的狀況：重構到某個階段，發現行不通，而後一拍腦殼說，哦，原來這塊的架構是這個樣的，是爲了達到某某業務需求啊，這塊不能動，得想別的辦法。相似的例子在研發團隊中時有發生，也提醒咱們要慎重當心。檢查清單：

• 你瞭解當前的架構設計嗎？它的設計初衷和以前的選型方案知道嗎？
• 你能給架構設定一個基準狀態嗎？

3.5 不要忽略數據

數據的重要性不言而喻，業務都是以數據流爲載體的，因此架構重構的本質就是對於數據流的重構。數據對重構的重要性主要體如今兩個方面：在重構設計時，須要考慮業務數據的需求，重構以後的系統對於數據的存儲、處理、分析等功能是否有影響；在重構過程當中，考慮依靠數據甚至是實際的數據來驗證重構的效果，提供評估的支持。檢查清單：

• 業務數據的需求在重構設計中有體現嗎？
• 重構過程當中可否經過實際數據來驗證效果？

3.6 管理好技術債務

技術債務在日常的軟件研發過程當中也是比較突出的問題，架構重構每每是爲了償還技術債務，因此請不要在償還技術債務的過程當中製造技術債務了。技術債務就像信用卡同樣，會有很高的利息率，就如同給團隊留下了大量的賬務開銷。組織應該培養一種保證設計質量的文化。應當鼓勵重構、同時也應當鼓勵持續設計以及其它有關代碼質量的實踐。在開發時間中應當專門抽出一部分以解決技術債務。檢查清單：

• 團隊對技術債務有跟蹤和備忘錄機制嗎？仍是開發人員能夠隨意的產生債務？
• 針對技術債務有按期的培訓、回顧機制嗎？

3.7 遠離那些虛榮的東西（例如使用「熱門」的技術棧）

架構的重構過程應該是以目標爲導向，換句話說「注重實效」。對於技術人來講，一個常常被輕視的問題在於，喜歡追逐新鮮的熱門技術，這實際上是個好事情，說明技術人敢於創新，不斷接受新技術。可是對於架構的重構這樣的關鍵性任務來講，是否是新技術並不重要，重要的是能不能實現重構的目標。對於新技術來講，雖然熱度大，但你們踩過的坑還很少，積累的失敗教訓和成功經驗還不夠，在這種狀況下，建議你們不要頭腦一熱就上馬新技術，應該客觀冷靜地評估新技術和成熟技術對架構重構的影響和效果，以數據和經驗來講話，而不要追趕時髦。檢查清單：

• 重構的技術選型是否有詳實的數據和專家評估？
• 選用的技術是否有良好的人才積累和足夠的經驗支持？你是否是實驗小白鼠？
• 在技術選型時，是否至少有兩個方案待評估？有沒有成熟的技術方案？

3.8 作好準備面對壓力

軟件開發過程當中，壓力無處不在。對於架構重構來講，壓力來源於多個方面：管理層、團隊成員、同級部門等等。說白了，架構重構對我的來講每每是一件出力不討好的事情。和作一個新產品可以取得很高的讚揚相比，重構的成績每每並不受領導重視，並且出了問題還要承擔很大的責任。從軟件開發角度看，作新產品是從 0 到 1，而架構重構是從 -1 到 1，複雜性和難度一般更大。所以，重構的負責人要提早作好心理準備，舒緩壓力的一個技巧是，設置好里程碑，將重構的成果量化，而且和業務的變化關聯起來，按期向利益相關各方同步狀態，獲得你們的理解和支持。檢查清單：

• 架構的重構是否獲得了管理層（特別是最高管理層）的支持？他們是否對重構的時間、任務量有直接的認識？
• 你的重構計劃中是否包含了一些能夠量化的成果？是否認期向管理層展現這些成果？

3.9 瞭解業務

架構重構的最終目的是改進業務，因此對於業務的瞭解將有助於架構師和技術人肯定重構目標的優先級和關鍵路徑。好比，咱們須要知道哪些關鍵業務的架構是不能碰的，哪些業務之間是互相關聯的，哪些業務的架構是須要優先重構的…..等等。除了瞭解業務自己，咱們還須要瞭解「人」，表面上管理層是重構目標的裁決者，但實際上業務部門的人才是。技術人須要瞭解他們的業務需求，並將其轉化爲重構目標。經過這種方式，架構重構的意義才能獲得具體的體現。檢查清單：

• 是否與業務部門就架構重構所能實現的業務目標進行過充分的討論和確認？
• 是否對關鍵業務和優先重構的業務進行了確認？

3.10 作好面對非技術因素的準備

無論你是否願意相信，技術在架構重構（以及其餘很關鍵的公司決策中）的影響因素中並非最高的，咱們還會涉及到商業利益、管理層偏好、大客戶影響、團隊問題等等，對於架構師和技術人來講，這些因素每每不是他們所能掌控的。咱們能作的就是，與利益相關者設定重構目標，而後，根據不一樣的影響因素，調整目標。請記住，不要死扛這個目標，當有人提出不一樣的意見時，要坦誠地和他們交流，並告知他們如何採納意見，那麼重構目標會有變化，而後讓其餘利益相關者也知道這些變化。非技術因素的影響是客觀存在的，並且從商業層面來講也是合理的，因此對於技術人來講要學會適應。檢查清單：

• 當非技術因素影響架構的重構時，你是否對目標作了調整並告知了利益相關各方？
• 你是否準備以開放而不是抵制的心態來對待非技術因素的影響？

3.11 對於代碼質量有所掌握

架構的重構對代碼質量要求很高，一方面是重構過程對 Bug 的容忍性比新產品的研發更低，另外一方面也決定了下一次重構的難易程度。代碼審查是一個很是好的辦法。代碼審查是軟件開發過程當中的必要步驟，既能夠幫助被審查者提到代碼質量，又可讓審查者加深對產品的理解。不論團隊多忙，必定要保證代碼提交以前，是通過其餘成員審覈過的，短時間來看會佔用團隊的時間，長期來看是事半功倍的好事。檢查清單：

• 團隊成員是否對代碼質量有足夠的重視？是否有獎懲措施？
• 團隊內部是否有代碼質量的標準文檔和審查流程？

4、結尾

關於架構的重構，一切來源於實踐中的經驗是最有價值的，爲技術人所用纔是有意義。

最後

給你們分享一份移動架構大綱，包含了移動架構師須要掌握的全部的技術體系，你們能夠對比一下本身不足或者欠缺的地方有方向的去學習提高；

須要高清架構圖以及圖中視頻資料的能夠加入個人技術交流羣：1018342383私聊羣主小姐姐免費獲取