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