Extreme Programming （XP）實踐

1 為什麼是XP

讓我們來考慮一個傳統的途徑：使用者組和開發組協商讓一個分析員設計一個專案。在幾周和幾個月中，分析員和使用者每天會面幾個小時。分析員生產出一套文件，可能還包括象一個可視描述和用例之類。使用者和專案經理（也可能是程式設計團隊）回顧這些文件並且協商出一個發行版。程式設計師使用規範在幾個月之後成長出一個系統，或多或少的實現了原來的想法。在結束的時候這通常是一個閉呼叫系統，當人們發現他們所遺漏的並意識到自從文件被寫好以來什麼都已經改變了。最後，使用者加入進來作一個使用者接受測試然後系統被髮布。 

通常整個過程所花費的時間比任何人所期望的都長，會遺漏一些特徵，並且質量並不是使用者想要的。更有甚著，文件也不再隨日期更新。 

問題總結： 
不能完全理解使用者需求（使用者自己也經常不清楚自己需要什麼） 
使用者的要求不斷變化 
技術更新速度很快 
開發人員缺乏成功經驗 
開發小組不穩定 
沒有完整的測試設計 


--------------------------------------------------------------------------------


2 XP簡介

XP全名Extreme Programming ，一種輕量級，靈活的方法。 
XP 規定了一組核心價值和方法，可以讓軟體開發人員發揮他們的專長：編寫程式碼。XP 消除了大多數重量型過程的不必要產物，通過減慢開發速度、耗費開發人員的精力（例如干特圖、狀態報告，以及多卷需求文件）從目標偏離。 
在XP中，在使用者vs程式設計師的角色中有一個基本的分隔。使用者擁有*what you get*，而程式設計師擁有*what it costs*。這顯示了誰能作出什麼決定。 即使用者做企業決策，程式設計師做技術決策。 

2.1 使用者決定： 

範圍：什麼系統是必須作的。 

優先順序：對於企業價值什麼是最重要的。 

發行的組合：什麼是必須在發行版中的，一定是有用的？ 

發行的日期：什麼時候需要發行？ 

2.2 程式設計師決定： 

評估新增一個特徵的時間 ，以及每個特徵的風險 

使用各種技術選項所花費的成本 ：程式設計師解釋程式選擇的結果，但是使用者作決定 

過程：小組怎麼樣工作，團隊怎麼組織 

細節時間表：在一個迭代中特徵先開發風險最大的那一個特徵可以減輕風險 

2.3 XP 的核心價值為： 

交流。 專案的問題往往可以追溯到某人在某個時刻沒有和其他人一起商量某些重要問題上。使用 XP，不交流是不可能的事。 


簡單。 XP 建議您總是儘可能圍繞過程和編寫程式碼做最簡單的事情。按照 Beck 的說法，“XP 就是打賭。它打賭今天最好做些簡單的事...而不是做更復雜但可能永遠也不會用到的事。” 


反饋。 更早和經常來自客戶、團隊和實際終端使用者的具體反饋意見為您提供更多的機會來調整您的力量。反饋可以讓您把握住正確的方向，少走彎路。 


勇氣。 勇氣存在於其它三個價值的環境中。它們相互支援。需要勇氣來相信一路上具體反饋比預先知道每樣事物來得更好。需要勇氣來在可能暴露您的無知時與團隊中其他人交流。需要勇氣來使系統儘可能簡單，將明天的決定推到明天做。而如果沒有簡單的系統、沒有不斷的交流來擴充套件知識、沒有掌握方向所依賴的反饋，勇氣也就失去了依靠。 


--------------------------------------------------------------------------------


3 XP的十二種實踐方法： 


重新劃分（Refactoring） 

系統比喻(Metaphor) 

簡單設計(Simple design) 

一週40小時 (40-hour week) 

編碼標準(Coding standards) 

持續整合(Continuous integration) 

成對程式設計(pair programming) 

集體程式碼所有權(Collective ownership) 

現場客戶(On-site customer) 

規劃策略(Planning game) 

小發行版(Small releases) 

測試(Testing) 

