極限編程XP（Extreme Programming）

極限編程簡介

      極限編程（Extreme Programming，簡稱XP）是敏捷軟件開發方法的表明。2000年，美國軟件工程專家Kent Beck對極限編程這一創新軟件過程方法論進行了解釋：「XP是一種輕量、高效、低風險、柔性、可預測、科學而充滿樂趣的軟件開發方法。」Kent Beck建議XP應用於規模小、進度緊、需求變化大、質量要求嚴格的項目。它是價值而非實踐驅動的高度迭代的開發過程，其價值體如今如下幾個方面：

       第一，溝通（Communication）：即追求有效的溝通。XP強調項目開發人員、設計人員、客戶之間等有效地、及時地溝通，確保各類信息的暢通。

       第二，簡單（Simplicity）：即實現最簡單的可行方案。XP認爲應該儘可能保持代碼的簡單，只要可以知足工做須要就行，這樣有利於代碼的重構和優化。

       第三，反饋（Feedback）：即快速有效的反饋。要求不斷對當前系統狀態進行反饋，經過反饋，達到迅速溝通、編碼、測試、發佈的目的。

       第四，勇氣（Courage）：即敢於放棄和重構。對於用戶的反饋，XP程序員要敢於對本身的代碼進行修改，即便有些修改可能會使得原來已經經過的測試又出現錯誤，可是通過團隊的共同攻關，最終必然會取得滿意的效果。

 

極限過程的開發過程

       與傳統的開發過程不一樣，極限編程的核心活動體如今需求→測試→編碼→設計過程當中，所以對工做環境、需求分析、設計、編程、測試、發佈等提出了新的思路和要求。

1.工做環境

   XP要求每一個參加項目開發的人都擔任一個角色（項目經理、項目監督人等），並履行相應的權利和義務。全部的人都在一個開放式的開發環境中工做，最好是在同一個大房間中工做，隨時討論問題，強調每週工做40小時工做制，不加班。

2.需求分析

   客戶被歸入開發隊伍。因爲客戶不具有計算機專業知識，沒法用專業語言明確描述需求，因此開發人員和客戶一塊兒，用講故事的方式把需求表達出來，這種故事被稱爲user story，即用user story表示需求。開發人員根據經驗講許多user story組合起來，或將其進行分解，最終記錄在story card的小卡片上，這些user story將陸續被程序員在各個小的週期內，按照商業價值、開發風險的優先順序逐個開發。

3.設計

   XP強調簡單設計（simple design），即用最簡單的辦法實現每一個小需求。在XP中，沒有那種傳統開發模式中一次性的、針對全部需求的整體設計，這些設計只要可以知足系統客戶在當前的需求就能夠了，不須要考慮未來可能的變化，整個設計過程包括在整個螺旋式的項目中。

4.編程

   成對編程（pair programming）是極限編程的一大特點，即兩我的一塊兒使用同一屏幕，同一個鍵盤，共同完成一段程序的編碼。成對編程的好處是，能夠提升紀律性，更容易寫出優質的代碼，同時保證編程的流暢進行，更重要的是，可以使得整個團隊更方便地分享編程經驗，有利於新手的快速成長。

5.測試

   在極限編程中，測試是很是重要的一個環節，它首先要求在開始寫程序以前先寫好測試，其目的是爲了提升軟件的可測試性。XP要求開發人員常常把開發好的模塊整合到一塊兒，每次整合後都要運行單元測試；作任何的代碼複覈和修改，都要運行單元測試；發現了漏洞，就要增長相應的測試。除了單元測試以外，還要進行整合測試、功能測試、負荷測試和系統測試等。全部這些測試是極限編程開發過程當中最重要的文檔之一，也是最終交付給用戶的內容之一。

6.發佈

   XP要求按照開發計劃，每通過一個開發週期，軟件就發佈一次，而不是像傳統的開發方法那樣，整個軟件開發完成後才發佈。在一個開發週期內，開發人員要求客戶選擇最有價值的user story做爲將來一兩個星期的開發內容，一個開發週期完成後，提交給客戶的系統雖然不是最終的產品，但它已經實現了幾個客戶認爲最重要的story，開發人員將逐步在其基礎上增長新的模塊，並且在發佈前軟件都通過單元測試和集成測試，所以，雖然軟件並不完備，可是發佈的軟件客戶仍是能夠真正使用的。

 

