極限程式設計(Extreme Programming)

Extreme Programming（極限程式設計，簡稱XP）是由Kent Beck在1996年提出的。Kent Beck在九十年代初期與Ward Cunningham共事時，就一直共同探索着新的軟體開發方法，希望能使軟體開發更加簡單而有效。Kent仔細地觀察和分析了各種簡化軟體開發的前提條件、可能行以及面臨的困難。1996年三月，Kent終于在為DaimlerChrysler所做的一個項目中引入了新的軟體開發觀念——XP。

　　XP是一個輕量級的、靈巧的軟體開發方法；同時它也是一個非常嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、回報和勇氣；即，任何一個軟體項目都可以從四個方面入手進行改善：加強交流；從簡單做起；尋求回報；勇于實事求是。XP是一種近螺旋式的開發方法，它将複雜的開發過程分解為一個個相對比較簡單的小周期；通過積極的交流、回報以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，并根據實際情況及時地調整開發過程。

什麼是軟體開發

軟體開發的内容是：需求、設計、程式設計和測試！

需求：不僅僅是使用者需求，應該是開發中遇到的所有的需求。比如，你首先要知道做這個項目是為了解決什麼問題；測試案例中應該輸入什麼資料……為了清楚地知道這些需求，你經常要和客戶、項目經理等交流。

設計：編碼前，肯定有個計劃告訴你要做什麼，結構是怎樣等等。你一定要按照這個來做，否則可能會一團糟。

程式設計：如果在項目截止日，你的程式不能跑起來或達不到客戶的要求，你就拿不到錢。

測試：目的是讓你知道，什麼時候算是完成了。如果你聰明，你就應該先寫測試，這樣可以及時知道你是否真地完成了。否則，你經常會不知道，到底有哪些功能是真正完成了，離預期目标還差多遠。

軟體開發中，客戶和開發人員都有自己的基本權利和義務。

客戶：

　　定義每個使用者需求的商業優先級；

　　制訂總體計劃，包括用多少投資、經過多長時間、達到什麼目的；

　　在項目開發過程中的每個工作周，都能讓投資獲得最大的收益；

　　通過重複運作你所指定的功能測試，準确地掌握項目進展情況；

　　能随時改變需求、功能或優先級，同時避免昂貴的再投資；能夠根據各種變化及時調整項目計劃；

　　能夠随時取消項目；項目取消時，以前的開發工作不是一堆垃圾，已開發完的功能是合乎要求的，正在進行或未完成的的工作則應該是不難接手的。

開發人員：

　　知道要做什麼，以及要優先做什麼；

　　工作有效率；

　　有問題或困難時，能得到客戶、同僚、上級的回答或幫助；

　　對工作做評估，并根據周圍情況的變化及時重新評估；

　　積極承擔工作，而不是消極接受配置設定；

　　一周40小時工作制，不加班。

這就是軟體開發，除此之外再還有其它要關心的問題！

靈巧的輕量級軟體開發方法

　　一套軟體開發方法是由一系列與開發相關的規則、規範和慣例。重量級的開發方法嚴格定義了許多的規則、流程和相關的文檔工作。靈巧的輕量級開發方法，其規則和文檔相對較少，流程更加靈活，實施起來相對較容易。

　　在軟體工程概念出現以前，程式員們按照自己喜歡的方式開發軟體。程式的品質很難控制，調試程式很繁瑣，程式員之間也很難讀懂對方寫的代碼。1968年，Edsger Dijkstra給CACM寫了一封題為GOTO Statement Considered Harmful 的信，軟體工程的概念由此誕生。程式員們開始摒棄以前的做法，轉而使用更系統、更嚴格的開發方法。為了使控制軟體開發和控制其它産品生産一樣嚴格，人們陸續制定了很多規則和做法，發明了很多軟體工程方法，軟體品質開始得到大幅度提高。随着遇到的問題更多，規則和流程也越來越精細和複雜。

　　到了今天，在實際開發過程中，很多規則已經難于遵循，很多流程複雜而難于了解，很多項目中文檔的制作過程正在失去控制。人們試圖提出更全面更好的一攬子方案，或者寄希望于更複雜的、功能更強大的輔助開發工具（Case Tools），但總是不能成功，而且開發規範和流程變得越來越複雜和難以實施。

