什么時候進行重構?

任何時間都可以進行重構，前提是你有足夠的時間以及精力去做這件事情，大部分公司重構代碼是不會計入KPI的，甚至重構的越多，出bug的概率就越大，背鍋的可能就越大。因此，小規(guī)模的重構或者自己負責功能的重構，可以穿插在需求中進行;大規(guī)模重構因為耗費時間較長，出錯概率較高，必須要得到上級的支持才能進行下去。

大規(guī)模重構的需求來源一般都是因為目前技術架構已經(jīng)不能滿足快速的業(yè)務迭代，可維護性差，新人上手困難，出現(xiàn)bug幾率增加，當代碼已經(jīng)到達這個程度的時候，就需要推進進行大規(guī)模重構了。

重構的原則

需要理清楚的是重構不是重寫，更不是解決bug，引入新需求。很多新手在進行重構的時候，往往會在重構過程中去修改之前的固有邏輯，甚至增加一些自己的業(yè)務理解去“優(yōu)化”現(xiàn)有的代碼，這是大錯特錯的，因此重構的***個原則是：“忠于原代碼”，特別是在自己無法理解之前業(yè)務的下，盡量忠于原文，可以減少產(chǎn)生的新的bug，可測性增強。

重構的第二個原則：“逐步實施”。盡量不要一下子就推翻重建，應該從盡量底層去抽取共性，由點及面，分解目標，逐步實施;比如你要對當前代碼做整體的MVP重估，這個時候你可以先把當前業(yè)務理清楚，分析核心業(yè)務，從最簡單的業(yè)務入手，保留原有的結構，逐步兼容，然后慢慢把之前的代碼精簡掉甚至移除。

重構的第三個原則：“簡潔邏輯而非減少代碼”，重構最終的目標是需要符合軟件工程中單一指責以及開閉原則的，代碼行數(shù)的多少不是關鍵，怎么理清楚邏輯，讓后續(xù)維護方便，入手學習成本低才是最關鍵的。很多人以“從XXX行到XX行”為重構的目標，行數(shù)的減少是衡量指標之一，但絕不是最重要的指標。比如RxJava的引入，可能會增加代碼量，但是邏輯更清晰了，增加功能更容易了，這就是成功的重構。

重構的另外一個原則就是：“合適的才是***的”，很多人重構代碼就是炫技，一旦給他重構代碼的機會，就如脫韁野馬，引入大量自己并不熟悉的框架進行，覺得這是一個學習的好機會，一旦出現(xiàn)問題就無法解決。怎么就算合適了，在我看來，合適的架構一定是以下幾個特征：

• 學習成本低，新人入手容易，市場上資料多;
• 不過度設計，但是又容易擴展，以后換成新架構也方便;
• 不要過度結耦;

前面兩點比較容易理解，第三點怎么理解呢?寫代碼久了，就會明白一個定律：“代碼邏輯守恒定律”，就是無論你怎么設計架構，代碼邏輯是不會減少的，一個地方邏輯減少了，就一定會在另一個地方邏輯增加。解偶就意味著，你把不屬于這一塊業(yè)務的邏輯轉(zhuǎn)移到另外一個地方，過度解構要么是劃分了很多個模塊，要么就是把對應的業(yè)務放在了“看不到”的地方，當“看不到”多了以后，就會造成查找問題非常麻煩，比如過多的在Java使用注解或者編譯時注解。過度解偶其實就是隱藏了不必要隱藏的邏輯，對調(diào)用者完全透明，問題的追蹤就會在透明層被截斷，從而導致問題的產(chǎn)生。

怎么實施重構

參與重構人數(shù)不宜過多，兩三人為宜;功能不宜分散，至少每個人應該要重構一個業(yè)務功能模塊或者功能點，這樣可以更好減少溝通成本。

大規(guī)模重構，應該從下至上，先理清晰要達到的目標，先從底層邏輯開始重構，逐步到上層。比如在Android中對之前代碼的重構，應該是先模塊，后組件，然后逐漸到具體業(yè)務，這樣就可以保證整個過程中重構的一致性。

在進行重構之前，需要對要達到的重構目標做一個評估，是要完全重構完，還是只需要對關鍵業(yè)務做梳理，亦或是需要整理出一個模版，然后分布實施。不同的目標對應不同的做法以及不同的工作量;在重構之前還需要需要對當前關鍵業(yè)務做梳理，理清楚周邊支撐組件和必須要提前的工作量。

比如，某一次重構：

• 目標：完成所有業(yè)務模塊的MVP重構
• 關鍵業(yè)務：打車、訂單管理、地圖
• 效果
  • 模塊抽取(module1/moduel2...)
  • 基礎組件

推送/IM

網(wǎng)絡

支付

...

• 規(guī)范

預估時間 30天/1人

圍繞關鍵業(yè)務設計，設計好了關鍵流程，重構就成功了一半。在重構中，還有一個比較基礎問題就是：編碼規(guī)范的問題;編碼規(guī)范盡量使用工具去最規(guī)范。類似于sonar/lint等工具做到自動識別，自動提醒，不要浪費太多時間在上面。