相信博客園的讀者大多都是千萬“碼農(nóng)”中的一員，每個人都寫過很多代碼，但并不是每一個人都能寫出高質(zhì)量的代碼。 rome is not built in one day !——完成高質(zhì)量的代碼也不是一蹴而就的。為了寫出高質(zhì)量的代碼，我們需要借助一些手段，“代碼重構(gòu)”基本上是最常用的手段，甚至是唯一的手段。 重構(gòu)需要你花一些心思去琢磨自己的代碼，這好比自己種的花花草草，看你怎么對待它們。你不給它們澆水、除蟲、曬太陽，它們可能會長蟲、生病。如果你用心地去對待它們，它們可能會枝繁葉茂，花開茂盛。但是，即使你已經(jīng)很專心地去打理它們了，它們也不一定是“健康的”，畢竟每一種花草都有自己的習(xí)性，代碼也是如此。

相信博客園的讀者大多都是千萬“碼農(nóng)”中的一員，每個人都寫過很多代碼，但并不是每一個人都能寫出高質(zhì)量的代碼。
rome is not built in one day !——完成高質(zhì)量的代碼也不是一蹴而就的。為了寫出高質(zhì)量的代碼，我們需要借助一些手段，“代碼重構(gòu)”基本上是最常用的手段，甚至是唯一的手段。

為何要重構(gòu)？

做一件事情之前，我們都應(yīng)該先反問自己Why。

我也問過自己：為什么要對代碼進(jìn)行重構(gòu)？項目一個接一個地做，我哪有什么時間去重構(gòu)代碼，我還要控制團(tuán)隊的項目成本！
Oh, Shit！為了讓代碼看起來更好一些，我們花了一些時間在代碼重構(gòu)上，項目的成本又超了！向公司領(lǐng)導(dǎo)匯報時，又要編造合適的理由了！

持續(xù)利益的提升

何謂“將來的利益”？如果代碼的質(zhì)量較為可靠，則會為以后的維護(hù)、升級奠定良好的基礎(chǔ)。倘若已完成的代碼質(zhì)量不高、不夠整潔，在系統(tǒng)維護(hù)、升級時，不說花在代碼修改上的時間，僅閱讀理解代碼就將花去你大量的時間。如果你需要對項目持續(xù)地維護(hù)、升級，這該是多么長久的一個痛苦啊！到這里，你能理解了吧，這些”低質(zhì)量代碼“產(chǎn)生的將來成本將遠(yuǎn)超于你現(xiàn)在重構(gòu)的成本。正所謂“長痛不如短痛”，要自宮就趕緊的，這樣才能早點(diǎn)練成“葵花寶典”。

設(shè)計的提升

沒有完美的產(chǎn)品，也沒有完美的設(shè)計，設(shè)計的最終目的是為用戶創(chuàng)造價值。

大多數(shù)系統(tǒng)或產(chǎn)品的設(shè)計是伴隨著需求持續(xù)演變的，設(shè)計調(diào)整時，重構(gòu)又是必備的利器。重構(gòu)的過程，是對設(shè)計過程的整理，也是對設(shè)計細(xì)節(jié)的推敲。設(shè)計既然是不完美的，那么在重構(gòu)的思考過程中我們總是能發(fā)現(xiàn)一些設(shè)計上的瑕疵。發(fā)現(xiàn)了瑕疵，我們就可以通過重構(gòu)加以改善。小到對字段、方法的重構(gòu)，大到對工程結(jié)構(gòu)、系統(tǒng)架構(gòu)的重構(gòu)，都是設(shè)計的改變。
這個過程可能讓你痛苦，可能讓你快樂。

何時才重構(gòu)？

講這個例子，并不是為了體現(xiàn)做什么事情都一定要趁早，而是為了說明無論做什么事情，選擇合適的時機(jī)非常重要。當(dāng)然趁早做一些事情，也能更早發(fā)現(xiàn)問題。

重構(gòu)亦是如此。重構(gòu)是一把利器，選擇合適的時機(jī)重構(gòu)或許會讓我們的收益超出預(yù)期。

下面幾項是我覺得可能需要重構(gòu)的時機(jī)：

1. 代碼中存在著重復(fù)的代碼
2. 代碼中存在過大的類或過長的方法
3. 代碼中存在強(qiáng)依賴、緊耦合的結(jié)構(gòu)
4. 代碼的運(yùn)算邏輯難以理解
5. 代碼不能清晰地描述現(xiàn)實(shí)對象的特征、行為以及對象間的關(guān)系

