### 從重構聯想到軟件復用和技術傳播
前面所提的現實世界問題,并不僅僅存在于重構中。它們廣泛存在于軟件的演化(evolution)和復用(reuse)中。
過去數年,我用了很多時間來關注軟件復用性、平臺、框架、模式、遺留系統(往往涉及「非面向對象」軟件)的發展相關問題。除了在朗訊(Lucent)和貝爾實驗室(Bell Labs)開發項目,我還參加了其他公司的員工討論會——他們也曾經與類似問題搏斗過。.[19], [20], [21], [22]
「可復用法」的現實問題,和重構的相關問題很類似:
- 技術人員可能不知道「該復用什么」或「如何復用」。
- 技術人員可能對于采用「可復用法」(reuse approach )缺乏動力,除非他們能夠獲得短期利益。
- 如果要成功適應「可復用法」(reuse approach ),額外開銷(Overhead)、學習曲線(learning curve)和發現成本(discovery cost )都必須考慮。
- 因釆用「可復用法」(reuse approach )不該引起項目混亂。項目中可能有很大壓力:盡管面對遺留系統的束縛,仍應讓現有資產或實現品獲得杠桿作用。 新的實現品應該與現有系統協同工作,或至少向下兼容于現有系統。
Geoffrey Moore[23] 把「技術的接納過程」描述為一條鐘型(bell-shaped )曲線:前段包括先行者(innovators )和早期接受者(early adopters),中部急劇增加的人群包括早期消費群體(early majority )和晚期消費群體( late majority),后段則是那些行動緩慢者(laggards)。一個思想或產品如果要成功,必須得到早期消費者和晚期消費者的廣泛支持。另一方面,許多對于先行者和早期接受者很有吸引力的想法, 最終徹底失敗,因為它們沒能跨越鴻溝,讓早期消費者和晚期消費者接納它們。之所以有這樣的鴻溝是因為,不同的消費人群有著不同的消費動機。先行者和早期接受者感興趣的是新技術、「范式移轉和突破性思想」的愿景(visions of paradigm shifts and breakthroughs)。早期和晚期消費群則主要關心成熟度、成本、支持,以及這種新思想或新產品是否被「與他們有著相似需求」的其他人成功套用。
要打動并說服軟件開發者,所需方式和打動并說服軟件研究者是完全不同的。軟件研究者通常是Moore 所說的「先行者」,軟件開發者(尤其是軟件經理)則往往屬于早期或晚期消費者。如果想要讓你的思想深入所有人心,了解這一差異是非常重要的。是的,無論軟件復用或重構,要想打動軟件開發者,這一點都至關重要。
在朗訊(Lucent)和貝爾實驗室(Bell Labs )中我發現,鼓勵「復用性」應用及運行其必要平臺,得冒一點風險。這需要主管人員精心制定策略、在中階經理層組織領導會議、與項目開發組協商、通過研討會和出版物向廣大研究人員和開發人員宣揚這些技術的好處。在這整個過程中,很重要的幾件事是:對員工進行培訓、盡量獲取短期利益、減少額外開銷、安全引入新技術。這些見識,都是從我對重構的研 究中得來的。
我的論文指導教授Ralph Johnson 審查本章草稿時指出:這些原則不僅可應用于重構和軟件復用性,同時也是技術傳播時的常見問題。如果你正試圖說服別人重構(或采用其他某種技術或實踐),請注意保證自己隨時關注這些問題,這樣才能深入人心。技術的傳播是很困難的,但不是做不到。
- 譯序 by 侯捷
- 譯序 by 熊節
- 序言
- 前言
- 章節一 重構,第一個案例
- 起點
- 重構的第一步
- 分解并重組statement()
- 運用多態(Polymorphism)取代與價格相關的條件邏輯
- 結語
- 章節二 重構原則
- 何謂重構
- 為何重構
- 「重構」助你找到臭蟲(bugs)
- 何時重構
- 怎么對經理說?
- 重構的難題
- 重構與設計
- 重構與性能(Performance)
- 重構起源何處?
- 章節三 代碼的壞味道
- Duplicated Code(重復的代碼)
- Long Method(過長函數)
- Large Class(過大類)
- Long Parameter List(過長參數列)
- Divergent Change(發散式變化)
- Shotgun Surgery(散彈式修改)
- Feature Envy(依戀情結)
- Data Clumps(數據泥團)
- Primitive Obsession(基本型別偏執)
- Switch Statements(switch驚悚現身)
- Parallel Inheritance Hierarchies(平行繼承體系)
- Lazy Class(冗贅類)
- Speculative Generality(夸夸其談未來性)
- Temporary Field(令人迷惑的暫時值域)
- Message Chains(過度耦合的消息鏈)
- Middle Man(中間轉手人)
- Inappropriate Intimacy(狎昵關系)
- Alternative Classes with Different Interfaces(異曲同工的類)
- Incomplete Library Class(不完美的程序庫類)
- Data Class(純稚的數據類)
- Refused Bequest(被拒絕的遺贈)
- Comments(過多的注釋)
- 章節四 構筑測試體系
- 自我測試代碼的價值
- JUnit測試框架
- 添加更多測試
- 章節五 重構名錄
- 重構的記錄格式
- 尋找引用點
- 這些重構準則有多成熟
- 章節六 重新組織你的函數
- Extract Method(提煉函數)
- Inline Method(將函數內聯化)
- Inline Temp(將臨時變量內聯化)
- Replace Temp with Query(以查詢取代臨時變量)
- Introduce Explaining Variable(引入解釋性變量)
- Split Temporary Variable(剖解臨時變量)
- Remove Assignments to Parameters(移除對參數的賦值動作)
- Replace Method with Method Object(以函數對象取代函數)
- Substitute Algorithm(替換你的算法)
- 章節七 在對象之間搬移特性
- Move Method(搬移函數)
- Move Field(搬移值域)
- Extract Class(提煉類)
- Inline Class(將類內聯化)
- Hide Delegate(隱藏「委托關系」)
- Remove Middle Man(移除中間人)
- Introduce Foreign Method(引入外加函數)
- Introduce Local Extension(引入本地擴展)
- 章節八 重新組織數據
- Self Encapsulate Field(自封裝值域)
- Replace Data Value with Object(以對象取代數據值)
- Change Value to Reference(將實值對象改為引用對象)
- Replace Array with Object(以對象取代數組)
- Replace Array with Object(以對象取代數組)
- Duplicate Observed Data(復制「被監視數據」)
- Change Unidirectional Association to Bidirectional(將單向關聯改為雙向)
- Change Bidirectional Association to Unidirectional(將雙向關聯改為單向)
- Replace Magic Number with Symbolic Constant(以符號常量/字面常量取代魔法數)
- Encapsulate Field(封裝值域)
- Encapsulate Collection(封裝群集)
- Replace Record with Data Class(以數據類取代記錄)
- Replace Type Code with Class(以類取代型別碼)
- Replace Type Code with Subclasses(以子類取代型別碼)
- Replace Type Code with State/Strategy(以State/strategy 取代型別碼)
- Replace Subclass with Fields(以值域取代子類)
- 章節九 簡化條件表達式
- Decompose Conditional(分解條件式)
- Consolidate Conditional Expression(合并條件式)
- Consolidate Duplicate Conditional Fragments(合并重復的條件片段)
- Remove Control Flag(移除控制標記)
- Replace Nested Conditional with Guard Clauses(以衛語句取代嵌套條件式)
- Replace Conditional with Polymorphism(以多態取代條件式)
- Introduce Null Object(引入Null 對象)
- Introduce Assertion(引入斷言)
- 章節十一 處理概括關系
- Pull Up Field(值域上移)
- Pull Up Method(函數上移)
- Pull Up Constructor Body(構造函數本體上移)
- Push Down Method(函數下移)
- Push Down Field(值域下移)
- Extract Subclass(提煉子類)
- Extract Superclass(提煉超類)
- Extract Interface(提煉接口)
- Collapse Hierarchy(折疊繼承關系)
- Form Template Method(塑造模板函數)
- Replace Inheritance with Delegation(以委托取代繼承)
- Replace Delegation with Inheritance(以繼承取代委托)
- 章節十二 大型重構
- 這場游戲的本質
- Tease Apart Inheritance(梳理并分解繼承體系)
- Convert Procedural Design to Objects(將過程化設計轉化為對象設計)
- Separate Domain from Presentation(將領域和表述/顯示分離)
- Extract Hierarchy(提煉繼承體系)
- 章節十三 重構,復用與現實
- 現實的檢驗
- 為什么開發者不愿意重構他們的程序?
- 現實的檢驗(再論)
- 重構的資源和參考資料
- 從重構聯想到軟件復用和技術傳播
- 結語
- 參考文獻
- 章節十四 重構工具
- 使用工具進行重構
- 重構工具的技術標準(Technical Criteria )
- 重構工具的實用標準(Practical Criteria )
- 小結
- 章節十五 集成
- 參考書目