|
Refactoring場合和基本命名規則
石一楹 ([email protected])
浙江大學靈峯科技開發公司技術總監
2001 年 12 月
雖然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或strategy。
- 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使代碼更容易理解的最有效和常用的手段之一就是給類、方法和屬性一個恰如其分的名字。很多公司和個人都編出了大量的代碼命名規範。如果這些規範太繁瑣，那就無法執行。有好的命名規則是好事，但並不總是如此。最重要的是，在整個項目開發團隊內，必須保持一致的命名規則，也許不是世界上最好的，但卻是對該項目最好的。下面一些是Refactoring中一些有效的命名原則：
類命名
Kent Beck提出其中大多數的規則。Kent Beck的《Smalltalk Best Practice Pattern》是我至今爲止讀過的所有書裏面最符合我審美觀點的書籍-淵博的知識和春秋的筆法。
簡單超類名-傳達設計目的
命名總要受各種因素的影響。你想把名字取得儘量短，易於輸入、格式化、容易說出口。同時，你也想讓名字儘可能包含更多的信息，這樣讀者就能夠更快地理解名字所包含的實際內容。你可能取一些儘量爲人所熟悉的名字，這樣在名字中就可以傳遞更多的共同經驗。同時，你也想讓名字儘量唯一，別人的代碼命名就不會和你重複。
Kent Beck給出的第一個規則就是不要縮寫。縮寫對輸入（20年內10-100次）的考慮多餘對理解（20年內1000-10000次）的考慮。理解縮寫詞需要兩步，第一步理解這些縮寫代表的詞語，第二步採取理解這些詞語所代表的意義。
對一個大層次的根類命名是一個重大的決策。在未來的20年中，人們可能不斷地使用你所給出的名字。你必須不犯錯誤。
人們通常在命名超類時加上各種各樣的修飾，富有計算機科學意義、給人深刻印象但最終卻沒有意義的單詞，如Object，Thing，Component，Part，Manager，Entity或Item。
你在創建一個詞彙表，而不是寫一個程序。暫時做一回詩人。簡單、生氣勃勃、容易記憶遠遠比說出全部內容更有效。規則：
Name a superclass with a single word that conveys its purpose in the design。
（用一個單詞命名超類，傳達它的設計目的），好的例子包括：Number 、Collection、Magnitude、Model
全稱子類名-區分異同
命名類的一種方法是給一個唯一的名字。唯一的名字可以讓你用用最短的信息表達最多的信息。
這對於通用術語來說是對的。Array是Collection的一個子類，因爲絕大多數人都知道"Array"意味着什麼。
但在絕大多數情況下，類繼承的層次結構對於理解你的代碼十分重要，特別是一個子類概念上是超類的變種同時又和超類共享實現的情況。你需要傳遞兩部分信息：1. 新類如何相同，以及 2. 新類如何不同
要表達相同，你可以借用超類的名字。這不一定是一個直接的子類和父類關係，層次上有一定距離也無妨。要表達不同，你需要一個單詞確切地強調新類爲什麼不是超類的理由。所以，有規則：Name subclasses in your hierarchies by prepending on an adjective to the superclass name。（在超類名字前加上內容命名你層次中的子類。）例如：BigInteger 是一個可以表達很大很大數字的整數。
方法命名-揭示意圖
爲什麼好的代碼總有很多簡單的方法，代碼可能只有一行，譬如：
class ParagraphEditor。。。。
public void highlight（aRectangle:Rectangle）{
reverse(aRectangle);
}
|
這個highlight只是分派到reverse，爲什麼還需要？關鍵在於Communication。因爲有了這個方法，以後的代碼就可以用highlight來說話。我要加亮一個區域，我就highlight它。
你當然可以直接使用reverse，結果是一樣的。但所有調用代碼都揭示了實現-"我通過反轉一個矩形來加亮它"。代碼應當揭示意圖，它另外的好處是可以更方便通過繼承修整。如果你想要一個ParagraphEditor用顏色加亮，那麼只需繼承ParagraphEditor並覆蓋highlight即可。所以：
communicate what is to be done rather than how it is to be done。(傳達你要做什麼（接口）而不是你如何做（實現）)
實例（臨時）變量命名-暗示角色
任何實例變量傳達的信息包括兩部分：
- 什麼是它的目的？
- 它如何被使用？
一個變量的目的或者說它擔當的角色對讀者非常重要，因爲它能夠正確地引導讀者的注意力。一般，你在閱讀代碼時腦袋裏總有一個目的。如果你理解變量的角色，而這個角色和你的目的無關，那麼你可以直接跳過使用該變量的無關代碼。如果發現該變量的角色和你的目的有關，那麼你就能馬上縮小你的閱讀範圍-那些引用此變量的相關代碼。
一個變量如何被使用和發送給它什麼消息通常是它的"類型"。理解類型並非不重要。但是，對於實例變量來說，你能夠了解這個變量所擔當角色的唯一地方就是它的名字。如果一個Point中有兩個實例變量叫做int1、int2而並非x、y，那麼在你理解哪一個是橫向座標，哪一個是縱向座標前，你可能要都上一堆代碼。更何況你還要閱讀與之相關的很多代碼。而變量的類型很容易從它聲明、傳遞給它的消息看出來。所以：
Name instance variable for the role they play in the computation。Make the name plural if the variable will hold a Collection。
（用計算中實例變量所承擔的角色對它命名。如果變量持有一個集合，使用複數。）
參考書目
- Martin Fowler : 《Refactoring：Improving the design of existing Code》
- Kent Beck：《Extreme Programming Explained》
- Kent Beck：《Smalltalk Best Practice Pattern》
- William C. Wake: 《Extreme Programming Explored》
- Jeff Langr： 《Evolution of Test and Code Via Test-First Design》
- Robert C. Martin: 《An Extreme Programming Episode》
- Don Robert，John Brant and Ralph Johnson:《A Refactoring Tool for Smalltalk》
- Jrefactory： jrefactory.Sourceforge.net
- Gamma , Junit: http://members.pingnet.ch/gamma/junit.htm
- Refactoring Browser: http://chip.cs.uiuc.edu/users/brant/Refactory/
- GOF：《Design Patterns: Elements of Reusable Object Oriented Software》
- MartinFowler :《UML distilled》
- Braint Foote and Joseph Yoder：《Big Ball of Mud》
- William Opdyke Ph.D. Thesis：《Refactoring Object-Oriented Frameworks》
- Braint Foote and William Opdyke:《Life Cycle and Refactoring Patterns that Support Evolution and Reuse》
- Mel O Cinneide：Ph.D. :《Automated Application of Design Patterns: a Refactoring Approach》
- Donald Bradley Roberts: Ph.D.:《Practical Analysis for Refactoring》
- C2：www.c2.com
- Eric Gamma, Kent Beck: Junit: http://www.junit.org
- Lance Tokuda:《Evolving Object-Oriented Designs with Refactoring》
- Michael Hunger：《Refactoring：Benefits and Disadvantages》
- TOMCAT BOOK
- Shiyiying：Code Smell serials
- William F. Opdyke,Object-Oriented Refactoring，Legacy Constraints and Reuse
- Stephen R.Schach:《Classical and Object-Oriented Software Engineering》
- Christopher Alexander：《The Timeless Way of Building》
| 