3.1 規劃策略 
有些人會指責 XP 是一種美其名的剽竊，只是一群牛仔在沒有任何規則的情況下將一個系統拼湊在一起。錯。XP 是為數不多的幾種承認您在開始時不可能事事通曉的方法之一。無論是使用者還是開發人員都是隨著專案的進展過程才逐步瞭解事物的。只有鼓勵和信奉這種更改的方法才是有效方法。狀態限定方法忽視更改。而 XP 則留心更改。它傾聽所用的方法就是*規劃策略*，一個由 Kent Beck 創造的概念。 
這一方法背後的主要思想是迅速地制定粗略計劃，然後隨著事物的不斷清晰來逐步完善。規劃策略的產物包括：一堆索引卡，每一張都包含一個客戶素材，這些素材驅動專案的迭代；以及對下一兩個發行版的粗略計劃，如 Kent Beck 和 Martin Fowler 在他們的 Planning Extreme Programming 中描述的那樣。讓這種形式的計劃得以發揮作用的關鍵因素是讓使用者做企業決策，讓開發小組做技術決策。如果沒有這一前提，整個過程就會土崩瓦解。 

3.2 系統比喻 
體系結構是做什麼用的？它提供了系統各種元件以及它們是如何互動的畫面 -- 一種對映，可以讓開發人員瞭解新的程式碼部分適合放在哪裡。 
XP 中的系統比喻與大多數方法稱作的體系結構差不多。比喻為團隊提供了一致的畫面，他們可以用它來描述現有系統的工作方式、新部件適合的位置，以及它們應該採取的形式。 
重要的是要記住，關鍵要讓每個人理解系統是如何組合在一起的，而不是美麗的比喻。有時您就是無法想到一個好的比喻。想到時就太好了。　 

3.3 測試 
在 XP 中有兩種測試： 
1. 單元測試 
2. 驗收測試 
開發人員在他們編寫程式碼的同時編寫單元測試。客戶在他們定義了素材後編寫驗收測試。單元測試及時告訴開發人員系統在某一點上是否*工作*。驗收測試告訴團隊系統是否執行使用者希望它執行的操作。 
假設團隊使用的是如 Java 這樣的面嚮物件語言，開發人員在為一些方法編寫程式碼之前為每種有可能失敗的方法編寫單元測試。然後他們編寫足夠的程式碼使之能通過測試。有時人們會發現這有點奇怪。答案很簡單。編寫測試首先為您提供： 

一組可能最完整的測試 

可能能工作的最簡單的程式碼 

程式碼意圖的明確景象 
開發人員只有在通過所有單元測試後才可以將程式碼檢入到原始碼資源庫中。單元測試使開發人員有信心相信他們的程式碼能夠工作。這為其他開發人員留下線索，可以幫助他們理解最早的開發人員的意圖（實際上，這是我們看到過的最好的文件）。單元測試還給了開發人員勇氣重新劃分程式碼，因為測試失敗可以立刻告訴開發人員存在錯誤。應該將單元測試自動化，並提供明確的通過／失敗結果。xUnit 框架做到的遠不止這些，因此大多數 XP 小組都使用它們。 
使用者負責確保每個素材都有驗收測試來確認它們。使用者可以自己編寫測試、可以徵募組織中的其他成員（例如 QA 人員或業務分析員）編寫它們，也可以將這兩種方法結合起來。測試告訴他們系統是否具有應該具有的那些特性，以及是否可以正確工作。理想情況下，使用者在迭代完成之前就應該寫好迭代中那些素材的驗收測試了。應該將驗收測試自動化，並要經常執行來確保開發人員在實現新特性時沒有破壞任何現有的特性。通常情況下，客戶需要來自開發團隊的某些幫助來編寫驗收測試。我們對一個專案開發一個可重用的自動驗收測試框架，可以讓使用者在簡單編輯器中輸入他們的輸入和所期望的輸出。框架將輸入轉換成 XML 檔案、執行檔案中的測試，然後為每個測試顯示*通過*或*失敗*。客戶喜歡這一做法。 
不是所有驗收測試都必須在所有情況下通過。問題是驗收測試幫助客戶衡量專案*完成*的情況如何。它們還可以讓客戶獲悉有關某些事物是否可以發行的決定。 

