重構(gòu)是對軟件內(nèi)部結(jié)構(gòu)的一種調(diào)整，目的是在不改變軟件之可察性前提下，提高其可理解性，降低其修改成本。關(guān)于重構(gòu)的至理明言如下： 任何一個傻瓜都能寫出計算器可以理解的代碼，唯有寫出人類容易理解的代碼，才是優(yōu)秀的程序員； 事不過三，三則重構(gòu)； 當(dāng)你接獲bug提報，請先撰寫一個單元測試來揭發(fā)這個bug; 當(dāng)你感覺需要撰寫注釋，請先嘗試重構(gòu)，試著讓所有的注釋變得多余； 當(dāng)你發(fā)現(xiàn)自己需要為程序增加一個特性，而代碼結(jié)構(gòu)使你無法方便的這樣做，就先重構(gòu)那個程序； 重構(gòu)之前，必須建立一套可靠的測試機制； 寫軟件就像種樹，優(yōu)秀的程序員挖成小坑后隨及填好，繼續(xù)挖下一個，只會產(chǎn)生一系列小坑，不會有大坑，菜鳥則不會意識到所挖的坑正在變大，還是不停的挖，直到自己掉進大坑，爬不出來，陷入無盡的痛苦深淵； 開發(fā)時間越長，越能體會垃圾代碼的痛苦，卻不知道如何改進； Kent Beck:我不是一個偉大的程序員，我只是個有著一些優(yōu)秀習(xí)慣的好程序員而已； 變量(Variable) 不要定義一個臨時變量多次重復(fù)使用，臨時變量定義仍然應(yīng)該可以自解釋，從變量名稱能夠很好的理解變量的含義和作用。在定義一個臨時變量后需要有一段業(yè)務(wù)邏輯才能夠完成對臨時變量的賦值的時候，可以考慮將這段邏輯抽取到一個獨立的方法。

doublegetPrice(){ int basePrice = _quantity* _itemPrice; double discountFactor; if (basePrice > 1000) discountFactor = 0.95; else discountFactor = 0.98; return basePrice * discountFactor; }

重構(gòu)為：

double getPrice(){ return basePrice()* discountFactor(); } private int basePrice(){ return _quantity* _itemPrice; } private double discountFactor(){ if (basePrice()> 1000) return0.95; else return 0.98; }

當(dāng)遇到復(fù)雜的表達式的時候，需要引入解釋變量，因為復(fù)雜的表達式很難進行自解釋。