極限過程的價值標準

極限編程技術以溝通、簡單、回饋、勇氣和尊重爲價值標準。

1.溝通

   構建一個軟件系統的基本任務之一就是與系統的開發者交流以明確系統的具體需求。在一些正式的軟件開發方法中，這一任務是經過文檔來完成的。極限編程技術能夠被當作是開發小組的成員之間迅速構建與傳播制度上的認識的一種方法。它的目標是向全部開發人員提供一個對於系統的共享的視角，而這一視角又是與系統的最終用戶的視角相吻合的。爲了達到這一目標，極限編程支持設計、抽象、還有用戶-程序員間交流的簡單化，鼓勵常常性的口頭交流與回饋。

2.簡單

   極限編程鼓勵從最簡單的解決方式入手再經過不斷重構達到更好的結果。這種方法與傳統系統開發方式的不一樣之處在於，它只關注於對當前的需求來進行設計、編碼，而不去理會明天、下週或者下個月會出現的需求。極限編程的擁護者認可這樣的考慮是有缺陷的，即有時候在修改現有的系統以知足將來的需求時不得不付出更多的努力。然而他們主張「不對未來可能的需求上投入精力」所獲得的好處能夠彌補這一點，由於未來的需求在他們還沒提出以前是極可能發生變化的。爲了未來不肯定的需求進行設計以及編碼意味着在一些可能並不須要的方面浪費資源。而與以前提到的「交流」這一價值相關聯來看，設計與代碼上的簡化能夠提升交流的質量。一個由簡單的編碼實現的簡單的設計能夠更加容易得被小組中的每一個程序員所理解。

3.反饋

   在極限編程中，「反饋」是和系統開發的不少不一樣方面相關聯的：

  （1）來自系統的反饋：經過編寫單元測試，程序員可以很直觀的獲得通過修改後系統的狀態。

  （2）來自客戶的反饋：功能性測試是由客戶還有測試人員來編寫的。他們能由此得知當前系統的狀態。這樣的評審通常計劃二、3個禮拜進行一次，這樣客戶能夠很是容易的瞭解、掌控開發的進度。

  （3）來自小組的反饋：當客戶帶着新需求來參加項目計劃會議時，小組能夠直接對於實現新需求所須要的時間進行評估而後反饋給客戶。

   反饋是與「交流」、「簡單」這兩條價值緊密聯繫的。爲了溝通系統中的缺陷，能夠經過編寫單元測試，簡單的證實某一段代碼存在問題。來自系統的直接反饋信息將提醒程序員注意這一部分。用戶能夠以定義好的功能需求爲依據，對系統進行週期性的測試。

4.勇氣

   極限編程理論中的「系統開發中的勇氣」最好用一組實踐來詮釋。其中之一就是「只爲今天的需求設計以及編碼，不要考慮明天」這條戒律。這是努力避免陷入設計的泥潭、而在其餘問題上花費了太多沒必要要的精力。勇氣使得開發人員在須要重構他們的代碼時能感到溫馨。這意味着從新審查現有系統並完善它會使得之後出現的變化需求更容易被實現。另外一個勇氣的例子是瞭解何時應該徹底丟棄現有的代碼。每一個程序員都有這樣的經歷：他們花了一成天的時間糾纏於本身設計和代碼中的一個複雜的難題卻無所得，而次日回來以一個全新而清醒的角度來考慮，在半小時內就輕鬆解決了問題。

5.尊重

   尊重的價值體如今不少方面。在極限編程中，團隊成員間的互相尊重體如今每一個人保證提交的任何改變不會致使編譯沒法經過、或者致使現有的測試案例失敗、或者以其餘方式致使工做延期。團隊成員對於他們工做的尊重體如今他們老是堅持追求高質量，堅持經過重構的手段來爲手頭的工做找到最好的解決設計方案。