第Ⅰ部分 敏捷開發 第2章 極限編程概述

作爲開發人員，我們應該記住，XP並非唯一選擇。——Pete MaBreen
★2.1極限編程實踐
極限編程(eXtreme Programming)是敏捷方法中著名的一個。由一系列相互依賴的實踐組成。

★2.1.1客戶作爲團隊成員
XP中客戶的定義：定義產品特性並排列這些特性優先級的人或團體。可能是統一家公司的業務分析師和市場專家，或者用戶團體代表，或者支付開發費用的人。
客戶與開發人員越近，就越容易融合到團隊中。

★2.1.2用戶素材
關於需求的特定細節：
爲了進行項目記錄，瞭解項目需求，但不要太多，能夠做記錄即可。
需求的特定細節會隨着時間的改變而改變，特別是看到集成到一起的系統時，因此過早的捕獲細節會導致無用功；
XP中與客戶反覆討論獲取對需求細節的理解，但不捕獲那些細節，用簡短的詞語進行記錄，記錄是爲了幫助彙集，開發人員在記錄邊標明估算。
用戶素材(user stories)：關於需求談話的助記符，是計劃工具，客戶根據優先級和實現代價安排該需求的實現時間。

★2.1.3短交付週期
每兩週交付可工作軟件，實現涉衆需求，並演示，得到反饋。
開發人員通過以前迭代中完成的工作量，爲本次迭代設定預算。
計劃分爲：
迭代計劃：2周的計劃。
發佈計劃：6個迭代計劃。

★2.1.4驗收測試
驗收測試在實現該用戶素材之前或同時完成。
驗收測試使用能夠讓他們自動並且反覆運行的腳本語言編寫。可以由開發人員或QA部門編寫。
不斷增長的驗收測試每天都被多次運行。
★SLS：以前我對JUNIT之類的單元測試工具總是搞不懂有什麼太大的用處，直到最近我對產品質量非常重視時，才意識到自動執行的單元測試的重要性。爲 了保證產品質量，首先我們要準備非常多的測試用例，理想的狀態是這些測試用例，涵蓋用戶實際使用的所有情況，所以，用例庫會是非常龐大的。以前都是測試人 員直接操作用戶界面，發現bug。這樣做本身效率比較低。但問題是每個產品版本的發佈、每次bug修改、或代碼改動、功能增加、效率優化都應該執行一遍所 有的用例庫，以確保質量，沒有衍生錯誤。頻繁發佈版本的時候，手工測試顯然效率太低。這時使用自動單元測試就會極大的提高測試效率，無論測試用例多麼龐 大，都不用擔心了。這也是爲什麼struts2好於struts1的原因，因爲struts2是獨立於容器的，可以進行自動單元測試。struts1就無 法實現這個功能。

★2.1.5結對編程
一個人控制鍵盤編碼，另一個觀察者尋找代碼中的錯誤和可以改進的地方。
好處：提高效率，減少缺陷率；極大地促進知識在團隊中的傳播

★2.1.6測試驅動的開發方法
編寫所有產品的目的是爲了通過單元測試。
測試用例和代碼同時的不斷的發展。
爲了使單元測試通過，解耦就成爲必然的選擇。

★2.1.7集體所有權
沒有程序員對任何一個特定的模塊或技術單獨負責。

★2.1.8持續集成
每個程序員都會持續的chech in、check out。

★2.1.9可持續的開發速度
軟件項目不是短跑，是馬拉松。團隊必須有意識的保持穩定適中的速度。
XP規則不允許加班，在版本發佈前1周時例外。因爲目標就在眼前，允許一蹴而就。

★2.1.10開放的工作空間
牆上掛滿狀態圖標、任務明細、UML圖。
在充滿積極討論的屋子裏，生產率非但不會降低，反而會成倍提高。

★2.1.11計劃遊戲
計劃遊戲(planning game)的本質是劃分業務人員和開發人員的職責。業務人員（也就是客戶）決定特性(feature)，開發人員決定實現這一特性花費的成本。
每次迭代計劃或發佈計劃開始，開發人員基於最近一次的工作量，爲客戶提供預算。客戶選擇那些所需的成本合計不超過預算的用戶素材。
這樣客戶很快會了解項目進度，以及成本。

★2.1.12簡單的設計
XP團隊使設計儘可能的簡單、具有表現力。他們不會考慮未來的用戶素材。這意味着在一開始可能並不適用數據庫或中間件，只有某個用戶素材需要基礎結構時，纔會被引入。
下列XP原則對開發人員進行指導：
1.考慮能夠工作的最簡單的事情。
XP團隊總是尋找能夠實現當前用戶素材的最簡單的設計。
平面文件對數據庫或EJB；socket連接對ORB或RMI；多線程對單線程。

2.你將不需要它。
只有有證據表明，現在引入基礎結構比過一段時間引入跟合算時才提前引入基礎結構。
★SLS：這與我的調優原則一樣，只有當我們可以肯定某一瓶頸肯定發生，或已經發生時才進行調優，而不是在不確定問題是否可定發生時，就解決問題。

3.一次，並且只有一次。
極限編程不允許重複的代碼。
導致重複的因素很多，對常見的是複製粘貼。
消除重複代碼的方法有，定義函數或基類或者使用TEMPLATE METHOD。
消除重複最好的方法就是抽象。

★2.1.13重構
隨着添加一個有一個特性，處理一個有一個錯誤，代碼結構會腐化，不過置之不理，會導致糾結不清，難於維護的代碼。
重構就是在不改變代碼行爲的前提下，對其進行一系列小的改造，旨在改進系統結構的一系列活動。
每次改造後就運行單元測試以確保沒有造成任何破壞。從而保證系統可工作。
重構是持續進行的，1個小時半個小時一次，是持續的。

★2.1.14隱喻
隱喻(metaphor)是整個系統的聯繫在一起的全局視圖，是未來的景象，是它使得所有單獨模塊的位置和外觀變得明顯直觀。
隱喻通常可以歸結爲一系列具有象徵意義的名字，這些名字提供一個系統組成元素的詞彙表，並有助於定義他們之間的關係。

★2.2結論
極限編程是一組簡單、具體的實踐，這些實踐結合在一起形成敏捷開發過程。是一種通用、優良的軟件開發方法。
項目團隊可以直接採用，可以可以增加實踐，或者對實踐進行修改後採用。