極限編程(eXtreme Programming)簡介

極限編程(eXtreme Programming)是近幾年才時興起來的開發模型,極限編程(eXtreme Programming)主要是針對中小型開發團隊在開發時間要求緊、需求不穩定的中小項目（大多數軟件項目都是這個情況）時使用。極限編程(eXtreme Programming)打破了傳統軟件工程的框架，非常新巧。譬如整個開發過程中文檔很少，大量使用“卡片 （如CRC卡片）”來描述開發計劃和內容；沒有真正意義上的軟件功能規格說明書，取而代之的是一系列可測試的用例；沒有獨立的設計和測試階段，它們總是在迭代中增量反覆進行；設計：儘可能小和簡單；一般沒有代碼複審（code review),大家共同擁有代碼。而它的最顯著的一個外在特徵是它常使用“成對開發”，即一臺機器前坐兩個開發人員，共同開發（一個看，一個寫），這乍聽起來真是蠻有趣的：）,極限編程(eXtreme Programming)的基本出發是認爲成對開發的效率在一定條件下要高於兩個人獨立開發的和。  不要覺得天方夜譚，在很多項目中，這種做法的有效性已經被證實。

極限編程(eXtreme Programming)XP的特點可以用“快、小、靈”來概括，極限編程(eXtreme Programming)和傳統瀑布模型（自頂向下）的區別在於它使用迭代增量（設計->代碼->測試->設計->代碼…)的方式。想法很簡單：沒有什麼目標是可以一開始就容易確定的。用爬山來做一下比喻的話，傳統的是在山下研究地圖，選好一條路線，然後沿着此路前進，XP則是走一走，停一停，看一看，對下一步的方向作出新的選擇，在很多時候，這樣做會讓你選擇到更好的捷徑。

極端編程(eXtreme Programming)是一種開發紀律，以簡單性、交流、反饋和勇氣爲基本宗旨。它的做法是以有效的實踐規則將整個團隊緊密聯繫起來，通過充分的反饋使團隊能隨時知道自己目前的狀況和恰當的調節規則以適應自己的特殊情況。

