關于refactoring思考

2019-11-18 13:19:18

字體：大中小

來源：轉載

供稿：網友

　　雖然refactoring幾乎可以隨時進行，然而，按照我們關于兩頂帽子的原則，在某些場合下，refactoring的介入顯得更加實際、有意義、富有成效。
　　
　　另外，在最后進入Refactoring實踐之前，我把Kent Beck和Martin Fowler給我們的忠告和建議放在這里。這些內容，非凡是Code Smell和命名規則不但對我們進行refactoring具有很強的實踐意義。同時，他們也促使我們對很多OO設計和編碼的原則進行更多的思考。
　　Refactoring 應用的場合
　　
　　增加功能
　　假如你的代碼不需要增加新的功能，那么你幾乎沒有必要對他進行Refactoring。增加功能是進行Refactoring最常見的起因。通常，refactoring的第一個目標就是為了讓代碼更輕易理解。Refactoring不僅僅可以使難以理解的代碼更加清楚，他也可以使你對它的理解呈現一種交互狀態，你和代碼的交互。理解了，新的功能就很輕易加入。
　　
　　另一個原因是原來代碼的結構很難直接擴展，可能是因為一個類和另外一個類的綁定太緊，或者是他使用了大量的case語句，或者是有一些重復的代碼讓你覺得加入你的代碼會使結構更差。總而言之，直接加入新功能不是太方便。這時候，你就需要Refactoring，使得舊的代碼在能讓舊的test case通過的情況下，讓新的代碼加入更加方便、快捷。
　　
　　重用
　　重用可以說是增加功能的一個特例。因為這是OO增加功能最主要的方法。但這里有一些差別。
　　
　　假如你的代碼是一個框架，那么當把代碼交給其他人使用時，你必須重點考慮框架的重用方法。譬如，你想在框架之上增加一層facade，這時候，你可能需要refactoring一些內部類，讓這個Facade的結構更輕易加入。
　　
　　對框架Refactoring可能需要是一個反饋的過程。因為框架一旦穩定就可能長期存在，一般你不會直接對這個框架增加功能。這時，不同應用程序對框架使用經驗的積累可能使得你的Refactoring具有更加明確的目標，更加深層次的抽象。
　　
　　修正bug
　　bug產生的原因有很多。可能是你對解決的問題理解不夠，也可能是程序的代碼過于紛亂。當你的代碼結構不是很清楚時，bug往往隱藏在代碼之中，使你很難發現。應用Refactoring讓代碼結構結構更清楚的同時，也使得bug自動浮出水面。
　　
　　Refactoring所追求的目標和過程往往使得代碼的Bug無處遁形。Eric E. Allen在IBM中developerWorks的bug pattern中的一個模式就是copy-and-paste方法造成代碼重復，從而產生bug的一個例子。這個 Rogue Title Pattern是一個非經常見的bug例子，當你修正了程序中一個bug時，你發現程序運行的結果是你明明已經修正的bug還在作怪。究其原因，就是程序員在實現一個功能的時候把一段代碼復制過去，稍加修改，就成為一個新的函數。你修改了一個地方，但卻忘了另外一個地方。
　　
　　Refactoring力求排除重復代碼，假如有這樣的bug，在refactoring以后，一次修改就能糾正所有的問題。
　　
　　Code Review
　　Review可以使得專家知識傳播到整個開發隊伍。他們能夠幫助更多的人理解一個大系統更多方面的問題。它們對于編寫清楚的代碼也有很好的幫助。俗話說得好，三個臭皮匠頂一個諸葛亮，Review也使得你能夠接受更多其他人的好意見和想法，從而使你的設計和代碼更加合理。
　　
　　按照Martin Fowler的建議，我使用refactoring作為我的主要review方法。我有比較多的機會做這樣的Code Review，在程序員發現一個難以解決的bug，或者當他們覺得自己的思路無法進行下去的時候，他們通常會要求我的幫助。
　　
　　我的方法通常是問幾個簡單的問題，然后直接找到他們的代碼，進行refactoring，在這個過程中，我總是一邊refactoring，一邊和程序員講解我這樣做的意圖。令人驚異的是，一旦我這樣去做，程序員往往能夠在我refactoring的過程中自己發現問題。由于Refactoring的結果非常具體，我很輕易對程序員講述一些本來就可以直接這樣實現的例子，這對提高程序員的編程能力有極大的幫助。
　　
　　味道
　　Kent Beck的" Code Smell"或許是OO社團最有人情味的名言了。Martin Fowler和Kent Beck專門合著了《Refactoring》其中的一章就叫《Bad Smells in Code》。
　　
　　雖然對Refactoring的研究涉及到了形式化地探測代碼的結構，譬如專門的重復代碼監測工具。但這些研究尚處于幼年期。更何況，很多代碼的結構并不是能夠用簡單的數字統計和抽象語法樹所能解決的。
　　
　　Code Smell是高水平的程序員對代碼的一種感覺，當你能夠聞到這樣的味道時，你就可以在不涉及到程序所要解決的具體問題時，就"聞到"代碼結構的好壞。
　　
　　Kent Beck 和Martin Fowler列出的代碼味道有：
　　
　　Duplicated Code
　　代碼重復幾乎是最常見的異味了。他也是Refactoring的主要目標之一。代碼重復往往來自于copy-and-paste的編程風格。與他相對應OAOO是一個好系統的重要標志（請參見我的duplicated code一文）。
　　
　　Long method
　　它是傳統結構化的"遺毒"。一個方法應當具有自我獨立的意圖，不要把幾個意圖放在一起，我的《大類和長方法》一文中有具體描述。
　　
　　Large Class
　　大類就是你把太多的責任交給了一個類。這里的規則是One Class One Responsibility。參見我的《大類和長方法》。
　　
　　Divergent Change
　　一個類里面的內容變化率不同。某些狀態一個小時變一次，某些則幾個月一年才變一次；某些狀態因為這方面的原因發生變化，而另一些則因為其他方面的原因變一次。面向對象的抽象就是把相對不變的和相對變化相隔離。把問題變化的一方面和另一方面相隔離。這使得這些相對不變的可以重用。問題變化的每個方面都可以單獨重用。這種相異變化的共存使得重用非常困難。
　　
　　Shotgun Surgery
　　這正好和上面相反。對系統一個地方的改變涉及到其他許多地方的相關改變。這些變化率和變化內容相似的狀態和行為通常應當放在同一個類中。
　　
　　Feature Envy
　　對象的目的就是封裝狀態以及與這些狀態緊密相關的行為。假如一個類的方法頻繁用get方法存取其他類的狀態進行計算，那么你要考慮把行為移到涉及狀態數目最多的那個類。
　　
　　Data Clumps
　　某些數據通常像孩子一樣成群玩耍：一起出現在很多類的成員變量中，一起出現在許多方法的參數中… ，這些數據或許應該自己獨立形成對象。
　　
　　PRimitive Obsession
　　面向對象的新手通常習慣使用幾個原始類型的數據來表示一個概念。譬如對于范圍，他們會使用兩個數字。對于Money，他們會用一個浮點數來表示。因為你沒有使用對象來表達問題中存在的概念，這使得代碼變的難以理解，解決問題的難度大大增加。好的習慣是擴充語言所能提供原始類型，用小對象來表示范圍、金額、轉化率、郵政編碼等等。
　　
　　Switch Statement
　　基于常量的開關語句是OO的大敵，你應當把他變為子類、state或
　　trategy。
　　Parallel Inheritance Hierarchies
　　并行的繼續層次是shotgun surgery的非凡情況。因為當你改變一個層次中的某一個類時，你必須同時改變另外一個層次的并行子類。
　　
　　Lazy Class
　　一個干活不多的類。類的維護需要額外的開銷，假如一個類承擔了太少的責任，應當消除它。
　　
　　Speculative Generality
　　一個類實現了從未用到的功能和通用性。通常這樣的類或方法唯一的用戶是test case。不要猶豫，刪除它。
　　
　　Temporary Field
　　一個對象的屬性可能只在某些情況下才有意義。這樣的代碼將難以理解。專門建立一個對象來持有這樣的孤兒屬性，把只和他相關的行為移到該類。最常見的是一個特定的算法需要某些只有該算法才有用的變量。
　　
　　Message Chain
　　消息鏈發生于當一個客戶向一個對象要求另一個對象，然后客戶又向這另一對象要求另一個對象，再向這另一個對象要求另一個對象，如此如此。這時，你需要隱藏分派。
　　
　　Middle Man
　　對象的基本特性之一就是封裝，而你經常會通過分派去實現封裝。但是這一步不能走得太遠，假如你發現一個類接口的一大半方法都在做分派，你可能需要移去這個中間人。
　　
　　Inappropriate Intimacy
　　某些類相互之間太親密，它們花費了太多的時間去磚研別人的私有部分。對人類而言，我們也許不應該太假正經，但我們應當讓自己的類嚴格遵守禁欲主義。
　　
　　Alternative Classes with Different Interfaces
　　做相同事情的方法有不同的函數signature，一致把它們往類層次上移，直至協議一致。
　　
　　Incomplete Library Class
　　要建立一個好的類庫非常困難。我們大量的程序工作都基于類庫實現。然而，如此廣泛而又相異的目標對庫構建者提出了苛刻的要求。庫構建者也不是萬能的。有時候我們會發現庫類無法實現我們需要的功能。而直接對庫類的修改有非常困難。這時候就需要用各種手段進行Refactoring。
　　
　　Data Class
　　對象包括狀態和行為。假如一個類只有狀態沒有行為，那么肯定有什么地方出問題了。
　　
　　Refused Bequest
　　超類傳下來很多行為和狀態，而子類只是用了其中的很小一部分。這通常意味著你的類層次有問題。
　　
　　Comments
　　經常覺得要寫很多注釋表示你的代碼難以理解。假如這種感覺太多，表示你需要Refactoring。
　　
　　Refactoring和命名
　　Refactoring使代碼更輕易理解的最有效和常用的手段之一就是給類、方法和屬性一個恰如其分的名字。很多公司和個人都編出了大量的代碼命名規范。假如這些規范太繁瑣，那就無法執行。有好的命名規則是好事，但并不總是如此。最重要的是，在整個

上一篇：在 Java 中如何進行 BASE64 編碼和解碼

下一篇：vtk在Java2中的使用