前言
最近面試了很多候選人，發現很多同學在簡歷上都寫得非常厲害，負責架構設計，專案重構之類的。但是問起來，很多人都說不出個所以然來。今天我們不談架構設計，我們聊一下重構。我面試時候經常會問，你是怎麼重構的，從哪些方面入手。大部分的人基本上回答就是換一下網路請求的框架，圖片處理的框架，好一些的能夠說出一些MVP/MVVM,再好一點的能夠說出一些模組化，元件化的東西。給我最大的感覺就是為了重構而重構，或者是無中生有的重構，沒有全面的思考過為什麼要這樣做。我們重構的目的就是為了讓專案的可讀性，可維護性，擴充套件性更強。後期其他同學接手，不至於把祖宗都問候一遍。剛好，最近我一直在維護一個2010年到現在的一個專案，談一談重構的過程。
1、註釋， activity、fragment、類、方法 一定要有註釋
每一個頁面，類，方法，都要有對應的註釋，寫明作者是誰，時間，還有是做什麼，這樣對後面的同學梳理流程的時候，會順暢很多。畢竟自己覺得自己寫的程式碼很清晰，在其他人眼中就不一定是這樣了。
activity：C:\Program Files\Android\Android Studio\plugins\android\lib\templates\activities\EmptyActivity\root\src\app_package
在頭部新增
/**
* @Description:
* @Author: huangjialin
* @CreateDate: ${.now?string("yyyy-MM-dd")}
*/
普通類的，可以直接在studio中進行設定 settings -- > File and Code Templates -- >File Header 中新增
/**
* @Description: java類作用描述
* @Author: huangjialin
* @CreateDate: ${DATE} ${TIME}
*/
命名規範，統一，包括資源，java檔案，佈局，方法名，欄位等等
這裡推薦使用外掛：Alibaba Java Coding Guidelines
要求：
1、（從命名上能夠知道這個是activity，fragment還是adapter等等）
2、見其名，能知其意
在我重構的過程中，遇到很多這樣的
這是直接從專案中進行截圖的，我都不擔心會出現什麼洩密的情況。這樣的命名，就只比使用A,B,C這樣的命名好一點而已。好的命名基本上能夠知道這個類，頁面，方法是幹什麼的，對後面維護的同學也是非常友好的。
java檔案命名，一定要做到見其名，知其意，即使名字長一些也是可以的，比如說aaaActivity ,aaaFragment...,這個aaa基本就是這個檔案是做什麼的。佈局，方法名，欄位這些，也是如此，但是命名的同時，也要注意編碼規範。
針對於資源的命名，不光要能從名字中知道含義，還需要考慮後期元件化後，可能會產生的資源衝突
這裡建議在module的build.gradle中新增
//給 Module 內的資源名增加字首, 避免資源名衝突
resourcePrefix "${project.name.toLowerCase().replaceAll("-", "_")}_"
這樣給資源命名是會提示新增上對應module的字首了。
3、工具類封裝
Log,Toast,SharedPreferences,dialog,animation 等等等等，特別是對於經歷過多人維護的專案，很多工具類都有很幾套，一人弄一套，所以我們要做的就是統一，一個專案中不要出現多個重複的工具類，否則對於後期維護那是很困難的。
4、第三方jar的統一 如網路，圖片等等
比如說我維護的這個專案，2010年寫的到現在，光網路請求的就有四個，最早以前就是用HttpURLConnection，然後又有Volley，然後到Okhttp，接著就是Retrofit + okhttp,導致了現在一個很嚴重的問題，新人維護都不敢亂動，一直堆程式碼，當然，現在這樣的請求是沒事，但是如果後期,比如說需要更改域名，加密，在頭部新增一些引數，等等等等 ，那倒黴的永遠是最後一個接手的人。
當然這裡需要注意兩個問題
第一：不要一上來就直接全部替換，要循序漸進，直接全部替換，那麼風險會非常大，對開發人員，測試人員，壓力都會很大。
第二：既然要統一，那麼選用個框架比較好？我個人的看法是首先是選擇穩定性好的，效能好的，自己擅長的。
5、模組化->元件化，MVP/MVVM
做到這一步，多少對專案有些熟悉了，接下來要先做的是架構的分層還是程式碼的分離，取決於自身對專案的熟悉程度，如果專案中已經做了模組化，那麼需要考慮的是以下幾點：
1、此時的模組分離的粒度是否符合當前，可能當時分層的時候是合理的，但是隨著業務的增加，是不是存在一些臃腫的程式碼，需不需要更加細緻的分離。這個需要根據專案來決定的。
2、專案越大，那就考慮元件化，元件化是在模組化的基礎上弄的，所以一定要先模組化在元件化。
3、元件化需要分層更加細緻，比如第三方jar層，公共元件層，元件層，除錯層等等，還需要考慮元件間的耦合，通訊等，具體的可以專門去學習元件化。
4、外掛化，如果做完元件化，在做外掛化，那麼外掛化將會容易很多，同理，需不需要做外掛化，根據公司專案來決定。
MVP/MVVM
這個主要是針對於程式碼的隔離，如果專案中已經使用了mvp，那就接著用mvp，不要因為一些東西出來了，比如現在Google強推一個jetpack，就馬上換MVVM，那樣風險是非常大的，如果都是allinone在一個activity，那麼直接就使用MVVM來進行重構。LiveData + ViewModel優勢是很大的。
元件化 + MVP + MVVM可參考：https://www.cnblogs.com/huangjialin/p/13086553.html
6、涉及模式的使用
到這一步，基本對整個專案都是有一個明顯的認識了，到這裡就要考慮業務了，需要考慮更多的是業務的擴充套件性好不好，可讀性好不好，好不好維護了。在這裡我們可以根據自己實際的專案來使用一些設計模式，比如單例，觀察者，工廠，Build模式，策略模式 等等
7、網路資料結構重構
這個看公司業務來決定，這個處理的是後端返回的資料結構是否需要統一，這裡看公司和前後端的情況來決定。畢竟這個改動，不光是前端改，也需要後端同學改動了，工作量大，風險很高。
8、效能優化：卡頓，記憶體，啟動，佈局優化，apk體積
到這一步，重構程式碼這部分，基本OK了，現在需要考慮的是應用的效能問題了，這裡我列出來，我個人覺得從左到右 優先順序由高到底 的順序來處理，具體怎麼做，參考這裡。
卡頓優化：https://www.cnblogs.com/huangjialin/p/13389421.html
記憶體優化：https://www.cnblogs.com/huangjialin/p/13327949.html
啟動優化：https://www.cnblogs.com/huangjialin/p/13292042.html
佈局優化：https://www.cnblogs.com/huangjialin/p/13353541.html
9、文件輸出
非常重要！！！非常重要！！！非常重要！！！
這一步沒做好，很容易導致前面做的前功盡棄。所以需要一邊重構，一邊輸出文件，後面接手的人，會感謝你的。
10、重構之路，任重而道遠，需要定期重構。
除非非常大的重構，否則重構不需要特意排期，只要我們發現某個地方不合理，都可以進行重構，但是需要通知測試人員注意測試。重構之路，任重而道遠 ！！！！！！！！！！！！！！！！