在極限編程(eXtreme Programming)中，每一個項目貢獻者都是“團隊”完整的一部分。這個隊伍是圍繞着一個每天和隊伍坐在一起共同工作的商業代表——“客戶”建立起來的。
核心實踐：整體團隊
極端編程的隊伍採用一種簡單的方式來進行規劃和跟蹤，以決定下一步要做什麼和預知項目什麼時候會完成。聚焦於商業價值，團隊通過一系列的通過了客戶定義的測試和完全集成的小的發佈來創作軟件系統。
核心實踐：規劃策略，小發行版，客戶測試
極端編程者通過成對和小組的方式共同工作，通過簡單設計和強制測試的代碼，不斷的提升設計以保證設計總是適合當前的需求。
核心實踐：簡單設計，成對編程，測試優先開發，設計改進
極端編程隊伍會總是保持系統能夠集成並且在所有的時間運行。程序員以成對的方式編寫所有的產品代碼，並且在所有時間內都共同工作。他們以相似的形式編碼以保證所有成員都可以按需要理解和改進所有的代碼。
核心實踐：持續集成，集體代碼所有權，編碼標準
極端編程隊伍分享一個公共並且簡單的系統藍圖。所有成員可以按照一種不時保持同步的節奏進行工作。
核心實踐：系統比喻，可接受的步伐
團隊整體
一個XP項目的所有參與者都作爲一個團隊的成員坐在一起。這個團隊必須包括一個業務的代表——“客戶”，他提供需求，設置優先度，並掌管整個項目的方向。最好這個客戶或者他的助手是一個最終用戶，瞭解該領域，知道什麼是所需要的。團隊當然還要有程序員。團隊可能會包含測試員，他幫助客戶定義客戶驗收測試。分析員可以作爲客戶的助手，幫助客戶定義需求。通常還會有一個指導,他幫助整個團隊跟蹤、推動開發進程。也可能會有一個管理者，他提供資源、處理對外交流和分工協作。這些職責中沒有任何一個是必須某個個人獨有的：每一個XP團隊的成員都以任何他們所能做到的方式參與，最好的團隊沒有專家，只有一些有着特殊的技能的一般的參與者。
規劃策略
XP的計劃解決軟件開發中的兩個關鍵問題：預知在責任期內哪些東西將被完成，並且確定下一步需要做什麼。重點是把握項目的正確軌道——這是相當簡單明瞭的——更勝於希望精確預知哪些東西將會需要以及可能花費多少時間——這是相當困難的。在XP這裏有兩個關鍵的規劃步驟，用來解決這兩個問題：
發佈計劃是一個實踐讓客戶向程序員們演示所希望獲得的特性，然後程序員們評估它們的難度。當手中有了代價的評估和這些特性的重要程序的認知之後，客戶安排一個項目計劃。最初的發佈計劃需要留有足夠的餘地：優先級以及評估都不是真實可靠的，並且知道團隊開始工作以前，我們都無法確切地瞭解隊伍的開發進度。甚至最初的發佈計劃也不是足夠精確能進行決斷，所以XP隊伍通常會不時地校正發佈計劃。
迭代計劃是一個實踐籍此可以爲團隊提供每幾個開發周的導向。XP隊伍通過兩週的“迭代”來建立軟件系統，在每一個迭代結束時提供可以運行的有實際用途的軟件系統。在進行迭代計劃時，客戶演示下兩週內希望完成的特性。程序員們將它們分割成若干個任務，並且評估它們的成本（比發佈計劃要細緻一些）。基於在之前的迭代中完成的工作，團隊簽定當前迭代中將要承擔的工作。
這些計劃十分的簡單，然而他們爲客戶提供了非常好的信息和極好的操縱控制。每隔幾周，多少進展都可以一目瞭然。在XP中沒有“百分之九十完成”：一個特性故事要麼完成了，要麼沒有完成。關注可視結果方法在於一個很好的小的對立論點：一方面來說，非常直觀地，如果進度不能令人滿意，客戶可以在某一個位置取消項目。從另一方面說，進度是顯而易見地，並且判斷哪些東西將會完成的能力是很完善的，因此XP項目往往可以在較少的壓力下完成更多的需要的東西。
客戶測試
作爲每一個所要求特性的演示的一部分，XP客戶定義一個或者多個自動進行的接受測試來表明特性已經能夠實現。團隊實現這些測試並且用它們來向自己和客戶證明特性已經被正確的實現了。由於時間的壓力，自動化是很重要的，手工測試將被跳過。這就像當黑夜來臨的時候，就可以關掉你的燈一樣。
最好的XP團隊會將他們的客戶測試當作程序員的測試一樣對待：一旦測試運行了，從此之後團隊會保持它能夠一直正確運行。這意味着系統只能夠被改進，總是向前的，從不會倒退。
小發行版本
XP團隊通過兩個重要的方式實踐小發行版本：
第一，團隊在每一個迭代發佈可以運行的，測試過的軟件系統，提供客戶選擇的商業價值。客戶可以爲任何目的使用這個軟件系統，無論是評估還是發佈給最終用戶（強烈推薦）。最重要的方式是在每一個迭代結束的時候軟件系統是可見的，並且提交給了客戶。這保證了任何事情都是公開和真實的。
第二，XP團隊儘可能頻繁地發佈給他們的最終用戶。XP網站項目每天都進行發佈，居家項目則每月或者更頻繁地發佈。甚至可以簡包裝的產品可以每季度地發運。
這麼頻繁地創建好的版本也許顯得不太可能，但是XP團隊每時每刻都在進行着發佈。更多信息可以參看持續集成，並請注意這些頻繁的發佈通過XP中隨處可見的測試（如同客戶測試和測試優先開發中所描述的）變得現實了。
簡單設計
XP團隊建構軟件系統爲一個簡單的設計。他們從簡單開始，並且在整個程序員測試和設計改進過程中，他們保持着簡單的設計。一個XP團隊保持着設計總是剛好適合系統當前的功能要求。這裏沒有多餘的投入，並且軟件系統總是爲將來做好了準備。
在XP中設計並不是一次性完成的事情，也不是一件從上到下的事情，它是自始至終的事情。在發佈計劃和迭代計劃中都有設計的步驟，在快速設計過程中集合了團隊的能力並且在整個項目過程地構中改進設計。在類似於極端編程這樣的遞增和迭代過程中，良好的設計是本質。這是在整個開發過程中必須更多的關注設計的原因。
成對編程
在XP所有的產品軟件都是由兩個程序員並排坐在一起，在同一臺機器上共同完成的。這個實踐保證了所有的產品代碼都至少有一個其它的程序員進行了審視，而結果是更好的設計，更好的測試和更好的代碼。
讓兩個程序員去做“一個程序員的工作”看起來有些效率低下，但是實際上剛好相反。研究表明成對編程在讓程序員們單獨工作相同的時間內會得到更好的代碼。這證明了：兩個頭腦加在一起比一個好得多！
很多程序員在還沒有嘗試過的情況下就反對成對編程。這確實需要一些實踐來做好它，而且你需要認真地實踐數週以上的時間來看到結果。百分之九十的學習過成對編程的程序員都會喜歡這樣，因此我們向所有的團隊強烈推薦它。
除開提供更好的代碼和測試之外，成隊也提供了知識在團隊中間傳遞。當成對地程序員交換夥伴時，每個人都會從其它的某個人那裏學到新的知識。程序員們在學習，他們的技術在提高，他們對團隊和公司來講變得更有價值。成對，即使它本身在XP過程之外實施，也是每個人的巨大成功。
測試優先開發
極限編程(eXtreme Programming)圍繞着反饋，而在軟件開發中，好的反饋需要好的測試。最優秀的XP團隊實踐“測試優先開發”，在一個很小的循環中增加一個測試，然後讓它能夠工作。幾乎是輕而易舉的，團隊提供的代碼接近100%都有測試程序覆蓋着，在絕大多數情況下這是很重要的進步。（如果你的程序員已經提供了更多的現有測試程序，你會擁有更多的力量。將它們保存下來，他們只會提供幫助的！）
僅僅寫了測試程序還是不夠的：你必須要運行它們。這裏，極端編程也是極端的。這些“程序員測試”，或者說“單元測試”是一個完整的集合，每當程序員們發佈任何代碼到代碼庫的時候（成對的程序員通常每天發佈兩次或者更多次），每一個程序員測試必須能夠正確的運行。每時每刻都是百分之百運行！這意味着程序員們可以立刻得到有關他們做得究竟如何的反饋。進一步說，這些測試提供了軟件設計改進時無價的支持。
設計改進
極限編程(eXtreme Programming)在每一個迭代都關注於提供商業價值。爲了在整個項目過程中完成這個目標，軟件系統必須有良好的設計。可選擇性可能會降低並且最終停滯。因此XP採用一種持續改進設計的過程，稱爲“重構”，來自於Martin Fowler 的書名，“重構：改進現有代碼的設計”。
重構的過程關注在去掉重複（一個低劣設計的明確標誌），以及提高代碼的“內聚”，還有減少“耦合”。高內聚和低耦合在最近三十年以來被公認爲是良好設計的特點。結果就是XP團隊從一個好的簡單的設計出發，並且總是讓軟件系統有一個好的簡單的設計。這讓他們能保持他們的開發速度，並且通常在實際上提高了項目開發速度。
重構自然是通過全面的測試來提供有力的支持的，這些測試用來確認當設計改變的時候不會破壞系統中的任何東西。因此客戶測試和程序員測試都是有效的評價因素。XP的實踐是相互支持的：他們會比各自獨立時更爲強壯。

