使用 Java 語言所進行的面向對象編程變得空前普及
它使軟件開發發生了某種程度上的變革
但最近的研究表明
有半數的軟件開發項目滯後
而三分之一的項目則超出預算
問題不在於技術
而是開發軟件所使用的方法
所謂的
輕量型
或
靈活
方式
與如 Java 這樣的面向對象語言的威力和靈活性結合起來
提供了一種很有意思的解決方案
最常見的靈活方式稱為極端編程（Extreme Programming）或者 XP
但許多人並不真正了解它
對 Java 項目使用 XP 可以大大增加成功的機會
本文提供了 XP 的概述
並解釋了它為什麼很重要
不是傳言
也沒有騙局
在過去的十年中
CEO 們在產生穩步增加的收入方面面臨巨大的壓力
他們通過在許多方面采取一系列舉措來解決這一問題
例如縮小公司規模
外包
再工程
企業資源規劃 (ERP) 等等
這些對低效率的解決措施讓 S&P
中的許多企業在
年代末能夠連續幾年保持兩位數的收入增長
但這種方式也帶來了一些負面影響
在 Gary Hamel 所著的 Leading the Revolution（請參閱參考資料）一書中
他聲稱已有一些跡象證明傳統企業模式的優勢已不那麼明顯
我們必須找到一些替代方法來為收入的持續增長提供動力
他建議唯一能讓公司繼續增長的辦法是進行一次徹底的創新
我們認為在軟件開發領域中尤其需要這樣
企業問題
如果使用標准軟件開發方法
那麼即使在 Java 平台上進行開發
也要做好失望的准備
如圖
所示
最近的研究表明
有一半項目將滯後
而三分之一的項目將超過預算
這一推測比
年由美國總審計局的研究結果好不了多少
圖
軟件項目成功和失敗
過去和現在
如果我們希望這些數字有顯著提高
則需要徹底創新的方法來開發軟件
有兩個主要因素影響現有的方法
懼怕失敗
對軟件本質的誤解
沒有人打算失敗
具有諷刺意味的是為使失敗最小化而創建的方法是失敗的
對軟件的誤解是問題的根源
恐懼實際上只是一種症狀
現有的方法是由那些有良好願望但忘記了軟件中的
軟
的那些聰明人所創建的
他們假定開發軟件就象造橋
因此他們從各種設計規范中借鑒了一些適用於
硬
物體（例如橋梁）的最優方法
結果是基於 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 的核心價值（請參閱參考資料）
我們對它們進行了總結
交流 項目的問題往往可以追溯到某人在某個時刻沒有和其他人一起商量某些重要問題上
使用 XP
不交流是不可能的事
簡單 XP 建議您總是盡可能圍繞過程和編寫代碼做最簡單的事情
按照 Beck 的說法
XP 就是打賭
它打賭今天最好做些簡單的事
而不是做更復雜但可能永遠也不會用到的事
反饋 更早和經常來自客戶
團隊和實際最終用戶的具體反饋意見為您提供更多的機會來調整您的力量
反饋可以讓您把握住正確的方向
少走彎路
勇氣 勇氣存在於其它三個價值的環境中
它們相互支持
需要勇氣來相信一路上具體反饋比預先知道每樣事物來得更好
需要勇氣來在可能暴露您的無知時與團隊中其他人交流
需要勇氣來使系統盡可能簡單
將明天的決定推到明天做
而如果沒有簡單的系統
沒有不斷的交流來擴展知識
沒有掌握方向所依賴的反饋
勇氣也就失去了依靠
XP 的方法將這些價值轉換成開發人員每天應做的事情
這裡沒什麼新鮮內容
多年以來
行業認識到 XP 方法是
最優方法
實際上
XP 中的
極端
來自兩方面
XP 采取經過證明的業界最優方法並將其發揮到極致
XP 將這些方法以某種方式進行結合
使它們產生的結果大於各部分的總和
這是怎樣的情景呢？代碼復查是個好的做法
因此始終通過成對地編寫代碼來做到
測試也是個好的做法
因此總是通過在編寫代碼之前編寫測試來做到
文檔很少與代碼保持一致
因此只做那些最需要的事
余下的部分則取決於明確編寫的代碼和測試
XP 不保證人們總做正確的事
但它允許人們這樣做
它將這些
極端
方法以一種相互支持的方式結合起來
顯著提高了速度和有效性
XP 的十二種方法
XP 的十二種方法（如圖
所示）將其定義為規則
讓我們仔細研究每一個方法來對
執行 XP
表示什麼有個更全面的理解
圖
XP 的十二種方法
規劃策略
有些人會指責 XP 是一種美其名的剽竊
只是一群牛仔在沒有任何規則的情況下將一個系統拼湊在一起
錯
XP 是為數不多的幾種承認您在開始時不可能事事通曉的方法之一
無論是用戶還是開發人員都是隨著項目的進展過程才逐步了解事物的
只有鼓勵和信奉這種更改的方法才是有效方法
狀態限定方法忽視更改
而 XP 則留心更改
它傾聽所用的方法就是
規劃策略
一個由 Kent Beck 創造的概念
這一方法背後的主要思想是迅速地制定粗略計劃
然後隨著事物的不斷清晰來逐步完善
規劃策略的產物包括
一堆索引卡
每一張都包含一個客戶素材
這些素材驅動項目的迭代
以及對下一兩個發行版的粗略計劃
如 Kent Beck 和 Martin Fowler 在他們的 Planning Extreme Programming 中描述的那樣（請參閱參考資料）
讓這種形式的計劃得以發揮作用的關鍵因素是讓用戶做企業決策
讓開發小組做技術決策
如果沒有這一前提
整個過程就會土崩瓦解
開發小組要決定
估計開發一個素材要花多長時間
使用各種技術選項所花費的成本
團隊組織
每個素材的
風險
迭代中素材開發的順序（先開發風險最大的那一個可以減輕風險）
客戶需要決定
范圍（一個發行版的素材和每一次迭代的素材）
發行日期
優先級（根據企業價值先開發哪些特性）
規劃經常發生
這樣
在客戶或開發人員學習新事物的同時
就為他們調整計劃提供了頻繁機會
成對編程
使用 XP
成對的開發人員編寫所有產品代碼
這種方式聽上去好象缺乏效率
Martin Fowler 說
當人們說成對編程降低生產力時
我回答
那是因為大多數耗費時間的編程部分是靠輸入來完成的
實際上
成對編程無論在經濟還是其它方面都提供了許多好處
所有設計決策都牽涉到至少兩個人
至少有兩個人熟悉系統的每一部分
幾乎不可能出現兩個人同時疏忽測試或其它任務
改變各對的組合在可以在團隊范圍內傳播知識
代碼總是由至少一人復查
研究還顯示成對的編程實際上比單獨編程更有效（有關詳細信息
請參閱參考資料中 Alistair Cockburn 和 Laurie Williams 所著的 The Costs and Benefits of Pair Programming）
測試
在 XP 中有兩種測試
單元測試
驗收測試
開發人員在他們編寫代碼的同時編寫單元測試
客戶在他們定義了素材後編寫驗收測試
單元測試及時告訴開發人員系統在某一點上是否
工作
驗收測試告訴團隊系統是否執行用戶希望它執行的操作
假設團隊使用的是如 Java 這樣的面向對象語言
開發人員在為一些方法編寫代碼之前為每種有可能失敗的方法編寫單元測試
然後他們編寫足夠的代碼使之能通過測試
有時人們會發現這有點奇怪
答案很簡單
編寫測試首先為您提供
一組可能最完整的測試
可能能工作的最簡單的代碼
代碼意圖的明確景象
開發人員只有在通過所有單元測試後才可以將代碼檢入到源代碼資源庫中
單元測試使開發人員有信心相信他們的代碼能夠工作
這為其他開發人員留下線索
可以幫助他們理解最早的開發人員的意圖（實際上
這是我們看到過的最好的文檔）
單元測試還給了開發人員勇氣重新劃分代碼
因為測試失敗可以立刻告訴開發人員存在錯誤
應該將單元測試自動化
並提供明確的通過／失敗結果
xUnit 框架（請參閱參考資料）做到的遠不止這些
因此大多數 XP 小組都使用它們
用戶負責確保每個素材都有驗收測試來確認它們
用戶可以自己編寫測試
可以征募組織中的其他成員（例如 QA 人員或業務分析員）編寫它們
也可以將這兩種方法結合起來
測試告訴他們系統是否具有應該具有的那些特性
以及是否可以正確工作
理想情況下
用戶在迭代完成之前就應該寫好迭代中那些素材的驗收測試了
應該將驗收測試自動化
並要經常運行來確保開發人員在實現新特性時沒有破壞任何現有的特性
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/19368.html