　　為了趕進度，程式員們經常跳過一些指定的流程，很少人能全面遵循那些重量級開發方法。

　　失敗的原因很簡單，這個世界沒有萬能藥。是以，一些人提出，将重量級開發方法中的規則和流程進行删減、重整和優化，這樣就産生了很多适應不同需要的輕量級流程。在這些流程中，合乎實際需要的規則被保留下來，不必要的複雜化開發的規被抛棄。而且，和傳統的開發方法相比，輕量級流程不再象流水生産線，而是更加靈活。

　　Extreme Programming（XP）就是這樣一種靈巧的輕量級軟體開發方法。

為什麼稱為“Extreme”（極限）

　　“Extreme”（極限） 是指，對比傳統的項目開發方式，XP強調把它列出的每個方法和思想做到極限、做到最好；其它XP所不提倡的，則一概忽略（如開發前期的整體設計等）。一個嚴格實施XP的項目，其開發過程應該是平穩的、高效的和快速的，能夠做到一周40小時工作制而不拖延項目進度。

XP的軟體開發是什麼樣

1 極限的工作環境

　　為了在軟體開發過程中最大程度地實作和滿足客戶和開發人員的基本權利和義務，XP要求把工作環境也做得最好。每個參加項目開發的人都将擔任一個角色（項目經理、項目監督人等等）并履行相應的權利和義務。所有的人都在同一個開放的開發環境中工作，最好是所有人在同一個大房子中工作，還有茶點供應；每周40小時，不提倡加班；每天早晨，所有人一起站着開個短會；牆上有一些大白闆，所有的Story卡、CRC卡等都貼在上面，讨論問題的時候可以在上面寫寫畫畫；下班後大家可以一起玩電腦遊戲……。

2 極限的需求

　　客戶應該是項目開發隊伍中的一員，而不是和開發人員分開的；因為從項目的計劃到最後驗收，客戶一直起着很重要的作用。開發人員和客戶一起，把各種需求變成一個個小的需求子產品（User Story），例如“計算年級的總人數，就是把該年級所有班的人數累加。”；這些子產品又會根據實際情況被組合在一起或者被分解成更小的子產品；它們都被記錄在一些小卡片（Story Card）上，之後分别被程式員們在各個小的周期開發中（Iteration，通常不超過3個星期）實作；客戶根據每個子產品的商業價值來指定它們的優先級；開發人員要做的是确定每個需求子產品的開發風險，風險高的（通常是因為缺乏類似的經驗）需求子產品将被優先研究、探索和開發；經過開發人員和客戶分别從不同的角度評估每個子產品後，它們被安排在不同的開發周期裡，客戶将得到一個盡可能準确的開發計劃；客戶為每個需求子產品指定驗收測試（功能測試）。

　　每釋出一次開發的軟體（經過一個開發周期），使用者都能得到一個可以開始使用的系統，這個系統全面實作了相應的計劃中的所有需求。而在一些傳統的開發模式中，無論什麼功能，使用者都要等到所有開發完成後才能開始使用。

3 極限的設計

　　從具體開發的角度來看，XP内層的過程是一個個基于測試驅動的開發（Test Driven Development）周期，諸如計劃和設計等外層的過程都是圍繞這些展開的。每個開發周期都有很多相應的單元測試（Unit Test）。剛開始，因為什麼都沒有實作，是以所有的單元測試都是失敗的；随着一個個小的需求子產品的完成，通過的單元測試也越來越多。通過這種方式，客戶和開發人員都很容易檢驗，是否履行了對客戶的承諾。XP提倡對于簡單的設計（Simple Design），就是用最簡單的方式，使得為每個簡單的需求寫出來的程式可以通過所有相關的單元測試。XP強調抛棄那種一攬子詳細設計方式（Big Design Up Front），因為這種設計中有很多内容是你現在或最近都根本不需要的。XP還大力提倡設計複核（Review）、代碼複核以及重整和優化（Refectory），所有的這些過程其實也是優化設計的過程；在這些過程中不斷運作單元測試和功能測試，可以保證經過重整和優化後的系統仍然符合所有需求。

