敏捷式軟體開發 (Agile Software Development)讀書筆記（三）

標籤：

敏捷設計

　　如果敏捷性（Agility）是指以微小增量的方式構建軟體，那麼究竟如何去設計軟體呢？又如何去確保軟體具有靈活性、可維護性以及可重用性的良好結構呢？

在敏捷團隊中，全域視圖和軟體一起演化。在每次迭代中，團隊改進系統設計，使設計儘可能的適合當前系統。團隊不會花費許多時間去預測未來的需求和需要，也不會試圖在今天就構建一些基礎結構去支撐那些他們認為明天才會需要的特性。他們更願意關注當前的系統結構，並使它儘可能的好。

那麼怎麼才能保證全域視圖和軟體一起演化呢？在軟體出現下面任何一種氣味時，就表明軟體正在腐化。敏捷團隊的成員就會採取一些動作來阻止軟體的腐化。下面列舉的就是常見的設計的臭味——腐化軟體的氣味[1]。

1. 僵化性（Rigidity）：很難對系統進行改動，因為每個改動都會迫使許多對系統其他部分的其他改動。

2.脆弱性（Fragility）：對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。

3.牢固性（Immobility）：很難解開系統的糾結，使之成為一些可在其他系統中重用的組件。

4.粘滯性（Viscosity）：做正確的事情比做錯誤的事情要困難。

5.不必要的複雜性（Needless Complexity）：設計中包含有不具任何直接好處的基礎結構。

6.不必要的重複（Needless Repetition）：設計中包含有重複的結構，而該重複的結構本可以使用單一的抽象進行統一。

7.晦澀性（Opacity）：很難閱讀、理解。沒有很好的表現出意圖。

是什麼激發了軟體的腐化呢？在非敏捷環境中，由於需求沒有按照初始設計預見的方式進行變化，從而導致了設計的退化。通常，改動都很急迫，並且進行改動的開發人員對於原始的設計思路並不熟悉。因而，雖然對設計的改動可以工作，但是它卻以某種方式違反了原始的設計。隨著改動的不斷進行，這些違反漸漸地的積累，設計開始出現臭味。

然而，我們不能因為設計的退化而責怪需求的變化。作為軟體開發人員，我們對於需求變化有非常好的瞭解。事實上，我們中的大多數人都認識到需求是項目中最不穩定的要素。如果我們的設計由於持續、大量的需求變化而失敗，那就表明我們的設計和實踐本身是有缺陷的。我們必須要設法找到一種方法，使得設計對於這種變化具有彈性，並且應用一些實踐來防止設計腐化。

與傳統的軟體開發方法懼怕需求變化相反，敏捷團隊依靠變化來擷取活力。團隊幾乎不進行預先設計，因此，不需要一個成熟的初始設計。他們更願意保持系統設計儘可能的乾淨、簡單，並使用許多單元測試和驗收測試作為支援。這保持了設計的靈活性、易於理解性。團隊利用這種靈活性，持續的改進設計，以便於每次迭代結束所產生的系統都具有最適合於那次迭代中需求的設計。

上面的描述非常美好，讀者不僅會問：敏捷開發人員如何知道要做什麼的呢？

答案是：

（1）、他們遵循敏捷實踐去發現問題；

（2）、他們應用設計原則去診斷問題；

（3）、他們應用適當的設計模式去解決問題。

軟體開發的這三個方面的相互作用就是設計。

總結來說：敏捷設計是一個過程，不是一個事件。它是一個持續的應用原則、模式以及實踐來改進軟體的結構和可讀性的過程。它致力於保持系統設計在任何時間都儘可能得簡單、乾淨以及富有表現力[1]。

設計原則

設計原則有助於開發人員消除設計中的臭味，並為當前的特性集構建出最好的設計。值得強調的是：這些設計原則是數十年軟體工程經驗來之不易的成果。它們不是某一個人的成果，而是許許多多軟體開發人員和研究人員思想和著作的結晶。雖然在此把它們表述為物件導向設計的原則，但是事實上它們只是軟體工程中一直存在的原則的特例而已。

這些原則如下：

1.單一職責原則（The Single Responsibility Principle，簡稱SRP）：就一個類而言，應該僅有一個引起它變化的原因[1]。在SRP中，我們把職責定義為“變化的原因（）”。如果你能夠想到多於一個的動機去改變一個類，那麼這個類就具有多於一個的職責。軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。事實上，我們將要論述的其餘原則都會以這樣或那樣的方式回到這個問題上。

2.開放封閉原則（The Open-Close Principle，簡稱OCP）：軟體實體（類、模組、函數等等）應該是可以擴充的，但是不可以修改的。遵循開放封閉原則設計出的模組具有兩個主要的特徵。它們是：（1）、對於擴充是開放的。這意味著模組的行為是可以擴充的。當應用的需求改變時，我們可以對模組進行擴充，使其具有滿足那些改變的新行為。換句話說，我們可以改變模組的功能。（2）、對模組行為進行擴充時，不必改動模組的原始碼或者二進位代碼。模組的二進位可執行版本，無論是可連結的庫、DLL或者Java的.jar檔案，都無需改動。

3.Liskov替換原則（The Liskov Substitution Principle，簡稱LSP）：子類型必須能夠替換掉它們的基底類型。OCP原則是OOD中很多說法的核心。LSP是使OCP成為可能的主要原則之一。正式子類型的可替換性才使得使用基類類型的模組在無需修改的情況下就可以擴充。這種可替換性必須是開發人員可以隱式依賴的東西。

4.依賴倒置原則（The Dependency Inversion Principle，簡稱DIP）：（1）、高層模組不應該依賴於底層模組。二者都應該依賴於抽象。（2）、抽象不應該依賴於細節。細節應該依賴於抽象。使用傳統的過程化設計所建立出來的依賴關係結構，策略是依賴於細節的。物件導向的程式設計倒置了依賴關係結構，使得細節和策略都依賴於抽象，並且常常是客戶擁有服務介面。事實上，這種依賴關係正式好的物件導向設計的標誌所在。

5.介面隔離原則（The Interface Segregation Interface，簡稱ISP）：不應該強迫客戶依賴它們不用的方法[3]。如果強迫客戶程式依賴於那些它們不適用的方法，那麼這些客戶程式就面臨著由於這些未使用方法的改變所帶來的變更。這就無意中導致了所有客戶程式之間的耦合。我們希望儘可能地避免這種耦合，因此我們希望分離介面。

 總結

　　敏捷式軟體開發 (Agile Software Development)方法正是認識到軟體開發的這一本質特徵而提出的革新性開發方法。使用敏捷開發方法會給我們帶來巨大的好處。當然要完全做到也是很困難的。這不僅需要對敏捷的深刻理解，更需要敏捷團隊成員的共同努力。

敏捷式軟體開發 (Agile Software Development)讀書筆記（三）