2019獨角獸企業重金招聘Python工程師標準>>>

重構概念

在不改變軟件可觀察行為的前提下，對軟件內部結構的一種調整，提高其可理解性，降低修改成本。

重構節奏

測試、小修改、測試、小修改......正是這種節奏讓重構得以快速安全而安全的前行。

構筑測試體系

如果想要重構，我們必須擁有一個良好的測試環境。編寫優良的測試程序，可以極大的提升編程速度和代碼質量，即使不進行重構也一樣如此。

每當我們收到一個bug報告時，請先寫一個單元測試來暴露bug。

測試是一種風險驅動的行為，測試的目的是希望找出現在或未來才可能出現的錯誤。 測試的要訣是：測試你最擔心出錯的部分。這樣你就能從測試工作中得到最大的利益。

“花費合理的時間找出大多數的bug”好過“窮盡一生抓出所有bug”。

重新組織函數

• 重復代碼 重復代碼應該考慮將其提煉到一個獨立的函數或類中。

• 過長函數 當我們看見一個過長的函數或者需要一段注釋才能讓人理解其用途的代碼時，我們就需要將這段代碼放到一個獨立的函數中。 一個函數多長才算合適？在我看來長度不是問題，關鍵在于函數名稱和函數體之間的語義距離。如果提煉可以強化代碼清晰度，那就去做，就算函數名稱比提煉出來的代碼還要長也無所謂。

• 內聯函數 有時候會遇到某些函數，其內部代碼和函數名稱同樣清晰易讀，我們就可以去掉這個函數直接使用其中代碼。

• 內聯臨時變量 如果發現一個臨時變量只被一個簡單表示式賦值一次，并且妨礙了其他重構手法，我們就應該讓他內聯化。 直接將變量聲明成final的，可以檢查變量是否真的是被賦值了一次。

• 以查詢來取代臨時變量

• 引入解釋性臨時變量 將復雜表達式的結果放到一個臨時變量，以變量名稱來解釋表達式用途。

• 分解臨時變量

在對象之間搬移特性

在對象設計過程中，決定把“責任”放在哪里是非?？傄?。這曾經讓我非常苦惱，但是現在我知道，在這種情況下，可以運用重構，改變原有的設計。

• 搬移函數 “搬移函數”是重構理論的支柱。如果一個類有太多行為，如果一個類和另一個類高度耦合，我們就需要搬移函數。

• 搬移新的字段 隨著系統的發展，你會發現自己需要新的類，并將現有的工作拖到新的類中。如果發現對于一個字段，在其所駐類之外的另一個類中都有更多函數使用了它，我就會考慮搬移這個字段。

• 提煉類 一個類應該是一個清晰的抽象，處理一些明確的責任。

簡化表達式

可以將一個復雜的條件邏輯分解成若干小塊。這樣可以使得分支邏輯和操作細節分離。

• 分解條件表達式 分解表達式可以突出條件邏輯，更清晰地表明每個分支的作用，并突出每個分支的原因。 做法：將分支語句提煉出來，構成一個獨立的函數。

• 合并表達式 有時會發現一串的表達式檢查條件各不相同，但最終行為卻一致。如果這樣就需要使用“邏輯與”或“邏輯或”合并表達式。

• 合并重復的條件片段 當所有分支都會執行相同代碼時，就需要將這段代碼搬移到條件表達式之外了。這樣我們能更加清晰的知道，那些東西是隨著條件變化而變化的、那些是不變的。

• 移除控制標記 控制標記可以使用break或continue來代替，還可以使用return直接返回。

• 以衛語句來取代嵌套表達式 可以讓代碼邏輯看起來更加的清晰。

• 以多態來取代條件表達式 多態的好處在于：如果你需要根據對象的不同類型來采取不同的行為，多態使你不必寫明顯的條件表達式。

簡化函數調用

-　改函數名 函數的名稱應該準確的表達它的用途。給函數命名有一個好的辦法：首先考慮應該給函數寫上一句這樣的注釋，然后在想辦法將注釋變成函數名稱。

• 移除參數 參數代表著函數所需的信息，不同的參數值有不同的意義。如果不去掉多余的參數，就會讓每一位調用者多費一份心。

• 將查詢函數和修改函數分離 任何有返回值的函數，都不因該有看到的副作用。

• 引入參數對象 為了縮短參數列，我們可以使用一個對象來包裝所有的參數。這樣可以降低理解和修改函數代碼的難度。

• 以異常來取代錯誤碼 如果調用者有責任在調用前檢查必要狀態，就拋出非受控異常。

處理概括關系

• 劃分邊界 確定各個字段、方法應該處于子類還是超類也是我們經常需要注意的一個點。

• 提煉子類、超類和接口

• 折疊繼承體系 有時我們會發現某個子類并沒有帶來該有的價值時，我們就需要將子類的超類合并。

• 塑造模板函數 你有一些子類，其中相應的某些函數以相同順序執行類似的操作，但是各個操作細節上有所不同。將這些操作分別放進獨立函數中，并保證他們有相同的簽名，于是原函數也變得相同了，然后將原函數移至超類。

• 以委托取代繼承 當某個子類只使用接口中的一部分，或者不使用繼承而來的數據時，我們可以在子類新建一個字段用以保存超類：調整子類函數，令他改而委托超類；然后去掉兩者間的繼承關系。

大型重構

• 梳理并分解機場體系
• 將過程化設計轉化為對象設計
• 提煉繼承體系

重構要點

需要有充分測試代碼

每次只做小的改動，然后編譯測試，然后在做改動

新加功能就不要去重構，重構就不要新加功能

重構一定要保證對外接口不要改動或者少改動

做性能重構時盡量使用度量工具，不要臆測

當你發現在加一個新功能的時候很費勁，這個時候就需要考慮重構了

重構一般發生在項目中期

性能重構是我們應該優先關注執行頻率較高的代碼

重構可以和系統設計達到一種平衡

任何情況下我們應該優先編寫出可以調試的軟件，然后再試圖優化它使它更快

一個優秀的程序員是能編寫出讓別人很快看懂理解的代碼

重構盡量不要直接刪掉老的接口，而應該將其標注成廢棄

參考

《重構改善既有代碼設計》

為監控而生的多級緩存框架 layering-cache這是我開源的一個多級緩存框架的實現，如果有興趣可以看一下

轉載于:https://my.oschina.net/u/3748347/blog/2992764

總結

以上是生活随笔為你收集整理的系统重构笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。