在敏捷方法中，極限編程（XP：eXtreme Programming）是其中最著名的一個，它由一系列簡單卻互相依賴的實踐組成。。。

本篇博客，對極限編程做一個簡述，以及個人的一些理解，主要從以下幾點進行。。。

客戶作為團隊成員

良性計劃

簡單設計

結對編程

持續集成

TDD和UAT

重構

隱喻

一、客戶作為團隊成員

關鍵詞：面對面溝通

首先明確一點，這里的客戶不僅僅指為我們產品付費或使用產品的外部客戶，它還包括公司內部的業務部門，有合作關系的甲方、第三方等。

XP團隊中的客戶是指：定義產品特性并對其進行排列優先級的人或者團體，即今天我們俗稱的產品、業務分析師、項目經理等一類人。

它所追求的是“客戶”和開發人員在同一個環境中工作。這里的環境由小到大可以是：同一個房間——距離在100米內——更遠；距離越遠，客戶越難以融入到團隊中來。

在XP中，面對面溝通，是最有效最簡潔的交流方式！

二、良性計劃

1、初始計劃

關鍵詞：確定重要的需求，快速響應，工時預估

項目開始時，開發人員和“客戶”應盡量確定出真正重要的需求，而不是所有的需求。因為隨著項目進展，需求也處在隨時或大或小的變更中。

只需要確定真正重要的需求，保持開發方向正確即可，這樣也方便對變更的快速響應和調整。

在“客戶”不斷編寫變更需求的時候，開發人員也應該對需求進行預估。工時預估是相對的，而不是絕對的，應流出一定的緩沖時間。

如果需求太大，那么就需要對其進行拆分，直至可以相對準確的進行工時預估和詳細的開發設計為止。

2、發布計劃

關鍵詞：需求可替換，隨時調整

知道了開發速度后，“客戶”即可知道需求的實現成本（包括人力、時間等資源）、商業價值、優先級別。

在開發過程中，可以根據具體的開發進度、實現難易程度而不斷調整需求的優先級，甚至進行需求替換，即：優先級。

初始可能對優先級等情況的判斷不是很準確，但隨著開發進度不斷精確，預估調整也可以不斷精確。

3、迭代計劃

關鍵詞：每次迭代做什么？

在XP中，一般的迭代周期為1-2周，迭代周期內需求的實現順序取決于技術決策范疇，應采用最具技術意義的順序來實現這些需求，可以串行也可以并行開發。

確定迭代后，正在開發的需求則不應被更改，還未開發的需求可以根據具體情況進行調整。

4、任務計劃

關鍵詞：開發和“客戶”達成一致約定

每次新的迭代開始時，開發人員應和“客戶”共同約定任務計劃。開發人員對需求進行任務拆分，“客戶”對需求進行初始的優先級調整排列。

計劃的方式可以采用任務列表、便箋、白板標示等方式，每完成一項，則應對其進行標注，對任務進度隨時更新。

三、簡單設計

關鍵詞：關于XP的三條指導原則

1、考慮能夠工作的最簡單的事情

盡可能尋找能實現當前需求的最簡單的設計，多考慮不同的方案，然后選擇一種我們可以實際得到和最簡單的解決方案。

2、你將不需要它

只有在確定真的需要引入某些基礎結構（比如數據庫、通信服務框架）性價比更高時，再去引入它們。

3、有且只有一次

在面向對象編程原則中，有一個叫做“共同重用原則”，即消除重復的代碼。

簡單來說就是將重復或相似度較高的代碼變成函數，封裝成一個統一的抽象集合，然后在使用時調用即可（這也將進一步減少代碼間的耦合）。

四、結對編程

關鍵詞：編碼標準、共同所有權

在XP中，結對編程指的是由2個開發人員公用一臺電腦，一個人進行編碼，另一個進行觀察并尋找代碼中的錯誤和可以改進的地方，兩個人進行頻繁的角色互換。

結對關系每天至少進行一次，且團隊中每個成員都應和其他成員一起工作參與。

這樣做的好處是：知識在團隊中的傳播、不同成員參與不同的工作、可替代性較低（研究表明這樣不但不會降低開發效率，切會大大減少缺陷率）。

PS：這樣的開發方式現在已經很少了，但個人覺得其演變至今，更像是由開發人員獨立完成單元測試代碼編寫和功能代碼編寫，這樣說有點拗口，換種方式：一個人身兼開發和測試開發2個崗位職責。

編碼標準：在XP中，團隊開發人員都遵循著相對比較統一的編碼標準（大家可以腦補一下最近阿里提出的java開發規約）。