4 極限的程式設計

　　既然程式設計很重要，XP就提倡兩個人一起寫同一段程式（Pair Programming），而且代碼所有權是歸于整個開發隊伍（Collective Code Ownership）。程式員在寫程式和重整優化程式的時候，都要嚴格遵守程式設計規範。任何人都可以修改其他人寫的程式，修改後要确定新程式能通過單元測試。

5 極限的測試

　　既然測試很重要，XP就提倡在開始寫程式之前先寫單元測試。開發人員應該經常把開發好的子產品整合到一起（Continuous Integration），每次整合後都要運作單元測試；做任何的代碼複核和修改，都要運作單元測試；發現了BUG，就要增加相應的測試（是以XP方法不需要BUG資料庫）。除了單元測試之外，還有整合測試，功能測試、負荷測試和系統測試等。所有這些測試，是XP開發過程中最重要的文檔之一，也是最終傳遞給使用者的内容之一。

XP中的重要慣例和規則

1 項目開發小組（Team）

　　在XP中，每個對項目做貢獻的人都應該是項目開發小組中的一員。而且，這個小組中必須至少有一個人對使用者需求非常清晰，能夠提出需求、決定各個需求的商業價值（優先級）、根據需求等的變化調整項目計劃等。這個人扮演的是“客戶”這個角色，當然最好就是實際的最終使用者，因為整個項目就是圍繞最終使用者的需求而展開的。程式員是項目開發小組中必不可少的成員。小組中可以有測試員，他們幫助客戶制訂驗收測試；有分析員，幫助客戶确定需求；通常還有個Coach（教練），負責跟蹤開發進度、解決開發中遇到的一些問題、推動項目進行；還可以又一個項目經理，負責調配資源、協助項目内外的交流溝通等等。項目小組中有這麼多角色，但并不是說，每個人做的工作是别人不能插手或幹預的，XP鼓勵每個人盡可能地為項目多做貢獻。平等相處，取長補短；這就是最好的XP開發小組。

2 計劃項目（Planning Game）、驗收測試、小規模釋出（Small Releases）

　　XP開發小組使用簡單的方式進行項目計劃和開發跟蹤，并以次預測項目進展情況和決定未來的步驟。根據需求的商業價值，開發小組針對一組組的需求進行一系列的開發和整合，每次開發都會産生一個通過測試的、可以使用的系統。

　　計劃項目

　　XP的計劃過程主要針對軟體開發中的兩個問題：預測在傳遞日期前可以完成多少工作；現在和下一步該做些什麼。不斷的回答這兩個問題，就是直接服務于如何實施及調整開發過程；與此相比，希望一開始就精确定義整個開發過程要做什麼事情以及每件事情要花多少時間，則事倍功半。針對這兩個問題，XP中又兩個主要的相應過程：

　　軟體釋出計劃（Release Planning）。客戶闡述需求，開發人員估算開發成本和風險。客戶根據開發成本、風險和每個需求的重要性，制訂一個大緻的項目計劃。最初的項目計劃沒有必要（也沒有可能）非常準确，因為每個需求的開發成本、風險及其重要性都不是一成不變的。而且，這個計劃會在實施過程中被不斷地調整以趨精确。

　　周期開發計劃（Iteration Planning）。開發過程中，應該有很多階段計劃（比如每三個星期一個計劃）。開發人員可能在某個周期對系統進行内部的重整和優化（代碼和設計），而在某個周期增加了新功能，或者會在一個周期内同時做兩方面的工作。但是，經過每個開發周期，使用者都應該能得到一個已經實作了一些功能的系統。而且，每經過一個周期，客戶就會再提出确定下一個周期要完成的需求。在每個開發周期中，開發人員會把需求分解成一個個很小的任務，然後估計每個任務的開發成本和風險。這些估算是基于實際開發經驗的，項目做得多了，估算自然更加準确和精确；在同一個項目中，每經過一個開發周期，下一次的估算都會有更過的經驗、參照和依據，進而更加準确。這些簡單的步驟對客戶提供了豐富的、足夠的資訊，使之能靈活有效地調控開發程序。每過兩三個星期，客戶總能夠實實在在地看到開發人員已經完成的需求。在XP裡，沒有什麼“快要完成了”、“完成了90%”的模糊說法，要不是完成了，要不就是沒完成。這種做法看起來好象有利有弊：好處是客戶可以馬上知道完成了哪些、做出來的東西是否合用、下面還要做些什麼或改進什麼等等；壞處是客戶看到做出來的東西，可能會很不滿意甚至中止合同。實際上，XP的這種做法是為了及早發現問題、解決問題，而不是等到過了幾個月，使用者終于看到開發完的系統了，然後才告訴你這個不行、那個變了、還要增加