當(dāng)然，每個人對重構(gòu)、對系統(tǒng)、對業(yè)務(wù)、對用戶的理解是不同的，所以每個人選擇重構(gòu)的時機(jī)也盡不相同。你大可不必參考這幾項，結(jié)合周圍的環(huán)境選擇合適自己的（這本身也是一個時機(jī)選擇）就好。即使出現(xiàn)這幾種情形，重構(gòu)也不一定是必須的，這取決于你們的項目經(jīng)驗、你們心中的準(zhǔn)則，也取決于你們看待產(chǎn)品、看待項目的方式。

重構(gòu)的策略

代碼重構(gòu)有很多策略，我將基于《31 Days Refactoring》和《Clean Code》這兩本書，以及OOP（面向?qū)ο缶幊蹋┑母拍罱榻B一些常用的重構(gòu)策略。當(dāng)然，我不是將書中的內(nèi)容搬到這里，我會盡可能地加入自己的理解。

下面列出了我將要講的重構(gòu)系列的主題，它們基本都來源于《31 Days Refactoring》。是的，這本書只有50多頁，你懂點(diǎn)英文，這本書你花1個小時或許就看完了。重構(gòu)的代碼大家都能讀懂，我不想徒有其“表”，我想更深層次地理解其“意”，不僅于自己，也于讀到這一系列文章的人。

方法、字段重構(gòu)

1. 移動方法 (2016-04-24)
2. 提取方法、提取方法對象 (2016-04-26)
3. 方法、字段的提升和降低 (2016-05-01)
4. 分解方法 (2016-05-02)
5. 為布爾方法命名 (2016-05-03)
6. 引入對象參數(shù) (2016-05-04)

類、接口重構(gòu)

1. 使用委派代替繼承 (2016-05-07)
2. 提取接口 (2016-05-08)
3. 解除依賴 (2016-05-09)
4. 分離職責(zé) (2016-05-11)
5. 提取基類、提取子類、合并子類 (2016-05-12)  
6. 去除上帝類 (2016-05-14)
7. 去除中間類
8. 使用多態(tài)代替條件判斷

設(shè)計模式重構(gòu)

1. 策略模式代替Switch
2. 引入契約式設(shè)計
3. 提取工廠類

一般性重構(gòu)

1. 重命名
2. 分解復(fù)雜判斷
3. 用條件判斷代替異常
4. 避免雙重否定
5. 盡快返回
6. 封裝條件
7. 封裝集合

你們也看到了，列舉的這些重構(gòu)策略都是一些基本技巧，即使學(xué)會這些技巧也不能讓你馬上成為“重構(gòu)”大師，我自身也不是什么代碼高手。

重構(gòu)的雙刃劍

正所謂“不破不立”，你不去用劍，不和劍交流，不被劍傷，你永遠(yuǎn)無法成為一名好劍客。

后話

最后，我想引用屈原的一句名言：“路漫漫其修遠(yuǎn)兮，吾將上下而求索”。

我無法讓你們在看完這一系列文章后，就能“深度”領(lǐng)會重構(gòu)的“意”了，這仍然需要你自己去琢磨代碼層面的一些事兒，也許是一個方法，也許是項目的架構(gòu)。

另外，我個人是不推薦“1天學(xué)會xxx”、“3天掌握xxx”、”8天弄懂xxx“的。你讀完了文章，不代表你真的理解了。你需要自己去思考，自己去實(shí)踐。1天也好，3天也罷，若你肯花時間專心地去領(lǐng)會一件事情，并堅持不懈地為之努力，你遲早是懂的。他人講得天花亂墜，你聽過看過之后，也不過是過眼云煙。

讀到這一系列文章的讀者，如果有不同的見解，或者察覺文章中的描述有誤，歡迎來討論或指正。通過這一系列文章，我希望讀者會有所收益，也希望自己對重構(gòu)能有一個更深的理解。如果您覺得文章對您有用，請不要吝嗇您的“推薦”；但如果您覺得它一無是處，請您不要客氣地點(diǎn)擊“反對”，您的反對也是給予我的一種磨礪，它會讓我持續(xù)學(xué)習(xí)和改進(jìn)。

“多么痛的領(lǐng)悟~，維護(hù)曾是你的全部~~。愿你掙脫爛代碼的枷鎖，各種坑的束縛，別再為項目受苦~~~”。結(jié)尾獻(xiàn)給各位一首歌，祝大家周末愉快！