XP 精華 如何使 java 項目獲得更大成功 Roy W. Miller (rmiller@rolemodelsoft.com) 軟件開發人員，RoleModel Software, Inc. Christopher T. Collins (ccollins@rolemodelsoft.com) 高級軟件開發人員，RoleModel Software, Inc.
內容：
企業問題 一種解決方案：靈活方法 XP 的 12 種方法 一起工作的方法 為什么 XP 很重要 參考資料 關于作者 評價這篇文章
使用 Java 語言所進行的面向對象編程變得空前普及。它使軟件開發發生了某種程度上的變革，但最近的研究表明，有半數的軟件開發項目滯后，而三分之一的項目則超出預算。問題不在于技術，而是開發軟件所使用的方法。所謂的“輕量型”或“靈活”方式，與如 Java 這樣的面向對象語言的威力和靈活性結合起來，提供了一種很有意思的解決方案。最常見的靈活方式稱為極端編程（Extreme PRogramming）或者 XP，但許多人并不真正了解它。對 Java 項目使用 XP 可以大大增加成功的機會。本文提供了 XP 的概述，并解釋了它為什么很重要 -- 不是傳言，也沒有騙局。
在 Gary Hamel 所著的 Leading the Revolution（請參閱參考資料）一書中，他聲稱已有一些跡象證實傳統企業模式的優勢已不那么明顯。我們必須找到一些替代方法來為收入的持續增長提供動力。他建議唯一能讓公司繼續增長的辦法是進行一次徹底的創新。我們認為在軟件開發領域中尤其需要這樣。
XP 提供了十年來最大的一次機會，給軟件開發過程帶來徹底變革。就象 Peopleware 作家 Tom DeMarco 所說，“XP 是當今我們所處領域中最重要的一項運動。預計它對于目前一代的重要性就象 SEI 及其能力成熟度模型對上一代的重要性一樣。”
XP 規定了一組核心價值和方法，可以讓軟件開發人員發揮他們的專長：編寫代碼。XP 消除了大多數重量型過程的不必要產物，通過減慢開發速度、耗費開發人員的精力（例如干特圖、狀態報告，以及多卷需求文檔）從目標偏離。我們熟悉到一個稱為“極端編程”的東西可能很難作為正式的開發過程推薦給治理層，但假如您的公司從事軟件行業，您應該幫助治理層繞過其名稱熟悉到 XP 可以提供的競爭優勢。
Kent Beck 在他所著的 Extreme Programming Explained: Embrace Change 一書中概括了 XP 的核心價值（請參閱參考資料）。我們對它們進行了總結：
勇氣。 勇氣存在于其它三個價值的環境中。它們相互支持。需要勇氣來相信一路上具體反饋比預先知道每樣事物來得更好。需要勇氣來在可能暴露您的無知時與團隊中其他人交流。需要勇氣來使系統盡可能簡單，將明天的決定推到明天做。而假如沒有簡單的系統、沒有不斷的交流來擴展知識、沒有把握方向所依靠的反饋，勇氣也就失去了依靠。 XP 的方法將這些價值轉換成開發人員天天應做的事情。這里沒什么新鮮內容。多年以來，行業熟悉到 XP 方法是“最優方法”。實際上，XP 中的“極端”來自兩方面：
XP 采取經過證實的業界最優方法并將其發揮到極致。 XP 將這些方法以某種方式進行結合，使它們產生的結果大于各部分的總和。 這是怎樣的情景呢？代碼復查是個好的做法，因此始終通過成對地編寫代碼來做到。測試也是個好的做法，因此總是通過在編寫代碼之前編寫測試來做到。文檔很少與代碼保持一致，因此只做那些最需要的事，余下的部分則取決于明確編寫的代碼和測試。XP 不保證人們總做正確的事，但它答應人們這樣做。它將這些“極端”方法以一種相互支持的方式結合起來，顯著提高了速度和有效性。
XP 的十二種方法 XP 的十二種方法（如圖 2 所示）將其定義為規則。讓我們仔細研究每一個方法來對“執行 XP”表示什么有個更全面的理解。
圖 2. XP 的十二種方法
規劃策略 有些人會指責 XP 是一種美其名的剽竊，只是一群牛仔在沒有任何規則的情況下將一個系統拼湊在一起。錯。XP 是為數不多的幾種承認您在開始時不可能事事通曉的方法之一。無論是用戶還是開發人員都是隨著項目的進展過程才逐步了解事物的。只有鼓勵和信仰這種更改的方法才是有效方法。狀態限定方法忽視更改。而 XP 則留心更改。它傾聽所用的方法就是“規劃策略”，一個由 Kent Beck 創造的概念。
這一方法背后的主要思想是迅速地制定粗略計劃，然后隨著事物的不斷清楚來逐步完善。規劃策略的產物包括：一堆索引卡，每一張都包含一個客戶素材，這些素材驅動項目的迭代；以及對下一兩個發行版的粗略計劃，如 Kent Beck 和 Martin Fowler 在他們的 Planning Extreme Programming 中描述的那樣（請參閱參考資料）。讓這種形式的計劃得以發揮作用的要害因素是讓用戶做企業決策，讓開發小組做技術決策。假如沒有這一前提，整個過程就會土崩瓦解。
開發人員只有在通過所有單元測試后才可以將代碼檢入到源代碼資源庫中。單元測試使開發人員有信心相信他們的代碼能夠工作。這為其他開發人員留下線索，可以幫助他們理解最早的開發人員的意圖（實際上，這是我們看到過的最好的文檔）。單元測試還給了開發人員勇氣重新劃分代碼，因為測試失敗可以馬上告訴開發人員存在錯誤。應該將單元測試自動化，并提供明確的通過／失敗結果。xUnit 框架（請參閱參考資料）做到的遠不止這些，因此大多數 XP 小組都使用它們。
用戶負責確保每個素材都有驗收測試來確認它們。用戶可以自己編寫測試、可以征募組織中的其他成員（例如 QA 人員或業務分析員）編寫它們，也可以將這兩種方法結合起來。測試告訴他們系統是否具有應該具有的那些特性，以及是否可以正確工作。理想情況下，用戶在迭代完成之前就應該寫好迭代中那些素材的驗收測試了。應該將驗收測試自動化，并要經常運行來確保開發人員在實現新特性時沒有破壞任何現有的特性。通常情況下，客戶需要來自開發團隊的某些幫助來編寫驗收測試。我們對一個項目開發一個可重用的自動驗收測試框架，可以讓用戶在簡單編輯器中輸入他們的輸入和所期望的輸出。框架將輸入轉換成 xml 文件、運行文件中的測試，然后為每個測試顯示“通過”或“失敗”。客戶喜歡這一做法。
XP 建議您應該編寫可能運行的最簡單的代碼，但同時也建議您應該不斷學習。重新劃分讓您將學到的知識加入到代碼中，同時又不會破壞測試。它使您的代碼簡練。這意味著它可以存在相當長的時間、為以后的開發人員引入更少問題，并為他們指引正確的方向。
簡單的設計 XP 的誹謗者說該過程忽略了設計。事實不是這樣。問題是重量型方法建議您做的不過是提前完成大部分瑣碎的設計任務。這就象是拍一張靜態的地平線的照片，靜止不動，然后嘗試畫一張如何到達那里的完美的地圖。XP 說設計不應該在事物將保持不變的前提下預先倉促進行。XP 認為設計非常重要，因此應該是一個持續的事務。我們總是先嘗試使用能夠工作的最簡單的設計，然后隨著現實的不斷顯現來更改它。
什么是可能工作的最簡單的設計？它是符合以下條件的設計（感謝 Kent Beck 為我們一一列出）：
運行所有測試 不包含重復代碼 明確陳述程序員對所有代碼的意圖 包含盡可能最少的類和方法
對簡單設計的需求并不是說所有設計都很小，也不表示它們是無足輕重的。它們只不過需要盡可能簡單，但是仍能工作。不要包括不使用的額外特性。我們稱這樣的事物為 YAGNI，表示“您將不需要它（You Aren′t Going to Need It）。”不要讓 YAGNI 破壞您成功的機會。
“每人擁有所有代碼”與“沒人擁有代碼”的說法并不一樣。沒人擁有代碼時，人們可以隨處進行破壞而不必負任何責任。而 XP 說，“假如是您破壞的，應該您來彌補。”我們有一些必須在每次集成之前和之后運行的單元測試。假如您破壞了某些事物，您要負責進行修補，無論它位于代碼的哪一部分。這需要極端規則。可能這是名稱中帶有“極端”的另一個原因。
