極限編程簡述

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

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

客戶做爲團隊成員

良性計劃

簡單設計

結對編程

持續集成

TDD和UAT

重構

隱喻

 

1、客戶做爲團隊成員

關鍵詞：面對面溝通

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

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

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

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

 

2、良性計劃

一、初始計劃

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

項目開始時，開發人員和「客戶」應儘可能肯定出真正重要的需求，而不是全部的需求。由於隨着項目進展，需求也處在隨時或大或小的變動中。

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

在「客戶」不斷編寫變動需求的時候，開發人員也應該對需求進行預估。工時預估是相對的，而不是絕對的，應流出必定的緩衝時間。

若是需求太大，那麼就須要對其進行拆分，直至能夠相對準確的進行工時預估和詳細的開發設計爲止。

二、發佈計劃

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

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

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

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

三、迭代計劃

關鍵詞：每次迭代作什麼？

在XP中，通常的迭代週期爲1-2周，迭代週期內需求的實現順序取決於技術決策範疇，應採用最具技術意義的順序來實現這些需求，能夠串行也能夠並行開發。

肯定迭代後，正在開發的需求則不該被更改，還未開發的需求能夠根據具體狀況進行調整。

四、任務計劃

關鍵詞：開發和「客戶」達成一致約定

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

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

 

3、簡單設計

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

一、考慮可以工做的最簡單的事情

儘量尋找能實現當前需求的最簡單的設計，多考慮不一樣的方案，而後選擇一種咱們能夠實際獲得和最簡單的解決方案。

二、你將不須要它

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

三、有且只有一次

在面向對象編程原則中，有一個叫作「共同重用原則」，即消除重複的代碼。

簡單來講就是將重複或類似度較高的代碼變成函數，封裝成一個統一的抽象集合，而後在使用時調用便可（這也將進一步減小代碼間的耦合）。

 

4、結對編程

關鍵詞：編碼標準、共同全部權

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

結對關係天天至少進行一次，且團隊中每一個成員都應和其餘成員一塊兒工做參與。

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

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

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

共同全部權：在XP中，團隊中每一個人都擁有check out任何模塊並對其進行修改的權力，每一個人並非獨立的，都不會被限制在本身的專業領域。

 

5、持續集成

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

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

        天天進行屢次系統構建（關於這點，能夠參考《Google軟件測試之道》中第一章第四節的內容）。

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

 

6、TDD和UAT

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

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

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

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

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

　　 三、可測試的程序：先編寫測試代碼，迫使本身設計的程序是可測試、易於調用的，這樣作的優勢是：迫使程序和周邊環境解耦。

　　 四、無價的文檔：編寫的測試代碼能夠做爲一種無價的文檔，範例，幫助其餘開發成員瞭解如何設計、使用代碼。

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

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

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

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

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

 

7、重構

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

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

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

一、可運行且可以完成全部的功能。

二、應對變化：軟件是由生命週期的，在它們的生命週期中都是在不斷變化的，開發者有責任保證這種變化應儘量的簡單。

三、易於閱讀和修改：易於閱讀和修改的軟件才能更加靈活和具備適應性。

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

舉個例子：

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

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

可是，飯天天都須要吃，忽略清潔工做並不能真正加快作飯用餐的速度。

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

 

8、隱喻

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

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

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

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

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

 

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