哪個内容等等。

　　驗收測試

　　客戶對每個需求都定義了一些驗收測試。通過運作驗收測試，開發人員和客戶可以知道開發出來的軟體是否符合要求。XP開發人員把這些驗收測試看得和單元測試一樣重要。為了不浪費寶貴的時間，最好能将這些測試過程自動化。

　　頻繁地小規模釋出軟體（Small Releases）

　　每個周期（Iteration）開發的需求都是使用者最需要的東西。在XP中，對于每個周期完成時釋出的系統，使用者都應該可以很容易地進行評估，或者已經能夠投入實際使用。這樣，軟體開發對于客戶來說，不再是看不見摸不着的東西，而是實實在在的。XP要求頻繁地釋出軟體，如果有可能，應該每天都釋出一個新版本；而且在完成任何一個改動、整合或者新需求後，就應該立即釋出一個新版本。這些版本的一緻性和可靠性，是靠驗收測試和測試驅動的開發來保證的。

3 簡單設計，Pair Programming，測試驅動開發，重整和優化

　　XP程式員不但做為一個開發小組共同工作，還以兩個人為一個小開發單元編寫同一個程式。開發人員們進行簡單的設計，編寫單元測試後再編寫符合測試要求的代碼，并在滿足需求的前提下不斷地優化設計。

　　簡單設計

　　XP中讓初學者感到最困惑的就是這點。XP要求用最簡單的辦法實作每個小需求，前提是按照這些簡單設計開發出來的軟體必須通過測試。這些設計隻要能滿足系統和客戶在當下的需求就可以了，不需要任何畫蛇添足的設計，而且所有這些設計都将在後續的開發過程中就被不斷地重整和優化。

　　在XP中，沒有那種傳統開發模式中一次性的、針對所有需求的總體設計。在XP中，設計過程幾乎一直貫穿着整個項目開發：從制訂項目的計劃，到制訂每個開發周期（Iteration）的計劃，到針對每個需求子產品的簡捷設計，到設計的複核，以及一直不間斷的設計重整和優化。整個設計過程是個螺旋式的、不斷前進和發展的過程。從這個角度看，XP是把設計做到了極緻。

　　Pair Programming

　　XP中，所有的代碼都是由兩個程式員在同一台機器上一起寫的——這是XP中讓人争議最多、也是最難實施的一點。這保證了所有的代碼、設計和單元測試至少被另一個人複核過，代碼、設計和測試的品質是以得到提高。看起來這樣象是在浪費人力資源，但是各種研究表明事實恰恰相反。—— 這種工作方式極大地提高了工作強度和工作效率。

　　很多程式員一開始是被迫嘗試這點的（XP也需要行政指令的支援）。開始時總是不習慣的，而且兩個人的效率不會比一個人的效率高。這種做法的效果往往要堅持幾個星期或一兩個月後才能很顯著。據統計，在所有剛開始Pair Programming的程式員中，90%的人在兩個月以後都很認為這種工作方式更加高效。

　　項目開發中，每個人會不斷地更換合作程式設計的夥伴。是以，Pair Programming不但提高了軟體品質，還增強了互相之間的知識交流和更新，增強了互相之間的溝通和了解。這不但有利于個人，也有利于整個項目、開發隊伍和公司。從這點看，Pair Programming不僅僅适用于XP，也适用于所有其它的軟體開發方法。

測試驅動開發

