前言

最近面試了很多候選人，發(fā)現(xiàn)很多同學(xué)在簡歷上都寫得非常厲害，負(fù)責(zé)架構(gòu)設(shè)計，項目重構(gòu)之類的。但是問起來，很多人都說不出個所以然來。今天我們不談架構(gòu)設(shè)計，我們聊一下重構(gòu)。我面試時候經(jīng)常會問，你是怎么重構(gòu)的，從哪些方面入手。大部分的人基本上回答就是換一下網(wǎng)絡(luò)請求的框架，圖片處理的框架，好一些的能夠說出一些MVP/MVVM,再好一點的能夠說出一些模塊化，組件化的東西。給我最大的感覺就是為了重構(gòu)而重構(gòu)，或者是無中生有的重構(gòu)，沒有全面的思考過為什么要這樣做。我們重構(gòu)的目的就是為了讓項目的可讀性，可維護性，擴展性更強。后期其他同學(xué)接手，不至于把祖宗都問候一遍。剛好，最近我一直在維護一個2010年到現(xiàn)在的一個項目，談一談重構(gòu)的過程。

1、注釋， activity、fragment、類、方法 一定要有注釋

每一個頁面，類，方法，都要有對應(yīng)的注釋，寫明作者是誰，時間，還有是做什么，這樣對后面的同學(xué)梳理流程的時候，會順暢很多。畢竟自己覺得自己寫的代碼很清晰，在其他人眼中就不一定是這樣了。
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中進行設(shè)置 settings -- > File and Code Templates -- >File Header 中添加

/**     
  * @Description:     java類作用描述 
  * @Author:         huangjialin
  * @CreateDate:     ${DATE} ${TIME}
  */

命名規(guī)范，統(tǒng)一，包括資源，java文件，布局，方法名，字段等等

這里推薦使用插件：Alibaba Java Coding Guidelines
要求：
1、（從命名上能夠知道這個是activity，fragment還是adapter等等）
2、見其名，能知其意

在我重構(gòu)的過程中，遇到很多這樣的

這是直接從項目中進行截圖的，我都不擔(dān)心會出現(xiàn)什么泄密的情況。這樣的命名，就只比使用A,B,C這樣的命名好一點而已。好的命名基本上能夠知道這個類，頁面，方法是干什么的，對后面維護的同學(xué)也是非常友好的。

java文件命名，一定要做到見其名，知其意，即使名字長一些也是可以的，比如說aaaActivity ,aaaFragment...,這個aaa基本就是這個文件是做什么的。布局，方法名，字段這些，也是如此，但是命名的同時，也要注意編碼規(guī)范。
針對于資源的命名，不光要能從名字中知道含義，還需要考慮后期組件化后，可能會產(chǎn)生的資源沖突
這里建議在module的build.gradle中添加

//給 Module 內(nèi)的資源名增加前綴, 避免資源名沖突
resourcePrefix "${project.name.toLowerCase().replaceAll("-", "_")}_"   

這樣給資源命名是會提示添加上對應(yīng)module的前綴了。

3、工具類封裝

Log,Toast,SharedPreferences,dialog,animation 等等等等，特別是對于經(jīng)歷過多人維護的項目，很多工具類都有很幾套，一人弄一套，所以我們要做的就是統(tǒng)一，一個項目中不要出現(xiàn)多個重復(fù)的工具類，否則對于后期維護那是很困難的。

4、第三方j(luò)ar的統(tǒng)一 如網(wǎng)絡(luò)，圖片等等

比如說我維護的這個項目，2010年寫的到現(xiàn)在，光網(wǎng)絡(luò)請求的就有四個，最早以前就是用HttpURLConnection，然后又有Volley，然后到Okhttp，接著就是Retrofit + okhttp,導(dǎo)致了現(xiàn)在一個很嚴(yán)重的問題，新人維護都不敢亂動，一直堆代碼，當(dāng)然，現(xiàn)在這樣的請求是沒事，但是如果后期,比如說需要更改域名，加密，在頭部添加一些參數(shù)，等等等等 ，那倒霉的永遠(yuǎn)是最后一個接手的人。
當(dāng)然這里需要注意兩個問題
第一：不要一上來就直接全部替換，要循序漸進，直接全部替換，那么風(fēng)險會非常大，對開發(fā)人員，測試人員，壓力都會很大。
第二：既然要統(tǒng)一，那么選用個框架比較好？我個人的看法是首先是選擇穩(wěn)定性好的，性能好的，自己擅長的。

