極限編程簡述

在敏捷方法中,極限編程(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(極限編程)的簡述,固然,具體的一些內容須要在實踐中不斷理解。

相關文章
相關標籤/搜索