極限程式設計與敏捷開發

徐景周在按照我的理解方式審查了軟體開發的生命週期後，我得出乙個結論：實際上滿足工程設計標準的惟一軟體文件，就是源**清單。

-- jack reeves

簡介2023年，為了解決許多公司的軟體團隊陷入不斷增長的過程泥潭，一批業界專家一起概括出了一些可以讓軟體開發團隊具有快速工作、響應變化能力的價值觀和原則，他們稱自己為敏捷聯盟。敏捷開發過程的方法很多，主要有：scrum，crystal,特徵驅動軟體開發（feature driven development，簡稱fdd），自適應軟體開發(adaptive software development，簡稱asd)，以及最重要的極限程式設計(extreme programming,簡稱xp)。極限程式設計(xp)是於2023年由**alltalk社群中的大師級人物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 3b 不必要的複雜性：設計中包含有不具任何直接好處的基礎結構。

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所示：

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

參考文獻

設計模式-可復用物件導向軟體的基礎 -- 李英軍等譯

重構-改善既有**的設計 -- 侯捷等譯

敏捷軟體開發-原則、模式與實現 -- 鄧輝譯

極限程式設計與敏捷開發

極限程式設計與敏捷開發

極限程式設計與敏捷開發

極限程式設計與敏捷開發

相關推薦