3.4 重構 
重構是在不更改功能性的前提下對程式碼加以改進。XP 小組在進行重構時毫不手軟。 
開發人員重構有兩個重要時機：實現特性之前和之後。開發人員嘗試確定更改現有程式碼是否可以讓新特性的開發更容易。他們檢視剛剛寫好的程式碼，看是否有方法可以對它進行簡化。例如，如果他們認為有抽象的機會，就會進行重構來從具體實現中除去重複的程式碼。 
XP 建議您應該編寫可能執行的最簡單的程式碼，但同時也建議您應該不斷學習。重構讓您將學到的知識加入到程式碼中，同時又不會破壞測試。它使您的程式碼簡練。這意味著它可以存在相當長的時間、為以後的開發人員引入更少問題，併為他們指引正確的方向。 

3.5 成對程式設計 
使用 XP，成對的開發人員編寫所有產品程式碼。這種方式聽上去好象缺乏效率。Martin Fowler 說，*當人們說成對程式設計降低生產力時，我回答，'那是因為大多數耗費時間的程式設計部分是靠輸入來完成的。'*實際上，成對程式設計無論在經濟還是其它方面都提供了許多好處： 

所有設計決策都牽涉到至少兩個人。 

至少有兩個人熟悉系統的每一部分。 

幾乎不可能出現兩個人同時疏忽測試或其它任務。 

改變各對的組合在可以在團隊範圍內傳播知識。 

程式碼總是由至少一人複查。 
研究還顯示成對的程式設計實際上比單獨程式設計更有效。 

3.6 小發行版 
發行版應該儘可能地小，同時仍然提供足夠的企業價值以證明它們值得。 
只要覺得有意義就可以釋出系統。這樣就儘可能早為使用者提供了價值（請記住，今天的錢比明天的錢來得值錢）。小發行版將為開發人員提供具體的反饋意見，告訴他們哪些符合客戶需要，哪些不符合客戶需要。然後，小組可以將這些經驗教訓包括在其下一發行版的規劃中。 

3.7 簡單的設計 
XP 的誹謗者說該過程忽略了設計。事實不是這樣。問題是重量型方法建議您做的不過是提前完成大部分瑣碎的設計任務。這就象是拍一張靜態的地平線的照片，靜止不動，然後嘗試畫一張如何到達那裡的完美的地圖。XP 說設計不應該在事物將保持不變的前提下預先倉促進行。XP 認為設計非常重要，因此應該是一個持續的事務。我們總是先嚐試使用能夠工作的最簡單的設計，然後隨著現實的不斷顯現來更改它。 
什麼是可能工作的最簡單的設計？它是符合以下條件的設計： 

執行所有測試 

不包含重複程式碼 

明確陳述程式設計師對所有程式碼的意圖 

包含儘可能最少的類和方法 
對簡單設計的需求並不是說所有設計都很小，也不表示它們是無足輕重的。它們只不過需要儘可能簡單，但是仍能工作。不要包括不使用的額外特性。我們稱這樣的事物為 YAGNI，表示*您將不需要它（You Aren't Going to Need It）。*不要讓 YAGNI 破壞您成功的機會。 

3.8 集體程式碼所有權 
小組中的任何人都應該有權對程式碼進行更改來改進它。每個人都擁有全部程式碼，這意味著每個人都對它負責。這種技術可以讓人們對部分程式碼進行必要的更改而不用經過程式碼擁有者個人的瓶頸。每個人都負責這一事實消除了無程式碼所有權所帶來的混亂。 

每人擁有所有程式碼*與*沒人擁有程式碼*的說法並不一樣。沒人擁有程式碼時，人們可以隨處進行破壞而不必負任何責任。而 XP 說，*如果是您破壞的，應該您來彌補。*我們有一些必須在每次整合之前和之後執行的單元測試。如果您破壞了某些事物，您要負責進行修補，無論它位於程式碼的哪一部分。這需要極端規則。可能這是名稱中帶有*極端*的另一個原因。 

