重構改善既有代碼的設計—— 讀書筆記2

重構改善既有代碼的設計的第三章—— 代碼的壞味道

書中也提到,重構是不存在精確衡量標準的。根據作者的觀點,沒有任何規則比得上一個見識廣博者的直覺。當然我們也必須培養出自己的判斷力。


下面根據書中給出的規則結合自己工作經驗,做個總結:

如果遇到以下情況,則意味着可以着手進行重構優化工作啦。

1. 重複代碼(Duplicated Code)

涉及到重複代碼的問題,在實際的開發過程中,稍有常識的開發者一般都會對其展開優化。根據重複代碼的範圍,對其方法or類進行抽象,提煉代碼。


2. 函數過長(Long Method)

我們都知道: 程序越長越難理解。所以我們在開發過程中應該積極地分解函數

通常需要遵循這樣一條規則:每當感覺需要以註釋來說明點什麼的時候,就可以考慮將需要說明的東西寫入到一個獨立的函數中,並以其用途命名。我們要意識到:函數的關鍵在於函數的功能而非長度

這裏我們需要合理地分解函數,避免引入過多參數,否則我們則需要定義類來消除過長的參數列表。

如何確定該提煉哪一段代碼呢?

書中給我們的技巧:

  1. 尋找註釋。它們通常能指出代碼用途和實現手法之間的語意距離。我們應該使函數名稱能很好的起到見名知意的效果。
  2. 條件表達式和循環也是很好的提煉信號。

3. 類內容過大(Large Class)

一個類如果擁有太多代碼,則意味着我們考慮對類進行優化,也可能意味着從架構上做出改變。比如:我們從MVC —> MVP框架的演進。


4. 參數列表過長(Long Parameter List)

全劇變量是邪惡的東西

關於參數列表過長,估計在開發過程我們自己也受不了,尤其是不知道參數對應關係的時候更是抓耳撓腮,令人抓狂。


5. 複雜的修改操作

書中提到的:

  1. 發散式變化(Divergent Change)
  2. 霰彈式修改(Shotgun Surgery)
  3. 依戀情結(Feature Envy)

從本質上來講,就是讓我們將需要變化的部分儘量集中在一處。從而避免漏改的發生。


6. switch語句

作者認爲:面向對象的程序的一個最明顯特徵就是:少用switch語句。因爲switch語句意味着重複。看到swtich語句,則應該考慮多態來替換它。

這個在類層次的話,肯定應該考慮多態


7. 未來代碼

編程中可沒有特南克斯 23333…

這裏其實挺有意思的,我們在開發的過程中,總是處於長遠的考慮,在項目中引入或者寫下暫時用不到的代碼。實際上往往用不到的…(PS:實踐出真知)

聽取作者的建議——用不上的裝置只會擋路,刪掉吧


8. 慎用繼承

繼承的侷限性:

  1. 繼承往往造成過度親密,因爲子類對超類的瞭解總是超過後者的主觀意願。
  2. 子類不想or不需要繼承超類的一部分內容。

另外,複用的意義經常被高估——大多數對象只要夠用就好。

所以我們應該考慮:使用代理替代繼承


9. 多餘註釋

在我們拿到別人的代碼時,總是希望看到對面的註釋,但是我們的目的是要更好的理解代碼的含義,而不是看註釋。

當感覺需要撰寫註釋時,請先嚐試重構,試着將所有的註釋變得多餘。

按照作者的觀點,註釋主要用來:

  1. 記述將來的打算;
  2. 標記不確定的區域;

對此,I can not agree more…,因爲我們的目的是理解代碼的含義


剛入侯門之時,讀這本書的感受就是——XJB扯…
現在讀來,猶如清風拂面…

代碼就想酒,如果感覺不到書中的觀點,那就請你再品,again and again…

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章