5、模塊化->組件化，MVP/MVVM

做到這一步，多少對項目有些熟悉了，接下來要先做的是架構(gòu)的分層還是代碼的分離，取決于自身對項目的熟悉程度，如果項目中已經(jīng)做了模塊化，那么需要考慮的是以下幾點：
1、此時的模塊分離的粒度是否符合當(dāng)前，可能當(dāng)時分層的時候是合理的，但是隨著業(yè)務(wù)的增加，是不是存在一些臃腫的代碼，需不需要更加細(xì)致的分離。這個需要根據(jù)項目來決定的。
2、項目越大，那就考慮組件化，組件化是在模塊化的基礎(chǔ)上弄的，所以一定要先模塊化在組件化。
3、組件化需要分層更加細(xì)致，比如第三方j(luò)ar層，公共組件層，組件層，調(diào)試層等等，還需要考慮組件間的耦合，通信等，具體的可以專門去學(xué)習(xí)組件化。
4、插件化，如果做完組件化，在做插件化，那么插件化將會容易很多，同理，需不需要做插件化，根據(jù)公司項目來決定。

MVP/MVVM
這個主要是針對于代碼的隔離，如果項目中已經(jīng)使用了mvp，那就接著用mvp，不要因為一些東西出來了，比如現(xiàn)在Google強推一個jetpack，就馬上換MVVM，那樣風(fēng)險是非常大的，如果都是allinone在一個activity，那么直接就使用MVVM來進行重構(gòu)。LiveData + ViewModel優(yōu)勢是很大的。

組件化 + MVP + MVVM可參考：http://www.rzrgm.cn/huangjialin/p/13086553.html

6、涉及模式的使用

到這一步，基本對整個項目都是有一個明顯的認(rèn)識了，到這里就要考慮業(yè)務(wù)了，需要考慮更多的是業(yè)務(wù)的擴展性好不好，可讀性好不好，好不好維護了。在這里我們可以根據(jù)自己實際的項目來使用一些設(shè)計模式，比如單例，觀察者，工廠，Build模式，策略模式 等等

7、網(wǎng)絡(luò)數(shù)據(jù)結(jié)構(gòu)重構(gòu)

這個看公司業(yè)務(wù)來決定，這個處理的是后端返回的數(shù)據(jù)結(jié)構(gòu)是否需要統(tǒng)一，這里看公司和前后端的情況來決定。畢竟這個改動，不光是前端改，也需要后端同學(xué)改動了，工作量大，風(fēng)險很高。

8、性能優(yōu)化：卡頓，內(nèi)存，啟動，布局優(yōu)化，apk體積

到這一步，重構(gòu)代碼這部分，基本OK了，現(xiàn)在需要考慮的是應(yīng)用的性能問題了，這里我列出來，我個人覺得從左到右 優(yōu)先級由高到底 的順序來處理，具體怎么做，參考這里。
卡頓優(yōu)化：http://www.rzrgm.cn/huangjialin/p/13389421.html
內(nèi)存優(yōu)化：http://www.rzrgm.cn/huangjialin/p/13327949.html
啟動優(yōu)化：http://www.rzrgm.cn/huangjialin/p/13292042.html
布局優(yōu)化：http://www.rzrgm.cn/huangjialin/p/13353541.html

9、文檔輸出

非常重要！！！非常重要！！！非常重要！！！
這一步?jīng)]做好，很容易導(dǎo)致前面做的前功盡棄。所以需要一邊重構(gòu)，一邊輸出文檔，后面接手的人，會感謝你的。

10、重構(gòu)之路，任重而道遠(yuǎn)，需要定期重構(gòu)。

除非非常大的重構(gòu)，否則重構(gòu)不需要特意排期，只要我們發(fā)現(xiàn)某個地方不合理，都可以進行重構(gòu)，但是需要通知測試人員注意測試。重構(gòu)之路，任重而道遠(yuǎn) ！！！！！！！！！！！！！！！！