3.9 持續的整合 
經常進行程式碼整合可以幫助您避免整合夢魘。XP 團隊在一天中整合了程式碼幾次，每次都在所有單元測試對系統執行後執行。 
傳統方法工作方式如下：編寫大量程式碼後執行一次大爆炸式的整合，然後花費相當長的時間來改正問題。這種笨拙的形式的確使專案速度減緩。大爆炸式的整合給團隊立即帶來大量問題，並且這些問題通常都有幾百種可能的原因。 
如果經常進行整合，任何特定整合失敗的原因都會非常明顯（以前執行過測試，因此錯誤一定是新事物犯下的）。使用這種方法，當遇到問題時，可能的原因就相當有限。修改起來更容易，花的時間少得多，使團隊保持最快速度前進。 

3.10 現場客戶 
要使功能最理想，XP 小組需要在現場有一位客戶來明確素材，並做出重要的企業決策。開發人員是不允許單獨做這些事情的。讓客戶隨時在場可以消除開發人員等待決策時出現的瓶頸。 
XP 不會假裝素材卡是開發人員交付必要程式碼所需的唯一指示。素材是對以後在客戶和開發人員之間填寫細節的對話的一項承諾。與將所有要求寫在一個靜態文件中不同，其思想是進行面對面的交流，減少產生誤解的機會。 
我們發現讓客戶在現場是可能最好的一種情形，但這不是解決問題的唯一方案。底線是客戶必須隨時在需要回答問題和根據企業價值為團隊提供指示時有空。如果客戶並非在現場專職陪伴團隊的情況下就能做到這些，那很好。如果能和團隊待在一起，這會更方便，但只是建議而已。 

3.11 編碼標準 
擁有編碼標準有兩個目的： 

防止團隊被一些例如事物沒有以最大速度發展這種無關緊要的愚蠢爭論搞得不知所措。 

它支援其它方法。 
如果沒有編碼標準，重新劃分程式碼會更加困難，按應當的頻度交換對更困難，快速前進也更困難。目標應該是團隊中沒有人辨認得出是誰寫的哪一部分程式碼。以團隊為單位對某一標準達成協議，然後遵守這一標準。目標不是建立一個事無鉅細的規則列表，而是提供將確保您的程式碼可以清晰交流的指導方針。編碼標準開始時應該很簡單，然後根據團隊經驗逐步進化。不要預先花費太多時間。建立能夠工作的最簡單標準，然後逐步發展。 

3.12 一週 40 小時 
Kent Beck 說他希望*...每天早晨都感到有活力有激情，每天晚上都感到疲憊而滿足。*一週 40 小時工作可以讓您做到這一點。確切的小時數並不重要，重要的是原則。長時間地持續工作會扼殺工作績效。疲勞的開發人員會犯更多錯誤，從長期來說，將比按*正常*時間表進行的開發慢得多。 
即使開發人員可以在長時間很好工作，這也不意味著他們應該這樣。最終他們會厭倦，會離開他們的工作，或者產生影響他們工作績效的非工作問題。如果您打亂了人們的生活，將會嚐到它所帶來的惡果。加班並不是解決專案問題的答案。實際上，它是更大問題的症狀。如果您要走向滅亡，就無藥可救了。 


--------------------------------------------------------------------------------


4 XP過程中的各個階段

作為一個軟體開發過程，XP中計劃，設計，編碼和測試各階段包括的內容比較簡潔，容易實施。 

4.1 計劃 

User stories的編寫 

識別需求方面 

開發計劃的制定 

經常構造版本 

版本控制 

Load Factor因子的確定 

將專案分解為各個迭代期 

每個迭代期開始時制定計劃 

人員集中 

站著開每日晨會 

當實施遇到困難時及時修正 

4.2 測試 

所有程式碼均需進行單元測試 

發行之前所有程式碼必須通過單元測試 

Bug發現後應馬上測試 　 

4.3 編碼 

始終獲得使用者的支援 

程式碼的書寫必須按照規範 

所有程式碼均採用配對開發 

一次只能有一對開發人員進行發行 

程式碼經常整合 

程式碼共享 

將優化放在最後 

不要加班 

4.4 設計 

簡單化 

採用程式設計規範 

設計時使用CRC卡片 

使用Spike Solution 方法 

不要過早新增新功能 

儘可能保持程式的簡潔性 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-582369/，如需轉載，請註明出處，否則將追究法律責任。