談談代碼重構

很久沒寫文章了，最近太忙了，詐個屍,剛好最近在代碼重構，簡單談談何時重構、重構的原則以及怎麼實施去重構。

何時進行重構？

任什麼時候間均可以進行重構，前提是你有足夠的時間以及精力去作這件事情，大部分公司重構代碼是不會計入KPI的，甚至重構的越多，出bug的機率就越大，背鍋的可能就越大。所以，小規模的重構或者本身負責功能的重構，能夠穿插在需求中進行；大規模重構由於耗費時間較長，出錯機率較高，必需要獲得上級的支持才能進行下去。大規模重構的需求來源通常都是由於目前技術架構已經不能知足快速的業務迭代，可維護性差，新人上手困難，出現bug概率增長，當代碼已經到達這個程度的時候，就須要推動進行大規模重構了。

重構的原則

須要理清楚的是重構不是重寫，更不是解決bug，引入新需求。不少新手在進行重構的時候，每每會在重構過程當中去修改以前的固有邏輯，甚至增長一些本身的業務理解去「優化」現有的代碼，這是大錯特錯的，所以重構的第一個原則是：「忠於原代碼」，特別是在本身沒法理解以前業務的下，儘可能忠於原文，能夠減小產生的新的bug，可測性加強。

重構的第二個原則：「逐步實施」。儘可能不要一會兒就推翻重建，應該從儘可能底層去抽取共性，由點及面，分解目標，逐步實施；好比你要對當前代碼作總體的MVP重估，這個時候你能夠先把當前業務理清楚，分析核心業務，從最簡單的業務入手，保留原有的結構，逐步兼容，而後慢慢把以前的代碼精簡掉甚至移除。

重構的第三個原則：「簡潔邏輯而非減小代碼」，重構最終的目標是須要符合軟件工程中單一指責以及開閉原則的，代碼行數的多少不是關鍵，怎麼理清楚邏輯，讓後續維護方便，入手學習成本低纔是最關鍵的。不少人以「從XXX行到XX行」爲重構的目標，行數的減小是衡量指標之一，但毫不是最重要的指標。好比RxJava的引入，可能會增長代碼量，可是邏輯更清晰了，增長功能更容易了，這就是成功的重構。

重構的另一個原則就是：「合適的纔是最好的」，不少人重構代碼就是炫技，一旦給他重構代碼的機會，就如脫繮野馬，引入大量本身並不熟悉的框架進行，以爲這是一個學習的好機會，一旦出現問題就沒法解決。怎麼就算合適了，在我看來，合適的架構必定是如下幾個特徵：

• 學習成本低，新人入手容易，市場上資料多；
• 不過分設計，可是又容易擴展，之後換成新架構也方便；
• 不要過分結偶;

前面兩點比較容易理解，第三點怎麼理解呢？寫代碼久了，就會明白一個定律：「代碼邏輯守恆定律」，就是不管你怎麼設計架構，代碼邏輯是不會減小的，一個地方邏輯減小了，就必定會在另外一個地方邏輯增長。解偶就意味着，你把不屬於這一塊業務的邏輯轉移到另一個地方，過分解構要麼是劃分了不少個模塊，要麼就是把對應的業務放在了「看不到」的地方，當「看不到」多了之後，就會形成查找問題很是麻煩，好比過多的在Java使用註解或者編譯時註解。過分解偶其實就是隱藏了沒必要要隱藏的邏輯，對調用者徹底透明，問題的追蹤就會在透明層被截斷，從而致使問題的產生。

怎麼實施重構

參與重構人數不宜過多，兩三人爲宜；功能不宜分散，至少每一個人應該要重構一個業務功能模塊或者功能點，這樣能夠更好減小溝通成本。

大規模重構，應該從下至上，先理清晰要達到的目標，先從底層邏輯開始重構，逐步到上層。好比在Android中對以前代碼的重構，應該是先模塊，後組件，而後逐漸到具體業務，這樣就能夠保證整個過程當中重構的一致性。

在進行重構以前，須要對要達到的重構目標作一個評估，是要徹底重構完，仍是隻須要對關鍵業務作梳理，亦或是須要整理出一個模版，而後分佈實施。不一樣的目標對應不一樣的作法以及不一樣的工做量；在重構以前還須要須要對當前關鍵業務作梳理，理清楚周邊支撐組件和必需要提早的工做量。

好比，某一次重構：

• 目標：完成全部業務模塊的MVP重構
• 關鍵業務：打車、訂單管理、地圖
• 效果
  • 模塊抽取（module1/moduel2...）
  • 基礎組件
    • 推送/IM
    • 網絡
    • 支付
    • ...
  • 規範
• 預估時間 30天/1人

圍繞關鍵業務設計，設計好了關鍵流程，重構就成功了一半。在重構中，還有一個比較基礎問題就是：編碼規範的問題；編碼規範儘可能使用工具去最規範。相似於sonar/lint等工具作到自動識別，自動提醒，不要浪費太多時間在上面。

總結

快下班了，先寫到這裏吧，有什麼能夠在評論中探討。