持續集成
極端編程隊伍總是保持的系統完全地集成在一起。我們說每日建構版本是爲弱者提供的：XP團隊每天都要構建系統很多次。（一個40人的XP團隊每天至少集成八到十次！）
這個實踐的好處可以通過回想你可能聽說過的（或者是親身參與過的）項目來了解：當系統構建是每週或以更低的頻率進行時，通常會陷入“集成的地獄”，在那裏所有東西都不能運行而且沒有人知道爲什麼。
極少進行集成會給軟件項目帶來一系列的問題。第一個，儘管集成是發行好的工作代碼的條件， 但是團隊並不去實踐它，而且通常它被委派給那些對整個系統並不十分了解的人。第二，極少集成的代碼通常是——我寧願說總是——錯漏百出。
集體代碼所有權
在一個極限編程(eXtreme Programming)項目中，每一對程序員都可以在任何時候改進任何一處的代碼。這意味着所有的代碼在很多人的關注下獲得更多的收益，這樣就提升了代碼質量並且減少了缺陷。這裏還有另外一個重要的好處：當代碼僅由單個人負責的時候，要求的特性往往會放到了錯誤的位置，因爲一個程序員發現他需要一個特性但是那段代碼卻不歸他管理。代碼的所有者太忙樂而不能去增加這個特性，所以這個程序員只好把這個特性加進了這個特性本不應該存在的他自己的代碼中。這導致了難看的，難於維護到代碼，充斥着重複和低（差）的內聚。
如果有人在他們所不理解的代碼上進行盲目的修改時，集體代碼所有權可能帶來問題。XP通過兩種關鍵技術來避免這類的問題：通過程序員測試來捕獲錯誤，成對編程則表明在不熟悉的代碼上工作的時候最佳途徑是找一個這方面的專家作爲夥伴。爲了確保在需要是進行好的修改，這種實踐將知識延伸到了整個團隊。
編碼標準
XP團隊遵循一個公共的編碼標準，因此係統中所有的代碼看上去都像出自單獨一個——非常有能力的——人之手。這個標準的規定並不重要：重要的是要讓所有的代碼看上去很相似，用來支持集體代碼所有權。
系統比喻
極限編程(eXtreme Programming)團隊對於程序如何運作形成一個共識，我們稱之爲“系統比喻”。在最佳狀態時，系統比喻是關於程序如何運作的一個簡單的靈魂描述，例如用“這個程序工作時就像一箱子蜜蜂，外出尋找花粉並帶回蜂箱”作爲一個基於代理的信息查詢系統的描述。
有些時候一個十分詩意的想象可能不會出現。在任何情況下，無論有沒有生動的比喻，XP團隊都會選用一個公共的命名系統來確保每個人都能理解系統是如何工作的，以及到哪裏去找到你所需要的功能，或者找到你要增加功能的正確位置。
可接受的步伐
極端編程團隊都會在這裏很長的一段時間。他們努力的工作，並且在一個能夠不斷維持的步伐下。這意味着在有效的時候他們會加班工作，而且他們經常這樣工作來保證每週都有最大的生產力。這恰當的解釋了死亡競賽式的項目既不會有生產力也不會創造有質量的軟件系統。XP團隊在這裏是要勝利而不是要死亡。
小結
極端編程 (極限編程(eXtreme Programming))是一種以簡單性、交流、反饋和勇氣爲基本宗旨的開發紀律。它的做法是以有效的實踐規則將整個團隊緊密聯繫起來，通過充分的反饋使團隊能隨時知道自己目前的狀況和恰當地調節實踐規則以適應自己的特殊情況。