徐景周
在按照我的理解方式審查了軟件開發的生命週期後，我得出一個結論：實際上滿足工程設計標準的惟一軟件文檔，就是源代碼清單。
-- Jack Reeves
簡介
2001年，爲了解決許多公司的軟件團隊陷入不斷增長的過程泥潭，一批業界專家一起概括出了一些可以讓軟件開發團隊具有快速工作、響應變化能力的價值觀和原則，他們稱自己爲敏捷聯盟。敏捷開發過程的方法很多，主要有：SCRUM，Crystal,特徵驅動軟件開發（Feature Driven Development，簡稱FDD），自適應軟件開發(Adaptive Software Development，簡稱ASD)，以及最重要的極限編程(eXtreme Programming,簡稱XP)。極限編程(XP)是於1998年由Smalltalk社羣中的大師級人物Kent Beck首先倡導的。
極限編程
設計和編程都是人的活動。忘記這一點，將會失去一切。
-- Bjarne Stroustrup
極限編程(XP)是敏捷方法中最箸名的一個。它是由一系列簡單卻互相依賴的實踐組成。這些實踐結合在一起形成了一個勝於部分結合的整體。
下面是極限編程的有效實踐：
1、完整團隊
XP項目的所有參與者（開發人員、客戶、測試人員等）一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的牆壁上隨意懸掛着大幅的、顯著的圖表以及其他一些顯示他們進度的東西。
2、計劃遊戲
計劃是持續的、循序漸進的。每2周，開發人員就爲下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。
3、客戶測試
作爲選擇每個所期望的特性的一部分，客戶可以根據腳本語言來定義出自動驗收測試來表明該特性可以工作。
4、簡單設計
團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重複，表達出了編寫者想表達的所有東西，並且包含儘可能少的代碼。
5、結對編程
所有的產品軟件都是由兩個程序員、並排坐在一起在同一臺機器上構建的。
6、測試驅動開發
編寫單元測試是一個驗證行爲，更是一個設計行爲。同樣，它更是一種編寫文檔的行爲。編寫單元測試避免了相當數量的反饋循環，尤其是功功能能驗證方面的反饋循環。程序員以非常短的循環週期工作，他們先增加一個失敗的測試，然後使之通過。
7、改進設計
隨時利用重構方法改進已經腐化的代碼，保持代碼儘可能的乾淨、具有表達力。
8、持續集成
團隊總是使系統完整地被集成。一個人拆入（Check in）後，其它所有人責任代碼集成。
9、集體代碼所有權
任何結對的程序員都可以在任何時候改進任何代碼。沒有程序員對任何一個特定的模塊或技術單獨負責，每個人都可以參與任何其它方面的開發。
10、編碼標準
系統中所有的代碼看起來就好像是被單獨一人編寫的。
11、隱喻
將整個系統聯繫在一起的全局視圖；它是系統的未來影像，是它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那麼你就知道該模塊是錯誤的。
12、可持續的速度
團隊只有持久纔有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。
極限編程是一組簡單、具體的實踐，這些實踐結合在形成了一個敏捷開發過程。極限編程是一種優良的、通用的軟件開發方法，項目團隊可以拿來直接採用，也可以增加一些實踐，或者對其中的一些實踐進行修改後再採用。
敏捷開發
人與人之間的交互是複雜的，並且其效果從來都是難以預期的，但卻是工作中最重要的方面。
-- Tom DeMacro和Timothy Lister
敏捷軟件開發宣言：
n 個體和交互 勝過 過程和工具
n 可以工作的軟件 勝過 面面俱到的文檔
n 客戶合作 勝過 合同談判
n 響應變化 勝過 遵循計劃
雖然右項也有價值，但是我們認爲左項具有更大的價值。
敏捷宣言遵循的原則：
n 我們最優先要做的是通過儘早的、持續的交付有價值的軟件來使客戶滿意。
n 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來爲客戶創造競爭優勢。
n 經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
n 在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
n 圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。
n 在團隊內部，最具有效果並富有效率的傳遞信息的方法，就是面對面的交談。
n 工作的軟件是首要的進度度量標準。
n 敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。
n 不斷地關注優秀的技能和好的設計會增強敏捷能力。
n 簡單是最根本的。
n 最好的構架、需求和設計出於自組織團隊。
n 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行爲進行調整。
當軟件開發需求的變化而變化時，軟件設計會出現壞味道，當軟件中出現下面任何一種氣味時，表明軟件正在腐化。
n 僵化性： 很難對系統進行改動，因爲每個改動都會迫使許多對系統其他部分的其它改動。
n 脆弱性： 對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。
n 牢固性： 很難解開系統的糾結，使之成爲一些可在其他系統中重用的組件。
n 粘滯性： 做正確的事情比做錯誤的事情要困難。
n 不必要的複雜性： 設計中包含有不具任何直接好處的基礎結構。
n 不必要的重複性： 設計中包含有重複的結構，而該重複的結構本可以使用單一的抽象進行統一。
n 晦澀性： 很難閱讀、理解。沒有很好地表現出意圖。
敏捷團隊依靠變化來獲取活力。團隊幾乎不進行預先設計，因此，不需要一個成熟的初始設計。他們更願意保持設計儘可能的乾淨、簡單，並使用許多單元測試和驗收測試作爲支援。這保持了設計的靈活性、易於理解性。團隊利用這種靈活性，持續地改進設計，以便於每次迭代結束生成的系統都具有最適合於那次迭代中需求的設計。
爲了改變上面軟件設計中的腐化味，敏捷開發採取了以下面向對象的設計原則來加以避免，這些原則如下：
n 單一職責原則(SRP)
就一個類而言，應該僅有一個引起它變化的原因。
n 開放-封閉原則(OCP)
軟件實體應該是可以擴展的，但是不可修改。
n Liskov替換原則(LSP)
子類型必須能夠替換掉它們的基類型。
n 依賴倒置原則(DIP)
抽象不應該依賴於細節。細節應該依賴於抽象。
n 接口隔離原則(ISP)
不應該強迫客戶依賴於它們不用的方法。接口屬於客戶，不屬於它所在的類層次結構。
n 重用發佈等價原則(REP)
重用的粒度就是發佈的粒度。
n 共同封閉原則(CCP)
包中的所有類對於同一類性質的變化應該是共同封閉的。一個變化若對一個包產生影響，則將對該包中的所有類產生影響，而對於其他的包不造成任何影響。
n 共同重用原則(CRP)
一個包中的所有類應該是共同重用的。如果重用了包中的一個類，那麼就要重用包中的所有類。
n 無環依賴原則(ADP)
在包的依賴關係圖中不允許存在環。
n 穩定依賴原則(SDP)
朝着穩定的方向進行依賴。
n 穩定抽象原則(SAP)
包的抽象程度應該和其穩定程度一致。
上述中的包的概念是：包可以用作包容一組類的容器，通過把類組織成包，我們可以在更高層次的抽象上來理解設計，我們也可以通過包來管理軟件的開發和發佈。目的就是根據一些原則對應用程序中的類進行劃分，然後把那些劃分後的類分配到包中。
下面舉一個簡單的設計問題方面的模式與原則應用的示例：
問題：
選擇設計運行在簡易檯燈中的軟件，檯燈由一個開關和一盞燈組成。你可以詢問開關開着還是關着，也可以讓燈打開或關閉。
解決方案一：
下面圖1是一種最簡單的解決方案，Switch對象可以輪詢真實開關的狀態，並且可以發送相應的turnOn和turnOff消息給Light。
解決方案二：
上面這個設計違反了兩個設計原則：依賴倒置原則(DIP)和開放封閉原則(OCP)，DIP原則告訴我們要優先依賴於抽象類，而Switch依賴了具體類Light，對OCP的違反是在任何需要Switch的地方都要帶上Light，這樣就不能容易擴展Switch去管理除Light外的其他對象。爲了解決這個方案，可以採用ABSTRACT SERVER模式，在Switch和Light之間引入一個接口，這樣就使得Switch能夠控制任何實現了這個接口的東西，這也就滿足了DIP和OCP原則。如下面圖2所示：
解決方案三：
上面圖2所示解決方案，違返了單一職責原則(SRP)，它把Switch和Light綁定在一起，而它們可能會因爲不同的原因而改變。這種問題可以採用ADAPTER模式來解決，適配器從Switchable 派生並委託給Light，問題就被優美的解決了，現在，Switch就可以控制任何能夠被打開或者關閉的對象。但是這也需要會出時間和空間上的代價來換取。如下面圖3所示：
敏捷設計是一個過程，不是一個事件。它是一個持續的應用原則、模式以及實踐來改進軟件的結構和可讀性的過程。它致力於保持系統設計在任何時間都儘可能得簡單、乾淨和富有表現力。
參考文獻
設計模式-可複用面向對象軟件的基礎 -- 李英軍等譯
重構-改善既有代碼的設計 -- 侯捷等譯
敏捷軟件開發-原則、模式與實現 -- 鄧輝譯
聯繫方式
地址：陝西省西安市勞動路90號院(臺板廠家屬院)六單元
郵編：710082
Email: [email protected]
未來工作室(Future Studio)
