【文章內容簡介】 Coach Pair 文檔 Spike 其它 價值觀 勇氣 簡單 交流 開發(fā)開發(fā) 集成測試 PairPramming 單元 測試 持續(xù)集成 驗收測試 迭代 小規(guī)模發(fā)布 產品品 計劃 評估 Onsite Customers 調控 風險 時間 價值 CRC 質量 持續(xù)集成 開發(fā) 輕量極 開發(fā)環(huán)境 簡單 需求 OnSite Customers 項目 計劃 其它 價值觀 勇氣 反饋 交流 系統(tǒng) Simple Design Refactoring 做最簡單的事情 讓系統(tǒng)運行 System Metaphor 9 （七 ） XP 的十二 條規(guī)則 重構（ Refactoring） 重構是 對已經完成的代碼進行改進的過程。在不對代碼的外部行為進行改動的情況下，對代碼內部的結構進行優(yōu)化。 重構讓您將學到的知識加入到代碼中，同時又不會破壞測試。它使您的代碼簡練。這意味著它可以存在相當長的時間為 以后的開發(fā)人員引入更少問題，并為他們指引正確的方向。 ?在 Metaphor 指引下的重構，是為商業(yè)模型服務的。不要把重構變成 不斷的盲目精簡代碼。 ?重構和編程前的計劃型設計 (Planned Design)結合，使 XP 的簡單設計可行有效。 ?XP 提倡毫不留情的重構 (Refactor mercilessly)。 ?任何人可 重構任何代碼，前提是重構后的代碼要通過 100%的測試之 后才能 被 Checkin。 ?可以根據(jù)需要，將一個迭代的全部目標定為重構。 ?不要太在意什么是最簡單的設計 ,愿意在最后重構，比知道如何做簡單的設計重要得多。 ?XP 建議您應該編寫可能運行的最簡單的代碼，但同時也建議您應該不斷學習。 開發(fā)人員重構有兩個重要時機：實 現(xiàn)特性之前和之后。開發(fā)人員嘗試確定更改現(xiàn)有代碼是否可以讓 新特性的開發(fā)更容易。他們查看剛剛寫好的代碼，看是否有方法可以對它進行簡化。例如，如果他們認為有抽象的機會，就會進行重構來從具體實現(xiàn)中除去重復的代碼 現(xiàn)場客戶 (OnSite Customer) 要使功能最理想， XP 小組需要在現(xiàn)場有一位客戶來明確素材，并做出重要的企業(yè)決策。開發(fā)人員是不 許單獨做這些事情的。讓客戶隨時在場可 以 消除開發(fā)人員等待決策時出現(xiàn)的瓶頸。 客戶是 Team 成員，在開發(fā)現(xiàn)場和開發(fā)人員一起工作。 傳統(tǒng)的客戶任務一般是講解需求，運行驗收測試 ，接收發(fā)布的系統(tǒng)。 XP 新增加的任務： * 寫 User Story * 評估 User Story 的商業(yè)優(yōu)先級 * 為每個 User Story 定義驗收測試 * 計劃開發(fā)內容 * 調控開發(fā)過程 建立商業(yè)模型，把隱藏在客戶需求下的原則傳授給開發(fā)人員： * 程序員理解的是表象，而 不是本質； * 程序員分擔任務的過程支解了對他們商業(yè)模型的理解； * 某些開發(fā)外包或分階測試 重構 勇氣 Team 集體 擁有代 碼 合作 統(tǒng)一 規(guī)范 其它 價值觀 反饋 簡單 交流 態(tài)度 自信 品質 好勝 驕傲 迭代 計劃 開發(fā) 編程 配置 管理 Simple Design 取舍 10 段開發(fā) (例如增量、迭代等 )導致 “ 知識泄露 ” 。 參加設計過程 ： * 和程序員一起找出 Metaphor，引 導 設計方向； * 在 Metaphor 的幫助下，定義更 有效更實際的功能測試，給程序員的設計制定了規(guī)范； * CRC 卡鼓勵客戶更多地參加設計過程。 我們發(fā)現(xiàn)讓客戶在現(xiàn)場可能 是 最好的一種情形，但這不是解決問題的唯一方案。底線是客戶必須隨時在需要回答問題和根據(jù)企業(yè)價值為團隊提供指示時有空。如果客戶并非在現(xiàn)場專職陪伴團隊的情況下就能做到這些，那很好。如果能和團隊 呆 在一起，這會更方便，但只是建議而已。 系統(tǒng) 隱 喻 (Metaphor) 體系結構是做什么用的？它提供了系統(tǒng)各種組件以及它們是如何交互 畫面 ，可以讓開發(fā)人員了解新的代碼部分適合放在哪里。 XP 中的系統(tǒng) 隱 喻 與大多數(shù)方法稱作的體系結構差不多。 隱 喻為團隊提供了一致的畫面，他們可以用它來描述現(xiàn)有系統(tǒng)的工作方式、新部件適合的位置，以及它們應該采取的形式。 “The system metaphor is a story that everyone customers, programmers, and managers can tell about how the system works.” — Kent Beck Team 將 Domain/SubDomain Model， Design/SubDesign Model 以及一些關鍵概念等等抽象化為比喻。通過這些比喻，加強客戶和程序員之間的相互理解，消化積累知識，指導設計開發(fā)的方向。 例： ?Market — 發(fā)布 /瀏覽，價格洽談，生成和履行合同； ?電影后期制作 — 郵遞 — 電影院播放電影。 ?Metaphor 的形成過程，是客戶建立并抽象商業(yè)模型和商業(yè)概念的過程，是程序員建立并抽象設計模型和設計概念的過程。 ?Metaphor 使客戶和程序員用共通的模型和語言進行交流 — “One Team, one language” 。 ?Metaphor 可以 幫助減少 “ 知識泄露 ” 和 “ 支解知識 ” 。 ?Metaphor 是設計過程的航標 —— 真正靈活有效的設計是針對商業(yè)原則的設計，而不是針對商業(yè)原則表現(xiàn)形式的設計，更不是脫離商業(yè)需求目的的學術設計。 ?隨著開發(fā)的繼續(xù)， Team 會找到更好的 Metaphor。這是知識細化、深化的結果，是 “ 持續(xù)學習 ”(Continuous learning) 的過程；是對商業(yè)模型和設計模型的持續(xù)重構。 簡單設計 (Simple Design) XP 的誹謗者說該過程忽略了設計。事實不是這樣。問題是重量型方法建議您做的不過是提前完成大部分瑣 碎的設計任務。這就象是拍一張靜態(tài)的地平線的照片，靜止不動，然后嘗試畫一張如何到達那里的完美的地圖。 XP 說設計不應該在事物保持不變的前提下預先倉促進行。 XP 認為設計非常重要，因此應該是一個持續(xù)的事務。我們總是先嘗試使用能夠工作的最簡單的設計，然后隨著現(xiàn)實的不斷顯現(xiàn)來更改它。 簡單設計 —— Do the simplest thing that could possibly work； You aren’t going to need it(YAGNI)。 簡單設計是符合以下條件的設計： * 運行所有測試 * 不包含重復代碼 * 明確陳述程序員對所有代碼的意圖 * 包含盡可能最少的類和方法 對簡單設計的需求并不是說所有設計都很小，也不表示它們是無足輕重的。它們只不 過需要盡可能簡單，但是仍能工 作。不要包括不使用的額外特性 ,我們稱這樣的事物為 YAGNI 11 （ You Aren39。t Going to Need It 您將不需要它）。不要讓 YAGNI 破 壞您成功的機會。 結 對編程 (Pair Programming) 風險會使大多數(shù)團隊停滯不前 ， 減少風險的最佳方法是確保團隊中的每個人都完全熟悉系統(tǒng) 的所有部件以及對系統(tǒng)的所有更改。技術講解和設計文檔很有用，但對于大多數(shù)快節(jié)奏的項目，它們并不能很好且迅速地傳播知識。傳播知識最有效的方法是讓一個知道代碼的人與不知道代碼的人一起解決問題。 結 對 是兩個人一起解決同一個編程問題。使用 XP， 結 對的開發(fā)人員編寫所有產品代碼 。 這種方式聽上去好象缺乏效率。 Martin Fowler 說 ：“ 當人們說 結 對編程降低生產力時 ，我回答， ‘ 那是因為大多數(shù)耗費時間的編程部分是靠輸入來完成的 ’”。 實際上， 結 對編程無論在經濟還是其它方面都提供了許多好處： * 鼓勵團隊 * 提高生產力 * 減少風險 * 使團隊生產效率更高 * 生成更好的代碼 * 促使知識的傳播 結對 是經理和團隊減少風險并防止因更改而毀掉團隊必須運用的最好的工具之一。當團隊成員結對時，所有設計決策和代碼更改都至少由兩個人完成。通過讓程序員結對，經理確保了更多人熟悉代碼以及它經歷的更改。此外，兩個人編寫的代碼總比一個人寫的代碼好。兩個人的智慧確實勝過一個人的，對于影響整個系統(tǒng)的設計決策更是如此。研究顯示 結 對編程確實 比單獨編程更有效。 一周 40 小時 (40hour week) Kent Beck 說 ：“ 他希望每天早晨都感到有活力有激情，每天晚上都感到疲憊而滿足 ” 。一周 40 小時工作可以讓您做到 這一點。確切的小時數(shù)并不重要，重要的是原則。長時間地持續(xù)工作會扼殺工作績效。疲勞的開發(fā) 人員會犯更多錯誤，從長期來說，將比按正常時間表進行的開發(fā)慢得多 。 一周 只 工作 40 小時 ， 體現(xiàn)了 XP 以人為本的價值觀。 它 保證了程序員可以持續(xù)地完成任務。 即使開發(fā)人員可以在長時間很好工作，這也不意味著他們應該這樣。最終他們會厭倦，會離開他們的工作，或者產生影響他們工作績效的非工作問題。如果您打亂了人們的生活，將會嘗到它所帶來的 惡果。加班并不是解決項目問題的答案。實際上， 加班多導致開發(fā)效率和質量下降，簡潔增加了開發(fā)成本， 它是更大問題的癥狀。 編碼標準 (Coding Standards) XP 中的 編碼標準 規(guī)定了 程序的風格，包括注釋如何寫，變量命名的規(guī)范，代碼的格式等， 它是 Teamwork 的前提之一，是其它眾多慣例和規(guī)則的前提之一。 擁有編碼標準有兩個目的： * 防止團隊被一些例如事物沒有以最大速度發(fā)展這種無關緊要的愚蠢爭論搞得不知所措 * 它 可以 支持其它方法。 如果沒有編碼標準，重新劃分代碼會更加困難，按應當?shù)念l度 交換對更困難，快速前進也更困難。目標應該是團隊中沒有人辨認得出是誰寫的哪一部分代碼。以團隊為單位對某一標準達成協(xié)議，然后遵守這一標準。目標不是創(chuàng)建一個事無巨細的規(guī)則列表，而是提供將確保您的代碼可以清晰交流的指導方針。編碼標準開始時應該很簡單，然后根據(jù)團隊經驗逐步進化。不要預先花費太多時間。創(chuàng)建能夠工作的最簡單標準，然后逐步發(fā)展。 持續(xù)集成 (Continuous Integration) 經常進行代碼集成可以幫助您避免集成夢魘。 XP 團隊在一天中集成代碼幾次，每次都在所有單元測試對系統(tǒng)運行后執(zhí)行。 持續(xù)集成是指不斷地把完成的功能模塊整合在一起。目的在于不斷獲得客戶反饋以及盡早發(fā)現(xiàn) BUG。 傳統(tǒng)方法工作方式如下：編寫大量代碼后執(zhí)行一次大爆炸式的集成，然后花費相當長的時 12 間來改正問題。這種笨拙的形式的確使項目速度減緩。大爆炸式的集成 立即 給團隊帶來大量的 問題，并且這些問題通常都有幾百種可能的原因。 如果經常 集成，任何特定集成失敗的原因都會非常明顯（以前運行過測試，因此錯誤一定是新事物犯下的）。使用這種方法，當遇到問題時，可能的原因就相當有限。修改起來更容易，花的時間少得多，使團隊保持最快速度 。 規(guī)劃 策略 (Planning Game) 有些人 指責 “ XP 是一種美其名的剽竊， 是一群牛仔在沒有任何規(guī)則的情況下將一個系統(tǒng)拼湊在一起 ” 。錯。 XP 是為數(shù)不多的幾種承認您在開始時不可能事事通曉的方法之一。無論是用戶還是開發(fā)人員都是隨著項目的進展過程才逐步了解事物的。只 有鼓勵和信奉這種更改的方法才是有效 的 方法。 XP 留心更改 ， 它傾聽所用的方法 。它是 一個由 Kent Beck 創(chuàng)造的概念。 這一方法背后的主要思想是迅速地制定粗略計劃，然后隨著事物的不斷清晰來逐步完善。規(guī)劃策略的產物包括：一堆索引卡，每一張都包含一個 客戶 素材，這些素材驅動項目的迭代；以及對下一兩個發(fā)行版的粗略計劃 ， 讓這種形式的計劃得以發(fā)揮作用的關鍵因素是讓用戶做企業(yè)決策，讓開發(fā)小組做技術決策。如果沒有這一前提，整個過程就會土崩瓦解。 開發(fā)小組要決定： * 估計開發(fā)一個素材要花多長時間 * 使用各種技術選項所花費的成本 * 團隊組織 * 每個素材的 “ 風險 ” * 迭代中素材開發(fā)的順序（先開發(fā)風險最大的那一個可以減輕風險） 客戶需要決定： * 范圍（一個發(fā)行版的素材和每一次迭代的素材） * 發(fā)行日期 * 優(yōu)先級（根據(jù)企業(yè)價值先開發(fā)哪些特性） 規(guī)劃經 常發(fā)生。這樣，在客戶或開發(fā)人員學習新事物的同時，就為他們調整計劃提供了頻繁機會。 小發(fā)行版 (Small Releases) 不斷地發(fā)布可用的系統(tǒng)可以告訴客戶你在做正確的事情?？蛻羰褂冒l(fā)布的系統(tǒng)，可以保證 頻繁地反饋和交流。 發(fā)行版應該盡可能地小，同時仍然提供足夠的企業(yè)價值以證明它們值得。 發(fā)布過程應該盡可能地自動化