　　回報是XP的四個基本的價值觀之一——在軟體開發中，隻有通過充分的測試才能獲得充分的回報。XP中提出的測試，在其它軟體開發方法中都可以見到，比如功能測試、單元測試、系統測試和負荷測試等；與衆不同的是，XP将測試結合到它獨特的螺旋式增量型開發過程中，測試随着項目的進展而不斷積累。另外，由于強調整個開發小組擁有代碼，測試也是由大家共同維護的。即，任何人在往代碼庫中放程式（Check In）前，都應該運作一遍所有的測試；任何人如果發現了一個BUG，都應該立即為這個BUG增加一個測試，而不是等待寫那個程式的人來完成；任何人接手其他人的任務，或者修改其他人的代碼和設計，改動完以後如果能通過所有測試，就證明他的工作沒有破壞願系統。這樣，測試才能真正起到幫助獲得回報的作用；而且，通過不斷地優先編寫和累積，測試應該可以基本覆寫全部的客戶和開發需求，是以開發人員和客戶可以得到盡可能充足的回報。

　　重整和優化 (Refactoring)

　　XP強調簡單的設計，但簡單的設計并不是沒有設計的流水帳式的程式，也不是沒有結構、缺乏重用性的程式設計。開發人員雖然對每個USER STORY都進行簡單設計，但同時也在不斷地對設計進行改進，這個過程叫設計的重整和優化（Refactoring）。這個名字最早出現在Martin Fowler寫的《Refactoring: Improving the Design of Existing Code》這本書中。

　　Refactoring主要是努力減少程式和設計中重複出現的部分，增強程式和設計的可重用性。Refactoring的概念并不是XP首創的，它已經被提出了近30年了，而且一直被認為是高品質的代碼的特點之一。但XP強調，把Refactoring做到極緻，應該随時随地、盡可能地進行Refactoring，隻要有可能，程式員都不應該心疼以前寫的程式，而要毫不留情地改程序式。當然，每次改動後，程式員都應該運作測試程式，保證新系統仍然符合預定的要求。

4 頻繁地整合，集體擁有代碼（Collective Code Ownership），程式設計規範

　　XP開發小組經常整合不同的子產品。為了提高軟體品質，除了測試驅動開發和Pair Programming以外，XP要求每個人的代碼都要遵守程式設計規範，任何人都可以修改其他人寫的代碼，而且所有人都應該主動檢查其他人寫的代碼。

　　頻繁地整合 （Integration ）

　　在很多項目中，開發人員往往很遲才把各個子產品整合在一起。在這些項目中，開發人員經常在整合過程中發現很多問題，但不能肯定到底是誰的程式出了問題；而且，隻有整合完成後，開發人員才開始稍稍使用整個系統，然後就馬上傳遞給客戶驗收。對于客戶來說，即使這些系統能夠通過終驗收測試，因為使用時間短，客戶門心裡并沒有多少把握。

　　為了解決這些問題，XP提出，整個項目過程中，應該頻繁地，盡可能地整合已經開發完的USER STORY（每次整合一個新的USER STORY）。每次整合，都要運作相應的單元測試和驗收測試，保證符合客戶和開發的要求。整合後，就釋出一個新的應用系統。這樣，整個項目開發過程中，幾乎每隔一兩天，都會釋出一個新系統，有時甚至會一天釋出好幾個版本。通過這個過程，客戶能非常清楚地掌握已經完成的功能和開發進度，并基于這些情況和開發人員進行有效地、及時地交流，以確定項目順利完成。

　　集體擁有代碼（Collective Code Ownership）

　　在很多項目開發過程中，開發人員隻維護自己的代碼，而且很多人不喜歡其他人随意修改自己的代碼。是以，即使可能有相應的比較詳細的開發文檔，但一個程式員卻很少、也不太願意去讀其他程式員的代碼；而且，因為不清楚其他人的程式到底實作了什麼功能，一個程式員一般也不敢随便改動其他人的代碼。同時，因為是自己維護自己的代碼，可能因為時間緊張或技術水準的局限性，某些問題一直不能被發現或得到比較好的解決。針對這點，XP提倡大家共同擁有代碼，每個人都有權利和義務閱讀其他代碼，發現和糾正錯誤，重整和優化代碼。這樣，這些代碼就不僅僅是一兩個人寫的，而是由整個項目開發隊伍共同完成的，錯誤會減少很多，重用性會盡可能地得到提高，代碼品質是非常好。

