亚洲精品午夜国产VA久久成人,亚洲精品福利视频,国产亚洲精品va在线

XP實踐整理(來自：XPChina BrokenDoor )

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 方法
不要過早添加新功能
盡可能保持程序的簡潔性
--------------------------------------------------------------------------------

5 相關資料
Extremeprogramming: http://www.extremeprogramming.org/
XPdeveloper: http://http://www.xpdeveloper.com/
Xprogramming: http://www.xprogramming.com/
Junit: http://www.junit.org/

posted on 2006-02-19 21:04 benchensz 閱讀(914) 評論(0) 編輯收藏所屬分類: XP極限編程體驗

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: 大型項目的XP(極限編程)（來自：UMLCHINA ）何時應該使用極限編程（來自：UML工程組織）配對編程（來自：ZDNet） XP設計原則（來自：xpchina:BrokenDoor） XP實踐整理(來自：XPChina BrokenDoor )

朋的博客

XP實踐整理(來自：XPChina BrokenDoor )

導航

常用鏈接

隨筆分類(78)

隨筆檔案(84)

文章分類(59)

文章檔案(59)

搜索

積分與排名

最新評論

閱讀排行榜