系統重構筆記

時間 2019-12-06

標籤系統筆記简体版

原文原文鏈接

重構概念

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

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

若是想要重構，咱們必須擁有一個良好的測試環境。編寫優良的測試程序，能夠極大的提高編程速度和代碼質量，即便不進行重構也同樣如此。github

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

測試是一種風險驅動的行爲，測試的目的是但願找出如今或將來纔可能出現的錯誤。測試的要訣是：測試你最擔憂出錯的部分。這樣你就能從測試工做中獲得最大的利益。緩存

「花費合理的時間找出大多數的bug」好過「窮盡一輩子抓出全部bug」。安全

重複代碼重複代碼應該考慮將其提煉到一個獨立的函數或類中。框架
過長函數當咱們看見一個過長的函數或者須要一段註釋才能讓人理解其用途的代碼時，咱們就須要將這段代碼放到一個獨立的函數中。一個函數多長才算合適？在我看來長度不是問題，關鍵在於函數名稱和函數體之間的語義距離。若是提煉能夠強化代碼清晰度，那就去作，就算函數名稱比提煉出來的代碼還要長也無所謂。函數
內聯函數有時候會遇到某些函數，其內部代碼和函數名稱一樣清晰易讀，咱們就能夠去掉這個函數直接使用其中代碼。工具
內聯臨時變量若是發現一個臨時變量只被一個簡單表示式賦值一次，而且妨礙了其餘重構手法，咱們就應該讓他內聯化。直接將變量聲明成final的，能夠檢查變量是否真的是被賦值了一次。性能
以查詢來取代臨時變量
引入解釋性臨時變量將複雜表達式的結果放到一個臨時變量，以變量名稱來解釋表達式用途。
分解臨時變量

在對象設計過程當中，決定把「責任」放在哪裏是很是總要的。這曾經讓我很是苦惱，可是如今我知道，在這種狀況下，能夠運用重構，改變原有的設計。

搬移函數「搬移函數」是重構理論的支柱。若是一個類有太多行爲，若是一個類和另外一個類高度耦合，咱們就須要搬移函數。
搬移新的字段隨着系統的發展，你會發現本身須要新的類，並將現有的工做拖到新的類中。若是發現對於一個字段，在其所駐類以外的另外一個類中都有更多函數使用了它，我就會考慮搬移這個字段。
提煉類一個類應該是一個清晰的抽象，處理一些明確的責任。

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

分解條件表達式分解表達式能夠突出條件邏輯，更清晰地代表每一個分支的做用，並突出每一個分支的緣由。作法：將分支語句提煉出來，構成一個獨立的函數。
合併表達式有時會發現一串的表達式檢查條件各不相同，但最終行爲卻一致。若是這樣就須要使用「邏輯與」或「邏輯或」合併表達式。
合併重複的條件片斷當全部分支都會執行相同代碼時，就須要將這段代碼搬移到條件表達式以外了。這樣咱們能更加清晰的知道，那些東西是隨着條件變化而變化的、那些是不變的。
移除控制標記控制標記可使用break或continue來代替，還可使用return直接返回。
以衛語句來取代嵌套表達式可讓代碼邏輯看起來更加的清晰。
以多態來取代條件表達式多態的好處在於：若是你須要根據對象的不一樣類型來採起不一樣的行爲，多態使你沒必要寫明顯的條件表達式。

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

劃分邊界肯定各個字段、方法應該處於子類仍是超類也是咱們常常須要注意的一個點。
提煉子類、超類和接口
摺疊繼承體系有時咱們會發現某個子類並無帶來該有的價值時，咱們就須要將子類的超類合併。
塑造模板函數你有一些子類，其中相應的某些函數以相同順序執行相似的操做，可是各個操做細節上有所不一樣。將這些操做分別放進獨立函數中，並保證他們有相同的簽名，因而原函數也變得相同了，而後將原函數移至超類。
以委託取代繼承當某個子類只使用接口中的一部分，或者不使用繼承而來的數據時，咱們能夠在子類新建一個字段用以保存超類：調整子類函數，令他改而委託超類；而後去掉二者間的繼承關係。