久久夜色精品国产亚洲av,久久久久亚洲AV成人无码网站,久久久亚洲精品蜜桃臀

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

1 為什么是XP

讓我們來考慮一個傳統(tǒng)的途徑：用戶組和開發(fā)組協(xié)商讓一個分析員設計一個項目。在幾周和幾個月中，分析員和用戶每天會面幾個小時。分析員生產(chǎn)出一套文檔，可能還包括象一個可視描述和用例之類。用戶和項目經(jīng)理（也可能是編程團隊）回顧這些文檔并且協(xié)商出一個發(fā)行版。程序員使用規(guī)范在幾個月之后成長出一個系統(tǒng)，或多或少的實現(xiàn)了原來的想法。在結束的時候這通常是一個閉呼叫系統(tǒng)，當人們發(fā)現(xiàn)他們所遺漏的并意識到自從文檔被寫好以來什么都已經(jīng)改變了。最后，用戶加入進來作一個用戶接受測試然后系統(tǒng)被發(fā)布。

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

問題總結：
不能完全理解用戶需求（用戶自己也經(jīng)常不清楚自己需要什么）
用戶的要求不斷變化
技術更新速度很快
開發(fā)人員缺乏成功經(jīng)驗
開發(fā)小組不穩(wěn)定
沒有完整的測試設計

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

2 XP簡介

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

2.1 用戶決定：

范圍：什么系統(tǒng)是必須作的。

優(yōu)先級：對于企業(yè)價值什么是最重要的。

發(fā)行的組合：什么是必須在發(fā)行版中的，一定是有用的？

發(fā)行的日期：什么時候需要發(fā)行？

2.2 程序員決定：

評估添加一個特征的時間，以及每個特征的風險

使用各種技術選項所花費的成本：程序員解釋程序選擇的結果，但是用戶作決定

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

細節(jié)時間表：在一個迭代中特征先開發(fā)風險最大的那一個特征可以減輕風險

2.3 XP 的核心價值為：

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

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

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

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

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

3 XP的十二種實踐方法：

重新劃分（Refactoring）

系統(tǒng)比喻(Metaphor)

簡單設計(Simple design)

一周40小時 (40-hour week)

編碼標準(Coding standards)

持續(xù)集成(Continuous integration)

成對編程(pair programming)

集體代碼所有權(Collective ownership)

現(xiàn)場客戶(On-site customer)

規(guī)劃策略(Planning game)

小發(fā)行版(Small releases)

測試(Testing)

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

3.2 系統(tǒng)比喻
體系結構是做什么用的？它提供了系統(tǒng)各種組件以及它們是如何交互的畫面 -- 一種映射，可以讓開發(fā)人員了解新的代碼部分適合放在哪里。
XP 中的系統(tǒng)比喻與大多數(shù)方法稱作的體系結構差不多。比喻為團隊提供了一致的畫面，他們可以用它來描述現(xiàn)有系統(tǒng)的工作方式、新部件適合的位置，以及它們應該采取的形式。
重要的是要記住，關鍵要讓每個人理解系統(tǒng)是如何組合在一起的，而不是美麗的比喻。有時您就是無法想到一個好的比喻。想到時就太好了。　

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

一組可能最完整的測試

可能能工作的最簡單的代碼

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

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

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

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

至少有兩個人熟悉系統(tǒng)的每一部分。

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

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

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

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

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

運行所有測試

不包含重復代碼

明確陳述程序員對所有代碼的意圖

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

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

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

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

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

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

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

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

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

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

4 XP過程中的各個階段

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

4.1 計劃

User stories的編寫

識別需求方面

開發(fā)計劃的制定

經(jīng)常構造版本

版本控制

Load Factor因子的確定

將項目分解為各個迭代期

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

人員集中

站著開每日晨會

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

4.2 測試

所有代碼均需進行單元測試

發(fā)行之前所有代碼必須通過單元測試

Bug發(fā)現(xiàn)后應馬上測試　

4.3 編碼

始終獲得用戶的支持

代碼的書寫必須按照規(guī)范

所有代碼均采用配對開發(fā)

一次只能有一對開發(fā)人員進行發(fā)行

代碼經(jīng)常集成

代碼共享

將優(yōu)化放在最后

不要加班

4.4 設計

簡單化
采用編程規(guī)范
設計時使用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 閱讀(915) 評論(0) 編輯收藏所屬分類: XP極限編程體驗

新用戶注冊刷新評論列表


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




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

朋的博客

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

導航

常用鏈接

隨筆分類(78)

隨筆檔案(84)

文章分類(59)

文章檔案(59)

搜索

積分與排名

最新評論

閱讀排行榜