第02章-極限編程概述

第二章極限編程概述AsdevelopersweneedtorememberthatXPisnottheonlygameintown.2.1極限編程實踐2.1.1完整團隊我們希望客戶、管理者和開發(fā)人員緊密地工作在一起，以便彼此知曉對方所面臨的問題，并共同去解決這些問題。XP團隊中的客戶是指定義產(chǎn)品的特性并排列這些特性優(yōu)先級的人或者團體。最好的情況是客戶和開發(fā)人員在同一個房間中工作，次一點的情況是客戶和開發(fā)人員之間的距離在100米內(nèi)。如果確實無法和客戶在一起工作，那么就去尋找能夠在一起工作、愿意并能夠代替真正客戶的人。2.1極限編程實踐2.1.2用戶故事為了進行項目計劃，必須要知道和項目需求有關的內(nèi)容，但是卻無須知道得太多。對于做計劃而言，了解需求只需要做到能夠估算它的程度就足夠了。需求的特定細節(jié)很可能會隨實踐而改變。因此，在離真正實現(xiàn)需求還很早的時候就去捕獲該需求的特定細節(jié)，很可能會導致做無用功以及對需求不成熟的關注。用戶故事--就是正在進行的關于需求談話的助記符。它是一個計劃工具，客戶可以使用它并根據(jù)它的優(yōu)先級和估算代價來安排實現(xiàn)該需求的實踐。2.1極限編程實踐2.1.3短交付周期XP項目每兩周交付一次可以工作的軟件。每兩周的迭代都實現(xiàn)了利益相關者的一些需求，在每次迭代結束時，會給利益相關者演示迭代生成的系統(tǒng)，以得到他們的反饋。迭代計劃：每次迭代通常耗時兩周。迭代是一次較小的交付，可能會被加入到產(chǎn)品中，也可能不會。它由客戶根據(jù)開發(fā)人員確定的預算而選擇一些用戶故事組成；一旦迭代開始，客戶就統(tǒng)一不再修改當次迭代中用戶素材的定義和優(yōu)先級別；迭代期間，開發(fā)人員可以自由地將用戶素材分解成為任務（task），并根據(jù)最具技術和商務意義的順序來開發(fā)這些任務。2.1極限編程實踐2.1.3短交付周期（續(xù)）發(fā)布計劃：XP團隊通常會創(chuàng)建一個計劃來規(guī)劃隨后大約6次迭代的內(nèi)容。一次發(fā)布通常需要3個月的工作。它表示了一次較大的交付，通常此次交付會被加入到產(chǎn)品中。發(fā)布計劃是由一組客戶根據(jù)開發(fā)人員給出的預算所選擇的、排好優(yōu)先級別的用戶故事組成。發(fā)布計劃不是一成不變的，客戶可以隨時改變計劃的內(nèi)容，他可以取消用戶素材，編寫新的用戶素材，或者改變用戶素材的優(yōu)先級別。但是客戶應該更改后面迭代的內(nèi)容，盡量不要更改下一次迭代。2.1極限編程實踐2.1.4驗收測試可以以客戶指定的驗收測試（AcceptanceTests）的形式來記錄有關用戶故事的細節(jié)。用戶故事的驗收測試是在就要實現(xiàn)該用戶故事之前或實現(xiàn)該用戶故事的同時進行編寫的。驗收測試使用能夠讓它們自動并且反復運行的某種腳本語言編寫，這些測試共同來驗證系統(tǒng)按照客戶指定的行為運轉。驗收測是由業(yè)務分析師、質(zhì)量保證專家以及測試人員在迭代期間編寫的，這些測試成為真正的項目需求文檔一旦通過一項驗收測試，那么就加入到已通過的驗收測試集中，并決不允許該測試再次失敗。2.1極限編程實踐2.1.5結對編程—不會降低編程效率，反而會大大減少缺陷率所有產(chǎn)品（production）代碼都是由結對的程序員使用同一臺電腦共同完成的。結對人員中的一位控制鍵盤并輸入代碼，另一位觀察輸入的代碼并尋找著代碼中的錯誤和可以改進的地方。結對編程的代碼是由兩人共同設計、共同編寫的，兩人功勞均等。結對的關系每天至少改變一次，以便于每個程序員在一天中可以在兩個不同的結對中工作。在一個迭代期間，每個團隊成員應該和所有其他的團隊成員在一起工作過，并且他們應該參與了本次迭代中所涉及的每項工作。這樣可以促進知識在團隊中的傳播?！皩＜摇币残枰c團隊中的其他成員結對。2.1極限編程實踐2.1.6測試驅動開發(fā)編寫所有產(chǎn)品代碼的目的都是為了使失敗的單元測試能夠通過。首先編寫一個單元測試，由于它要測試的功能還不存在，因此它會運行失敗，然后，編寫代碼使測試通過。編寫測試用例和代碼之間的更迭速度是很快的，基本上在幾分鐘左右。這樣的方式非常利于重構。這樣一種方式可以激發(fā)程序員去解除各個模塊之間的耦合，這樣能夠獨立地對它們進行測試。面向對象設計的原則在進行這種解除耦合方面具有巨大的幫助作用。2.1極限編程實踐2.1.7

