使用面向對象程式設計變得空前普及。它使軟體開發發生了某種程度上的變革，但最近的研究表 明，有半數的軟體開發項目滞後，而三分之一的項目則超出預算。問題不在于技術，而是開發軟體所使用的方法。所謂的“輕量型”或“靈活”方式，與面向對象語 言的威力和靈活性結合起來，提供了一種很有意思的解決方案。最常見的靈活方式稱為極端程式設計（Extreme Programming）或者 XP，但許多人并不真正了解它。對軟體項目使用 XP 可以大大增加成功的機會。本文提供了 XP 的概述，并解釋了它為什麼很重要 -- 不是傳言，也沒有騙局。
在過去的十年中，CEO 們在産生穩步增加的收入方面面臨巨大的壓力。他們通過在許多方面采取一系列舉措來解決這一問題，例如縮小公司規模、外包、再工程、企業資源規劃 (ERP) 等等。這些對低效率的解決措施讓 S&P 500 中的許多企業在 90 年代末能夠連續幾年保持兩位數的收入增長。但這種方式也帶來了一些負面影響。
在 Gary Hamel 所著的 Leading the Revolution（請參閱參考資料）一書中，他聲稱已有一些迹象證明傳統企業模式的優勢已不那麼明顯。我們必須找到一些替代方法來為收入的持續增長提 供動力。他建議唯一能讓公司繼續增長的辦法是進行一次徹底的創新。我們認為在軟體開發領域中尤其需要這樣。
企業問題
如果使用标準軟體開發方法，那麼即使在常用的平台上進行開發，也要做好失望的準備。如圖 1 所示，最近的研究表明，有一半項目将滞後，而三分之一的項目将超過預算。這一推測比 1979 年由美國總審計局的研究結果好不了多少。
如果我們希望這些數字有顯著提高，則需要徹底創新的方法來開發軟體。有兩個主要因素影響現有的方法： 懼怕失敗、對軟體本質的誤解。
沒有人打算失敗。具有諷刺意味的是為使失敗最小化而建立的方法是失敗的。對軟體的誤解是問題的根源。恐懼實際上隻是一種症狀。現有的方法是由那些有良 好願望但忘記了軟體中的“軟”的那些聰明人所建立的。他們假定開發軟體就象造橋。是以他們從各種設計規範中借鑒了一些适用于“硬”物體（例如橋梁）的最優 方法。結果是基于 Big Design Up-front (BDUF) 思想的反映遲鈍的開發方法，軟體不堪一擊，人們無法使用它們。
〈一〉一種解決方案：靈活方法
最近發生了一些轉變，從所謂的“重量型”方法轉向了“輕量型”或“靈活”方法，例如 Crystal 方法、适應性軟體開發和（目前最流行的）XP。所有這些過程都有這樣一個事實，即需要人們共同來開發軟體。成功的軟體過程必須将人們的長處最大化，将他們 的缺點最小化，因為優點和缺點毋庸質疑都存在。在我們看來，XP 最出色的地方在于它能夠解決所有影響參加人員的互補力量。
XP 提供了十年來最大的一次機會，給軟體開發過程帶來徹底變革。就象 Peopleware 作家 Tom DeMarco 所說，“XP 是當今我們所處領域中最重要的一項運動。預計它對于目前一代的重要性就象 SEI 及其能力成熟度模型對上一代的重要性一樣。”
XP 規定了一組核心價值和方法，可以讓軟體開發人員發揮他們的專長：編寫代碼。XP 消除了大多數重量型過程的不必要産物，通過減慢開發速度、耗費開發人員的精力（例如幹特圖、狀态報告，以及多卷需求文檔）從目标偏離。我們認識到一個稱為 “極端程式設計”的東西可能很難作為正式的開發過程推薦給管理層，但如果您的公司從事軟體行業，您應該幫助管理層繞過其名稱認識到 XP 可以提供的競争優勢。
Kent Beck 在他所著的 Extreme Programming Explained: Embrace Change 一書中概括了 XP 的核心價值（請參閱參考資料）。我們對它們進行了總結：
1）交流
項目的問題往往可以追溯到某人在某個時刻沒有和其他人一起商量某些重要問題上。使用 XP，不交流是不可能的事。
2）簡單
XP 建議您總是盡可能圍繞過程和編寫代碼做最簡單的事情。按照 Beck 的說法，“XP 就是打賭。它打賭今天最好做些簡單的事...而不是做更複雜但可能永遠也不會用到的事。”
3）回報
更早和經常來自客戶、團隊和實際最終使用者的具體回報意見為您提供更多的機會來調整您的力量。回報可以讓您把握住正确的方向，少走彎路。
4）勇氣
勇氣存在于其它三個價值的環境中。它們互相支援。需要勇氣來相信一路上具體回報比預先知道每樣事物來得更好。需要勇氣來在可能暴露您的無知時與團隊中 其他人交流。需要勇氣來使系統盡可能簡單，将明天的決定推到明天做。而如果沒有簡單的系統、沒有不斷的交流來擴充知識、沒有掌握方向所依賴的回報，勇氣也 就失去了依靠。
XP 的方法将這些價值轉換成開發人員每天應做的事情。這裡沒什麼新鮮内容。多年以來，行業認識到 XP 方法是“最優方法”。實際上，XP 中的“極端”來自兩方面：
XP 采取經過證明的業界最優方法并将其發揮到極緻。
XP 将這些方法以某種方式進行結合，使它們産生的結果大于各部分的總和。
這是怎樣的情景呢？代碼複查是個好的做法，是以始終通過成對地編寫代碼來做到。測試也是個好的做法，是以總是通過在編寫代碼之前編寫測試來做到。文檔 很少與代碼保持一緻，是以隻做那些最需要的事，餘下的部分則取決于明确編寫的代碼和測試。XP 不保證人們總做正确的事，但它允許人們這樣做。它将這些“極端”方法以一種互相支援的方式結合起來，顯著提高了速度和有效性。
〈二〉XP 的十二種方法
XP 的十二種方法（如圖 2 所示）将其定義為規則。讓我們仔細研究每一個方法來對“執行 XP”表示什麼有個更全面的了解。
1）規劃政策
有些人會指責 XP 是一種美其名的剽竊，隻是一群牛仔在沒有任何規則的情況下将一個系統拼湊在一起。錯。XP 是為數不多的幾種承認您在開始時不可能事事通曉的方法之一。無論是使用者還是開發人員都是随着項目的進展過程才逐漸了解事物的。隻有鼓勵和信奉這種更改的方 法才是有效方法。狀态限定方法忽視更改。而 XP 則留心更改。它傾聽所用的方法就是“規劃政策”，一個由 Kent Beck 創造的概念。
這一方法背後的主要思想是迅速地制定粗略計劃，然後随着事物的不斷清晰來逐漸完善。規劃政策的産物包括：一堆索引卡，每一張都包含一個客戶素材，這些 素材驅動項目的疊代；以及對下一兩個發行版的粗略計劃，如 Kent Beck 和 Martin Fowler 在他們的 Planning Extreme Programming 中描述的那樣（請參閱參考資料）。讓這種形式的計劃得以發揮作用的關鍵因素是讓使用者做企業決策，讓開發小組做技術決策。如果沒有這一前提，整個過程就會土 崩瓦解。
開發小組要決定：估計開發一個素材要花多長時間 、使用各種技術選項所花費的成本 、團隊組織 、每個素材的“風險” 、疊代中素材開發的順序（先開發風險最大的那一個可以減輕風險）。
客戶需要決定： 範圍（一個發行版的素材和每一次疊代的素材） 、發行日期 、優先級（根據企業價值先開發哪些特性）規劃經常發生。這樣，在客戶或開發人員學習新事物的同時，就為他們調整計劃提供了頻繁機會。
2）成對程式設計
使用 XP，成對的開發人員編寫所有産品代碼。這種方式聽上去好象缺乏效率。Martin Fowler 說，“當人們說成對程式設計降低生産力時，我回答，‘那是因為大多數耗費時間的程式設計部分是靠輸入來完成的。’”實際上，成對程式設計無論在經濟還是其它方面都提供 了許多好處： 所有設計決策都牽涉到至少兩個人、至少有兩個人熟悉系統的每一部分、幾乎不可能出現兩個人同時疏忽測試或其它任務、改變各對的組合在可以在團隊範圍内傳播 知識、代碼總是由至少一人複查。
研究還顯示成對的程式設計實際上比單獨程式設計更有效（有關詳細資訊，請參閱參考資料中 Alistair Cockburn 和 Laurie Williams 所著的 The Costs and Benefits of Pair Programming）。
3）測試
在 XP 中有兩種測試： 單元測試 、驗收測試 。
開發人員在他們編寫代碼的同時編寫單元測試。客戶在他們定義了素材後編寫驗收測試。單元測試及時告訴開發人員系統在某一點上是否“工作”。驗收測試告訴團隊系統是否執行使用者希望它執行的操作。
假設團隊使用的是如 Java 這樣的面向對象語言，開發人員在為一些方法編寫代碼之前為每種有可能失敗的方法編寫單元測試。然後他們編寫足夠的代碼使之能通過測試。有時人們會發現這有 點奇怪。答案很簡單。編寫測試首先為您提供：一組可能最完整的測試 、可能能工作的最簡單的代碼 、代碼意圖的明确景象 。
開發人員隻有在通過所有單元測試後才可以将代碼檢入到源代碼資源庫中。單元測試使開發人員有信心相信他們的代碼能夠工作。這為其他開發人員留下線索， 可以幫助他們了解最早的開發人員的意圖（實際上，這是我們看到過的最好的文檔）。單元測試還給了開發人員勇氣重新劃分代碼，因為測試失敗可以立刻告訴開發 人員存在錯誤。應該将單元測試自動化，并提供明确的通過／失敗結果。xUnit 架構（請參閱參考資料）做到的遠不止這些，是以大多數 XP 小組都使用它們。
使用者負責確定每個素材都有驗收測試來确認它們。使用者可以自己編寫測試、可以征募組織中的其他成員（例如 QA 人員或業務分析員）編寫它們，也可以将這兩種方法結合起來。測試告訴他們系統是否具有應該具有的那些特性，以及是否可以正确工作。理想情況下，使用者在疊代 完成之前就應該寫好疊代中那些素材的驗收測試了。應該将驗收測試自動化，并要經常運作來確定開發人員在實作新特性時沒有破壞任何現有的特性。通常情況下， 客戶需要來自開發團隊的某些幫助來編寫驗收測試。我們對一個項目開發一個可重用的自動驗收測試架構，可以讓使用者在簡單編輯器中輸入他們的輸入和所期望的輸 出。架構将輸入轉換成 XML 檔案、運作檔案中的測試，然後為每個測試顯示“通過”或“失敗”。客戶喜歡這一做法。
不是所有驗收測試都必須在所有情況下通過。問題是驗收測試幫助客戶衡量項目“完成”的情況如何。它們還可以讓客戶獲悉有關某些事物是否可以發行的決定。
4）重新劃分
重新劃分是在不更改功能性的前提下對代碼加以改進。XP 小組在進行重新劃分時毫不手軟。
開發人員重新劃分有兩個重要時機：實作特性之前和之後。開發人員嘗試确定更改現有代碼是否可以讓新特性的開發更容易。他們檢視剛剛寫好的代碼，看是否有方法可以對它進行簡化。例如，如果他們認為有抽象的機會，就會進行重新劃分來從具體實作中除去重複的代碼。
XP 建議您應該編寫可能運作的最簡單的代碼，但同時也建議您應該不斷學習。重新劃分讓您将學到的知識加入到代碼中，同時又不會破壞測試。它使您的代碼簡練。這意味着它可以存在相當長的時間、為以後的開發人員引入更少問題，并為他們指引正确的方向。
5）簡單的設計
XP 的诽謗者說該過程忽略了設計。事實不是這樣。問題是重量型方法建議您做的不過是提前完成大部分瑣碎的設計任務。這就象是拍一張靜态的地平線的照片，靜止不 動，然後嘗試畫一張如何到達那裡的完美的地圖。XP 說設計不應該在事物将保持不變的前提下預先倉促進行。XP 認為設計非常重要，是以應該是一個持續的事務。我們總是先嘗試使用能夠工作的最簡單的設計，然後随着現實的不斷顯現來更改它。
什麼是可能工作的最簡單的設計？它是符合以下條件的設計（感謝 Kent Beck 為我們一一列出）： 運作所有測試 、不包含重複代碼 、明确陳述程式員對所有代碼的意圖 、包含盡可能最少的類和方法 。
對簡單設計的需求并不是說所有設計都很小，也不表示它們是無足輕重的。它們隻不過需要盡可能簡單，但是仍能工作。不要包括不使用的額外特性。我們稱這 樣的事物為 YAGNI，表示“您将不需要它（You Aren’t Going to Need It）。”不要讓 YAGNI 破壞您成功的機會。
6）集合體代碼所有權
小組中的任何人都應該有權對代碼進行更改來改進它。每個人都擁有全部代碼，這意味着每個人都對它負責。這種技術可以讓人們對部分代碼進行必要的更改而不用經過代碼擁有者個人的瓶頸。每個人都負責這一事實消除了無代碼所有權所帶來的混亂。
“每人擁有所有代碼”與“沒人擁有代碼”的說法并不一樣。沒人擁有代碼時，人們可以随處進行破壞而不必負任何責任。而 XP 說，“如果是您破壞的，應該您來彌補。”我們有一些必須在每次內建之前和之後運作的單元測試。如果您破壞了某些事物，您要負責進行修補，無論它位于代碼的 哪一部分。這需要極端規則。可能這是名稱中帶有“極端”的另一個原因。
7）持續的內建
經常進行代碼內建可以幫助您避免內建夢魇。XP 團隊在一天中內建了代碼幾次，每次都在所有單元測試對系統運作後執行。
傳統方法工作方式如下：編寫大量代碼後執行一次大爆炸式的內建，然後花費相當長的時間來改正問題。這種笨拙的形式的确使項目速度減緩。大爆炸式的內建 給團隊立即帶來大量問題，并且這些問題通常都有幾百種可能的原因。如果經常進行內建，任何特定內建失敗的原因都會非常明顯（以前運作過測試，是以錯誤一定 是新事物犯下的）。使用這種方法，當遇到問題時，可能的原因就相當有限。修改起來更容易，花的時間少得多，使團隊保持最快速度前進。
8）現場客戶
要使功能最理想，XP 小組需要在現場有一位客戶來明确素材，并做出重要的企業決策。開發人員是不允許單獨做這些事情的。讓客戶随時在場可以消除開發人員等待決策時出現的瓶頸。
XP 不會假裝素材卡是開發人員傳遞必要代碼所需的唯一訓示。素材是對以後在客戶和開發人員之間填寫細節的對話的一項承諾。與将所有要求寫在一個靜态文檔中不同，其思想是進行面對面的交流，減少産生誤解的機會。
我們發現讓客戶在現場是可能最好的一種情形，但這不是解決問題的唯一方案。底線是客戶必須随時在需要回答問題和根據企業價值為團隊提供訓示時有空。如果客戶并非在現場專職陪伴團隊的情況下就能做到這些，那很好。如果能和團隊待在一起，這會更友善，但隻是建議而已。
9）小發行版
發行版應該盡可能地小，同時仍然提供足夠的企業價值以證明它們值得。
隻要覺得有意義就可以釋出系統。這樣就盡可能早為使用者提供了價值（請記住，今天的錢比明天的錢來得值錢）。小發行版将為開發人員提供具體的回報意見，告訴他們哪些符合客戶需要，哪些不符合客戶需要。然後，小組可以将這些經驗教訓包括在其下一發行版的規劃中。
10）一周 40 小時
Kent Beck 說他希望“...每天早晨都感到有活力有激情，每天晚上都感到疲憊而滿足。”一周 40 小時工作可以讓您做到這一點。确切的小時數并不重要，重要的是原則。長時間地持續工作會扼殺工作績效。疲勞的開發人員會犯更多錯誤，從長期來說，将比按“ 正常”時間表進行的開發慢得多。
即使開發人員可以在長時間很好工作，這也不意味着他們應該這樣。最終他們會厭倦，會離開他們的工作，或者産生影響他們工作績效的非工作問題。如果您打 亂了人們的生活，将會嘗到它所帶來的惡果。加班并不是解決項目問題的答案。實際上，它是更大問題的症狀。如果您要走向滅亡，就無藥可救了。
11）編碼标準
擁有編碼标準有兩個目的：a.防止團隊被一些例如事物沒有以最大速度發展這種無關緊要的愚蠢争論搞得不知所措；b.它支援其它方法。
如果沒有編碼标準，重新劃分代碼會更加困難，按應當的頻度交換對更困難，快速前進也更困難。目标應該是團隊中沒有人辨認得出是誰寫的哪一部分代碼。以 團隊為機關對某一标準達成協定，然後遵守這一标準。目标不是建立一個事無巨細的規則清單，而是提供将確定您的代碼可以清晰交流的指導方針。編碼标準開始時 應該很簡單，然後根據團隊經驗逐漸進化。不要預先花費太多時間。建立能夠工作的最簡單标準，然後逐漸發展。
12）系統比喻
體系結構是做什麼用的？它提供了系統各種元件以及它們是如何互動的畫面 -- 一種映射，可以讓開發人員了解新的代碼部分适合放在哪裡。
XP 中的系統比喻與大多數方法稱作的體系結構差不多。比喻為團隊提供了一緻的畫面，他們可以用它來描述現有系統的工作方式、新部件适合的位置，以及它們應該采取的形式。
重要的是要記住，關鍵要讓每個人了解系統是如何組合在一起的，而不是美麗的比喻。有時您就是無法想到一個好的比喻。想到時就太好了。
标簽： 軟體 xp 使用者 滑鼠
![各種二分查找[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)