if ((platform.toUpperCase().indexOf("MAC")> -1)&& (browser.toUpperCase().indexOf("IE")> -1)&& wasInitialized()&& resize> 0 ) { // do something }

重構(gòu)為：

final booleanisMacOs ? ?= platform.toUpperCase().indexOf("MAC")>-1; final boolean isIEBrowser =browser.toUpperCase().indexOf("IE") > -1; final booleanwasResized ?= resize >0; if (isMacOs&& isIEBrowser&& wasInitialized()&& wasResized){ // do something }

減少對全局變量的使用，第一個是全局變量的生命周期很難控制，資源本身無法得到很快的釋放，其二是過多使用全局變量導(dǎo)致在調(diào)用方法的時候很難完全清楚方法說需要的入口數(shù)據(jù)信息，其三，多處都可以對全局變量賦值，我們很難立刻定位到當(dāng)前全局變量的值來源自哪里? 　分解方法(Extract Method) 一個較大的方法往往也會分為多個小的段落，step1,step2,step3，在每一個步驟都會考慮添加注釋說明。而這些相對較為獨立的步驟就可以分解為不同的方法，在分解后方法名可以自解釋方法的功能而不再需要額外的注釋。在一個類里面如果方法里面有一段代碼在多個方法中重復(fù)出現(xiàn)，需要抽取該類的公用方法。在多個不同的類中有一段代碼重復(fù)出現(xiàn)，需要考慮將公用代碼放到公用類中形成公用方法。 方法名需要很好的自解釋方法的功能，方法的返回盡量單一，方法的入口參數(shù)太多的時候應(yīng)該考慮使用集合，結(jié)構(gòu)或數(shù)據(jù)對象進行參數(shù)的傳遞。參數(shù)的傳遞可能出傳遞的是引用，但不要去修改入口參數(shù)的值。 不要因為一個方法里面只有一行，兩行很短而不考慮去分解，分解的時候更多的是考慮代碼的自解釋性。代碼本身不是解釋的技術(shù)實現(xiàn)機制，而是解釋的業(yè)務(wù)規(guī)則和需求。如果代碼不是解釋的業(yè)務(wù)規(guī)則和需求，那么其它人員就很難快速理解。 引入方法對象來取代方法，當(dāng)發(fā)現(xiàn)一個方法只用到該類里面的幾個關(guān)鍵屬性，方法和類里面其它的方法交互很少，輸出單一。由于該方法和這幾個屬性內(nèi)聚性很強而和該類其它部分松耦合，因此可以考慮將方法和這部分屬性移出形成一個單獨的方法對象。 移動方法，類的職責(zé)要單一，一個類的方法更多用到了別的類的屬性，這個方法可能更適合定義在那個類中。

class Account... private AccountType_type; private int_daysOverdrawn; double overdraftCharge(){ if (_type.isPremium()){ double result = 10; if (_daysOverdrawn > 7) result += (_daysOverdrawn -7)* 0.85; return result; } else return _daysOverdrawn * 1.75; } double bankCharge(){ double result = 4.5; if (_daysOverdrawn > 0) result +=overdraftCharge(); return result; }

重構(gòu)為：

classAccount... private AccountType _type; private int _daysOverdrawn; double overdraftCharge(){ return _type.overdraftCharge(_daysOverdrawn); } double bankCharge(){ double result = 4.5; if (_daysOverdrawn > 0) result += _type.overdraftCharge(_daysOverdrawn); return result; } classAccountType... double overdraftCharge(Account account){ if (isPremium()){ double result = 10; if (account.getDaysOverdrawn()> 7) result += (account.getDaysOverdrawn()- 7)* 0.85; return result; } else return account.getDaysOverdrawn()* 1.75; }

分解類(Extract Class) 類的職責(zé)的劃分不容易在初次設(shè)計時就準(zhǔn)確把握，所以在編碼時重構(gòu)是必要的。職責(zé)定位不清！——典型特征是擁有太多的成員變量；而在這里面最重要的就是職責(zé)要單一，屬性和方法是否合適的類中。如果不是就需要考慮分解或合并，擴展類的功能，或者抽象相應(yīng)的接口。面向?qū)ο蟮脑O(shè)計原則如下： 1.單一職責(zé)原則(SRP)-就一個類而言，應(yīng)該僅有一個引起它變化的原因 類的職責(zé)要單一，類里面的方法只做類的職責(zé)范圍里面的事情。MVC即是一種粗粒度的職責(zé)話費，模型類重點是提供數(shù)據(jù)，控制類重點是處理業(yè)務(wù)邏輯，而V視圖類則是關(guān)注數(shù)據(jù)獲取后的呈現(xiàn)。 數(shù)據(jù)和數(shù)據(jù)操作可以考慮分解，如形成專門的DTO數(shù)據(jù)傳輸對象類。界面類和界面數(shù)據(jù)提供類也可以考慮分離，如形成專門的Facade層專門負(fù)責(zé)數(shù)據(jù)的準(zhǔn)備和形成。界面層不應(yīng)該有太多的數(shù)據(jù)處理操作。 當(dāng)發(fā)現(xiàn)一個大的類里面的屬性和方法存在明細(xì)的分組特性的時候，而且分組直接松散耦合，需要考慮分解為多個類。 引入方法對象來取代方法，當(dāng)發(fā)現(xiàn)一個方法只用到該類里面的幾個關(guān)鍵屬性，方法和類里面其它的方法交互很少，輸出單一。由于該方法和這幾個屬性內(nèi)聚性很強而和該類其它部分松耦合，因此可以考慮將方法和這部分屬性移出形成一個單獨的方法對象。 胖接口也是違反職責(zé)單一，胖接口會導(dǎo)致所有實現(xiàn)接口的類都Override所有的接口方法，而有些接口方法往往是子類并不需要的。因此對于胖接口仍然要從職責(zé)的角度對接口進行拆分。 2.開放——封閉原則(OCP)-對擴展開放，對修改封閉 當(dāng)發(fā)生變化時，只需要添加新的代碼，而不必改動已經(jīng)正常運行的代碼：軟件人的夢想！而要達到這個目的，關(guān)鍵是要能夠較為準(zhǔn)確的預(yù)測業(yè)務(wù)變化會導(dǎo)致的可能會發(fā)送變化的模塊或代碼。 3.Liskov替換原則(LSP) 子類型必須能夠替換掉他們的基類型。正是子類型的可替換性，才使得使用基類類型的軟件無須修改就可以擴展。案例參考正方形駁論。矩形的合理假設(shè)：長、寬可以獨立變化；而正方形的合理假設(shè)：長、寬始終相等。因此正方形并不能從矩形繼承。 4.依賴倒置原則(DIP)-高層模塊不應(yīng)該依賴于低層模塊；抽象不應(yīng)該依賴于細(xì)節(jié)。 依賴倒置原則的重點是高層模塊類不要去依賴底層模塊的類，而應(yīng)該去依賴接口，特別是當(dāng)我們預(yù)見到底層模塊的類本身可能會擴展和變化的時候。這樣在變化的時候最大的好處就是高層類和接口不用變化。 類是否考慮抽象為接口，一方面是根據(jù)LSP原則進行重構(gòu)，一方面是需要觀察我們建立的類，是否有多個類本身存在相同的行為或方法，如果存在則需要考慮抽象接口。

最新內(nèi)容請見作者的GitHub頁：http://qaseven.github.io/

總結(jié)

以上是生活随笔為你收集整理的软件开发—重构的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。