在敏捷方法中,極限編程(XP:eXtreme Programming)是其中最著名的一個,它由一系列簡單卻互相依賴的實踐組成。。。java
本篇博客,對極限編程作一個簡述,以及我的的一些理解,主要從如下幾點進行。。。數據庫
客戶做爲團隊成員編程
良性計劃框架
簡單設計函數
結對編程工具
持續集成單元測試
TDD和UAT測試
重構編碼
隱喻spa
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(極限編程)的簡述,固然,具體的一些內容須要在實踐中不斷理解。