集體所有結對編程中的每一對都具有簽出（checkout）任何模塊并對它進行改進的權力。沒有程序員對任何一個特定的模塊或技術單獨負責，每個人都參與GUI方面的工作；每個人都參與中間件方面的工作；每個人都參與數(shù)據(jù)庫方面的工作。沒有人比其他人在一個模塊或者技術上具有更多的權威。任何人都可以多從事自己擅長的一方面，但是不會被限制在自己的專業(yè)領域內(nèi)。2.1極限編程實踐2.1.8持續(xù)集成XP團隊每天會進行多次系統(tǒng)構建，他們會重新創(chuàng)建整個系統(tǒng)。集成時要采用系統(tǒng)最終結果發(fā)布的形式—CD或Web。程序員的模塊在簽入/集成前必須保證模塊已經(jīng)通過所有測試。2.1極限編程實踐2.1.9可持續(xù)的開發(fā)速度軟件項目不是全速短跑，而是馬拉松長跑。XP團隊必須要以一種可持續(xù)的速度前進，必須要有意識地保持穩(wěn)定、適中的速度。XP的規(guī)則是不允許團隊加班工作。在版本發(fā)布前的一個星期是該規(guī)則的惟一例外------如果發(fā)布目標就在眼前并且可以一蹴而就，則允許加班。2.1極限編程實踐2.1.10開放的工作空間開放的房間：桌子/椅子面對面，墻上掛滿了各種圖表；人和人之間的距離必須足夠近，能夠互相聽到對方的談話。密歇根大學的一項研究表明，在“充滿積極討論的屋子（warroom）”里工作，生產(chǎn)率非但不會降低，反而會成倍地提高。2.1極限編程實踐2.1.11計劃游戲計劃游戲（planninggame）的本質(zhì)是劃分業(yè)務人員和開發(fā)人員之間的職責。業(yè)務人員（客戶）決定特性（feature）的重要性，開發(fā)人員決定實現(xiàn)一個特性所花費的代價。在每次發(fā)布和每次迭代的開始，開發(fā)人員基于在最近一次迭代或者最近一次發(fā)布中他們所完成的工作量，為客戶提供一個“預算”。客戶選擇那些所需的成本合計起來不超過該預算的用戶素材。在短周期迭代和頻繁的發(fā)布過程中，客戶和開發(fā)人員會逐步精確掌握系統(tǒng)的進度情況。2.1極限編程實踐2.1.12簡單設計XP團隊使他們的設計盡可能地簡單、具有表現(xiàn)力（expressive）。此外，他們僅僅關注于計劃在本次迭代中要完成的用戶素材。他們不會考慮那些未來的用戶素材。這意味著XP團隊的工作可能不會從基礎結構開始，只有當出現(xiàn)一個用戶素材迫切需要基礎結構時，他們才會引入該基礎結構。3條XP指導原則：(1)考慮能工作的最簡單的事情盡量考慮最簡單的方法實現(xiàn)當前的用戶故事。2.1極限編程實踐2.1.12簡單設計3條XP指導原則：(2)你不需要它將來會用到，現(xiàn)在不考慮，不得不用時再添加；(3)一次，并且只有一次極限編程者絕不能容忍重復的代碼代碼重復不僅僅是浪費存儲空間，關鍵是“維護災難”消除重復最好的方法就是抽象。提煉出抽象，可以減少代碼間的耦合。2.1極限編程實踐2.1.13重構不斷修改的代碼往往會退化/腐化，導致難于維護；重構就是在不改變代碼行為的前提下，對其進行一系列小的改造（transformation），旨在改進系統(tǒng)結構的實踐活動。每個改造都是微不足道的，但是這些所有的改造迭加在一起，就形成了對系統(tǒng)設計和架構顯著的改進。每次重構進行完后，必須運行單元測試，保證重構沒有造成任何破壞，然后再去做下一次重構。而且，重構是持續(xù)進行的。2.1極限編程實踐2.1.14隱喻隱喻（metaphore）是所有XP實踐中最難理解的一個。隱喻是將整個系統(tǒng)聯(lián)系在一起的全局視圖（如：智力