　　為了防止修改其他人的代碼而引起系統崩潰，每個人在修改後都應該運作測試程式。（從這點，我們可以再次看到，XP的各個慣例和規則是怎樣有機地結合在一起的。）

　　程式設計規範

　　XP開發小組中的所有人都遵循一個統一的程式設計标準，是以，所有的代碼看起來好像是一個人寫的。因為有了統一的程式設計規範，每個程式員更加容易讀懂其他人寫的代碼，這是是實作Collective Code Ownership的重要前提之一。

5 Metaphor（系統比喻），不加班

　　XP過程通過使用一些形象的比喻讓所有人對系統有個共同的、簡潔的認識。XP認為加班是不正常的，因為這說明關于項目進度的估計和安排有問題。

　　Metaphor（系統比喻）

　　為了幫助每個人一緻清楚地了解要完成的客戶需求、要開發的系統功能，XP開發小組用很多形象的比喻來描述系統或功能子產品是怎樣工作的。比如，對于一個搜尋引擎，它的Metaphor可能就是“一大群蜘蛛，在網上四處尋找要捕捉的東西，然後把東西帶回巢穴。”

　　不加班

　　大量的加班意味着原來的計劃是不準确的，或者是程式遠不清楚自己到底什麼時候能完成什麼工作。而且，開發管理人員和客戶也是以無法準确掌握開發速度；開發人員也是以非常疲勞。XP認為，如果出現大量的加班現象，開發管理人員（比如Coach）應該和客戶一起确定加班的原因，并及時調整項目計劃、進度和資源。

XP中一些基本概念的簡介

　　User Story：開發人員要求客戶把所有的需求寫成一個個獨立的小故事，每個隻需要幾天時間就可以完成。開發過程中，客戶可以随時提出新的User Story，或者更改以前的User Story。

　　Story Estimates和開發速度：開發小組對每個User Story進行估算，并根據每個開發周期（Iteration）中的實際情況反複計算開發速度。這樣，開發人員和客戶能知道每個星期到底能開發多少User Story。

　　Release Plan和Release Scope：整個開發過程中，開發人員将不斷地釋出新版本。開發人員和客戶一起确定每個釋出所包含的User Story。

　　Iteration（開發周期）和Iteration Plan：在一個Release過程中，開發人員要求客戶選擇最有價值的User Story作為未來一兩個星期的開發内容。

　　The Seed：第一個開發周期（Iteration）完成後，送出給客戶的系統。雖然這不是最終的産品，但它已經實作了幾個客戶認為是最重要的Story，開發人員将逐漸在其基礎上增加新的子產品。

　　Continuous Integration（整合）：把開發完的User Story的子產品一個個拼裝起來，一步步接近乃至最終完成最終産品。

　　驗收測試（功能測試）：對于每個User Story，客戶将定義一些測試案例，開發人員将使運作這些測試案例的過程自動化。

　　Unit Test（單元測試）：在開始寫程式前，程式員針對大部分類的方法，先寫出相應的測試程式。

　　Refactoring (重整和優化) ：去掉代碼中的備援部分，增加代碼的可重用性和伸縮性。

小結

　　XP的一個成功因素是重視客戶的回報——開發的目的就是為了滿足客戶的需要。XP方法使開發人員始終都能自信地面對客戶需求的變化。XP強調團隊合作，經理、客戶和開發人員都是開發團隊中的一員。團隊通過互相之間的充分交流和合作，使用XP這種簡單但有效的方式，努力開發出高品質的軟體。XP的設計簡單而高效；程式員們通過測試獲得客戶回報，并根據變化修改代碼和設計，他們總是争取盡可能早地将軟體傳遞給客戶。XP程式員能夠勇于面對需求和技術上的變化。

　　XP很象一個由很多小塊拼起來的智力拼圖，單獨看每一小塊都沒有什麼意義，但拼裝好後，一幅美麗的圖畫就會呈現在你面前。