共同所有權：在XP中，團隊中每個人都擁有check out任何模塊并對其進行修改的權力，每個人并不是獨立的，都不會被限制在自己的專業領域。

五、持續集成

關鍵詞：持續集成、可持續的開發速度

持續集成：開發人員每天都會進行多次的check in和check out并進行merge，使用非阻塞的源代碼控制工具。

每天進行多次系統構建（關于這點，可以參考《Google軟件測試之道》中第一章第四節的內容）。

可持續的開發速度：軟件開發不是百米短跑，而是一場馬拉松。為了完成快速開發，團隊成員必須以一種有節奏的可持續的速度前進。

六、TDD和UAT

關鍵詞：TDD（測試驅動開發）、UAT（驗收測試）

首先需要明白一點：編寫單元測試是一種驗證行為，更是一種設計行為。它的優點是：避免了相當數量的反饋循環，尤其是功能測試時候的反饋循環（即測試-提缺陷-修復-驗證）的行為。

TDD：即測試驅動開發方法。在XP中，采用這種方法，它有一下幾種特點：

　　 1、測試先行：在編寫功能代碼之前先設計測試方案和測試代碼；需要明白的一點是：程序中的每一項功能都有測試來驗證它的操作正確性。

　　 2、心中有數：首先編寫測試代碼的好處是：迫使我們從不同角度考慮代碼設計，而不是只關注功能實現（同時考慮接口正確性、異常、邊界等情況）。

　　 3、可測試的程序：先編寫測試代碼，迫使自己設計的程序是可測試、易于調用的，這樣做的優點是：迫使程序和周邊環境解耦。

　　 4、無價的文檔：編寫的測試代碼可以作為一種無價的文檔，范例，幫助其他開發成員了解如何設計、使用代碼。

　　 注：這里的文檔是可編譯可運行的，且保持最新的版本。

　　 總結：為了使功能代碼能夠通過測試，迫使開發人員去做有目的的編程；為了做到心中有數，開發人員必須使得程序模塊之間進行隔離，降低耦合；

　　　　 為了模塊隔離，降低耦合，迫使我們以對程序最有利的方式進行解耦合，即改善了設計。

UAT：即驗收測試。是用來驗證系統是否滿足它所聲稱的具有其功能的黑盒測試方法。

驗收測試是關于系統特性的最終文檔。單元測試作為可編譯可運行的系統內部結構的文檔，驗收測試是有關系統特性的可編譯執行的文檔。

七、重構

關鍵詞：實現功能、應對變化、易于閱讀和修改

在Martin Fowler大神的名著《重構》一書中，他把重構定義為：在不改變代碼外在行為的前提下對代碼進行修改，以改進代碼內部結構的過程。

每個軟件程序都應具有三項職責：

1、可運行且能夠完成所有的功能。

2、應對變化：軟件是由生命周期的，在它們的生命周期中都是在不斷變化的，開發者有責任保證這種變化應盡可能的簡單。

3、易于閱讀和修改：易于閱讀和修改的軟件才能更加靈活和具有適應性。

從以上三點來說，重構后的程序讀起來應比之前好很多，工作的也應該更好。程序應該變得更易理解和修改，且程序結構各部分之間互相隔離。

舉個例子：

重構好比用餐結束后對廚房和廚具的清理工作。第一次沒有清理，用餐可能更快點，但由于沒有對其進行清理，第二次做飯，你需要做的準備工作時間就更長一點，這樣會促使你放棄清理工作。

如果你總是跳過清理工作，確實可以使你很快用完餐，但臟亂在一天天積累。最終你需要話費大量的時間和精力，甚至代價去做清理，以使得它們適合與烹飪。

但是，飯每天都需要吃，忽略清潔工作并不能真正加快做飯用餐的速度。

PS：從這個例子可以明白，重構是必須且經常進行的！

八、隱喻

關鍵詞：務實主義、全局考慮

隱喻（metaphore），是XP中最難理解的一個特性，XP本質來說都是奉行務實主義。

簡單來說，所謂的隱喻，即從整個系統范疇來進行全局考慮，它是系統的未來景象，它使得所有單獨模塊的位置和特性變得更明顯、直觀。

如果某個模塊和整個系統對比顯得格格不入，那么你就應該明白，這個模塊存在問題。

隱喻也可以理解為一個總體的系統總稱，其特質應該是明顯的，直觀的（可參考《Google軟件測試之道》一書中第三章第3.2.1節的Google——ACC指導原則中的特質一詞）。

以上即關于敏捷方法中的XP（極限編程）的簡述，當然，具體的一些內容需要在實踐中不斷理解。

總結

以上是生活随笔為你收集整理的极限编程简述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。