本篇接著談論 Chapter 8 的後半部分，我將談到兩個主題：
今天的內容會比較輕鬆，偏概念性。Here we go!
簡言之，如何在不同領域中找到共同點：找到變化的地點，稱為共通性分析。
根據 Jim Coplien 的說法：
共通性分析就是尋找一些共同的元素，他們能夠幫助我們理解系列成員的共同之處在哪裡。
舉例來說，一隻鴨子、一隻袋鼠、一個人類，它們的共同點就是它們都是「用兩腳行走的動物」。有了共通性分析，我們就能更容易討論做為用兩腳行走的動物，它們有拿些差異。
找出如何變化，稱為可變性分析。而可變性只有在指定共通性之後才有意義：
共通性分析尋找的是不可能隨時間而改變的結構，而可變性則是要找到可能變化的結構。
從架構的視角來看，共通性分析為架構提供長效的要素，而可變性分析則促進它適應實際使用所需。
如果我們把軟體設計的三種視角加入上述的思考，我們會得到下圖（還原得很醜）：
共通性分析與概念視角相互關聯；可變性分析與實作視角相互關聯。
規約視角夾在中間與另外兩種視角互動：
| 定義⋯⋯時 | 必須問自己⋯⋯ |
|---|---|
| 抽象類別（共通性） | 需要用什麼介面來處理這個類別的所有責任 |
| 衍生類別（可變性） | 對於這個指定的特定實作，應該如何根據指定的規約來實作它 |
接下來我們來討論敏捷程式設計。
敏捷程式設計遵循著「一邊開發一邊設計」，在程式設計的同時進行驗證。
設計模式常常被描述為需要「預先設計再做開發」，看起來與敏捷程式開發是矛盾的。
但本書作者認為，它們的目標是相同的：敏捷開發企圖讓程式碼更具有可變性；設計模式要的是能產生更靈活的程式碼。
而且，敏捷程式設計與設計模式都關心高品質的程式碼。這些品質有：無冗餘、可讀、可測試。
無冗餘簡言之：某個規則只要在一個地方實作。這就是我們先前提過的 DRY (Don't Repeat Yourself) 原則；Kent Beck 稱之為 OOAO (One and Only Once) 原則。
冗餘與耦合之間關係緊密：如果存在冗餘，那麼當修改其中一部分時，極有可能另一部分也是需要修改的。因此，兩部分的程式碼是相互耦合的。
「依介面設計」的做法 —— 找出變化並且封裝，使程式碼高內聚 —— 正式消除冗餘需要的。
所以，良好地運用設計模式也能避免冗餘發生。
依照極限程式設計宣導者 Ron Jeffries 所說，能夠產生好讀的程式碼，需要「依企圖做程式設計」，因為在閱讀程式時，我們往往是看程式碼的意圖，而不是細節的實作。
而依企圖做程式設計在此又與設計模式的「依介面設計」的原則類似，都是在不考慮實作的情況下先建立介面。
可測試的程式碼是敏捷開發的核心。可測試性也與其他實踐密切相關：
Chapter 8 到這裡告一個段落。下一篇將介紹另一個設計模式：Strategy 模式。明天見！
iThome鐵人賽
看影片追技術