敏捷開發(fā)總結(jié)

1、Intro:簡單的說，敏捷開發(fā)是一種以人為核心、迭代、循序漸進的開發(fā)方法。在敏捷開發(fā)中，軟件項目的構(gòu)建被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。敏捷開發(fā)是由一些業(yè)界專家針對一些企業(yè)現(xiàn)狀提出了一些讓軟件開發(fā)團隊具有快速工作、響應(yīng)變化能力的價值觀和原則，并于2001初成立了敏捷聯(lián)盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發(fā)方法。敏捷開發(fā)(agiledevelopment)概念從2004年初開始廣為流行。Bailar非常支持這一理論，他采取了敏

2、捷方式組建團隊：CapitalOne的敏捷團隊包括3名業(yè)務(wù)人員、兩名操作人員和57名IT人員，其中包括1個業(yè)務(wù)信息指導(dǎo)(實際上是業(yè)務(wù)部門和IT部門之間的翻譯者)；另夕卜，還有一個由項目經(jīng)理和至少80名開發(fā)人員組成的團隊。這些開發(fā)人員都曾被Bailar送去參加過敏捷開發(fā)的培訓(xùn)，具備相關(guān)的技能。每個團隊都有自己的敏捷指導(dǎo)(Bailar聘用了20個敏捷指導(dǎo))，他的工作是關(guān)注流程并提供建議和支持。最初提出的需求被歸納成一個目標、一堆記錄詳細需要的卡片及一些供參考的原型和模板。在整個項目階段，團隊人員密切合作，開發(fā)有規(guī)律地停頓-在9周開發(fā)過程中停頓34次，以評估過程及決定需求變更是否必要。在Capita

3、lOne，大的IT項目會被拆分成多個子項目，安排給各敏捷團隊，這種方式在敏捷開發(fā)中叫蜂巢式(swarming)，所有過程由一名項目經(jīng)理控制。為了檢驗這個系統(tǒng)的效果，Bailar將項目拆分，從舊的瀑布式開發(fā)轉(zhuǎn)變?yōu)椴⒘惺介_發(fā)，形成了敏捷開發(fā)所倡導(dǎo)的精干而靈活的開發(fā)團隊，并將開發(fā)階段分成30天一個周期，進行沖刺-每個沖刺始于一個啟動會議，到下個沖刺前結(jié)束。在Bailar將其與傳統(tǒng)的開發(fā)方式做了對比后，他感到非常興奮一敏捷開發(fā)使開發(fā)時間減少了30%40%，有時甚至接近50%，提高了交付產(chǎn)品的質(zhì)量。不過，有些需求不能用敏捷開發(fā)來處理。Bailar承認，敏捷開發(fā)也有局限性，比如對那些不明確、優(yōu)先權(quán)不清楚的

4、需求或處于較快、較便宜、較優(yōu)的三角架構(gòu)中卻不能排列出三者優(yōu)先級的需求。此夕，他覺得大型項目或有特殊規(guī)則的需求的項目，更適宜采用傳統(tǒng)的開發(fā)方式。盡管描述需求一直是件困難的事，但經(jīng)過陣痛之后，需求處理流程會讓CIO受益匪淺。敏捷開發(fā)是由一些業(yè)界專家針對一些企業(yè)現(xiàn)狀提出了一些讓軟件開發(fā)團隊具有快速工作、響應(yīng)變化能力的價值觀和原則，并于2001初成立了敏捷聯(lián)盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發(fā)方法。通過這項工作，他們認為：個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作響應(yīng)變化勝過合同談判勝過遵循計劃并提出了以下遵循的原則：我們最優(yōu)先要做的是通過盡早的、持續(xù)的交

5、付有價值的軟件來使客戶即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。圍繞被激勵起來的個體來構(gòu)建項目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。在團隊內(nèi)部，最具有效果并富有效率的傳遞信息的方法，就是面對面的交談。工作的軟件是首要的進度度量標準。敏捷過程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力。簡單是最根本的。最好的構(gòu)架、需求和設(shè)

6、計出于自組織團隊。每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應(yīng)地對自己的行為進行調(diào)整。MatainFlow:從無到繁重再到敏捷多數(shù)軟件開發(fā)仍然是一個顯得混亂的活動，即典型的“邊寫邊改”(codeandfix)。設(shè)計過程充斥著短期的，即時的決定，而無完整的規(guī)劃。這種模式對小系統(tǒng)開發(fā)其實很管用，但是當(dāng)系統(tǒng)變得越大越復(fù)雜時，要想加入新的功能就越來越困難。同時錯誤故障越來越多，越來越難于排除。一個典型的標志就是當(dāng)系統(tǒng)功能完成后有一個很長的測試階段，有時甚至有遙遙無期之感，從而對項目的完成產(chǎn)生嚴重的影響。我們使用這種開發(fā)模式已有很長時間了，不過我們實際上也有另外一種選擇，那就是“正規(guī)

7、方法”(methodology)。這些方法對開發(fā)過程有著嚴格而詳盡的規(guī)定，以期使軟件開發(fā)更有可預(yù)設(shè)性并提高效率，這種思路是借鑒了其他工程領(lǐng)域的實踐。這些正規(guī)方法已存在了很長時間了，但是并沒有取得令人矚目的成功，甚至就沒怎么引起人們的注意。對這些方法最常聽見的批評就是它們的官僚繁瑣，要是按照它的要求來，那有做太多的事情需要做，而延緩整個開發(fā)進程。所以它們通常被認為是“繁瑣滯重型”方法，或JimHighSmith所稱的“巨型(monumental)方法。作為對這些方法的反叛，在過去幾年中出現(xiàn)了一類新方法。盡管它們還沒有正式的名稱，但是一般被稱為“敏捷型方法。對許多人來說，這類方法的吸引之處在于對繁

8、文縟節(jié)的官僚過程的反叛。它們在無過程和過于繁瑣的過程中達到了一種平衡，使得能以不多的步驟過程獲取較滿意的結(jié)果。敏捷型與滯重型方法有一些顯著的區(qū)別。其中一個顯而易見的不同反映在文檔上。敏捷型不是很面向文檔，對于一項任務(wù)，它們通常只要求盡可能少的文檔。從許多方面來看，它們更象是“面向源碼”(code-oriented)。事實上，它們認為最根本的文檔應(yīng)該是源碼。但是，我并不以為文檔方面的特點是敏捷型方法的根本之點。文檔減少僅僅是個表象，它其實反映的是更深層的特點：1敏捷型方法是“適配性”而非“預(yù)設(shè)性”。重型方法試圖對一個軟件開發(fā)項目在很長的時間跨度內(nèi)作出詳細的計劃，然后依計劃進行開發(fā)。這類方法在計劃

9、制定完成后拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應(yīng)變化的過程，甚至能允許改變自身來適應(yīng)變化。2敏捷型方法是“面向人”的(people-oriented)而非“面向過程”的(process-oriented)。它們試圖使軟件開發(fā)工作順應(yīng)人的天性而非逆之。它們強調(diào)軟件開發(fā)應(yīng)當(dāng)是一項愉快的活動。我認為以上兩個特點很好的概括了敏捷開發(fā)方法的核心思想：適應(yīng)變化和以人為中心Ation：CustomerEngagementTestDrivenDevelopmentCollaborativeFocusPairProgrammingStandupRefactoringFrequentRel

10、easesAutomatedTestingMinimalDocumentationAdaptivePlanningContinuousIntegration這兩個圓圈表示不同的視角上的敏捷實踐，包括開發(fā)者視角和項目管理的視角。接下來從里向外進行介紹。Test-DrivenDevelopment，測試驅(qū)動開發(fā)，它是敏捷開發(fā)的最重要的部分。在ThoughtWorks，我們實現(xiàn)任何一個功能都是從測試開始，首先對業(yè)務(wù)需求進行分析，分解為一個一個的Story,記錄在StoryCard上。然后兩個人同時坐在電腦前面，一個人依照Story,從業(yè)務(wù)需求的角度來編寫測試代碼，另一個人看著他并且進行思考,如果有不

11、同的意見就會提出來進行討論,直到達成共識,這樣寫出來的測試代碼就真實反映了業(yè)務(wù)功能需求。接著由另一個人控制鍵盤，編寫該測試代碼的實現(xiàn)。如果沒有測試代碼，就不能編寫功能的實現(xiàn)代碼。先寫測試代碼，能夠讓開發(fā)人員明確目標，就是讓測試通過。ContinuousIntegration，持續(xù)集成。在以往的軟件開發(fā)過程中，集成是一件很痛苦的事情，通常很長時間才會做一次集成，這樣的話，會引發(fā)很多問題，比如build未通過或者單元測試失敗。敏捷開發(fā)中提倡持續(xù)集成，一天之內(nèi)集成十幾次甚至幾十次，如此頻繁的集成能盡量減少沖突，由于集成很頻繁，每一次集成的改變也很少，即使集成失敗也容易定位錯誤。一次集成要做哪些事情呢

12、？它至少包括：獲得所有源代碼；編譯源代碼；運行所有測試，包括單元測試、功能測試等；確認編譯和測試是否通過，最后發(fā)送報告。當(dāng)然也會做一些其它的任務(wù)，比如說代碼分析、測試覆蓋率分析等等。在我們公司里，開發(fā)人員的桌上有一個火山燈用來標志集成的狀態(tài)，如果是黃燈，表示正在集成；如果是綠燈，表示上一次集成通過，開發(fā)人員在這時候獲得的代碼是可用而可靠的；如果顯示為紅燈，就要小心了，上一次集成未通過，需要盡快定位失敗原因從而讓燈變綠。在持續(xù)集成上，我們公司使用的是自己開發(fā)的產(chǎn)品CruiseControlRefactoring,重構(gòu)。相信大家對它都很熟悉了，有很多很多的書用來介紹重構(gòu)，最著名的是Martin的重

13、構(gòu)，Joshua的從重構(gòu)到模式等。重構(gòu)是在不改變系統(tǒng)外部行為下，對內(nèi)部結(jié)構(gòu)進行整理優(yōu)化，使得代碼盡量簡單、優(yōu)美、可擴展。在以往開發(fā)中，通常是在有需求過來，現(xiàn)在的系統(tǒng)架構(gòu)不容易實現(xiàn)，從而對原有系統(tǒng)進行重構(gòu)；或者在開發(fā)過程中有剩余時間了，對現(xiàn)在代碼進行重構(gòu)整理。但是在敏捷開發(fā)中，重構(gòu)貫穿于整個開發(fā)流程，每一次開發(fā)者checkin代碼之前，都要對所寫代碼進行重構(gòu)，讓代碼達到cleancodethatworks。值得注意的是，在重構(gòu)時，每一次改變要盡可能小，用單元測試來保證重構(gòu)是否引起沖突，并且不只是對實現(xiàn)代碼進行重構(gòu)，如果測試代碼中有重復(fù)，也要對它進行重構(gòu)。Pair-Programming，結(jié)對編程

14、。在敏捷開發(fā)中，做任何事情都是Pair的，包括分析、寫測試、寫實現(xiàn)代碼或者重構(gòu)。Pair做事有很多好處，兩個人在一起探討很容易產(chǎn)生思想的火花，也不容易走上偏路。在我們公司，還有很多事都是Pair來做，比如Pair學(xué)習(xí)，Pair翻譯，Pair做PPT，關(guān)于這個話題，錢錢同學(xué)有一篇很有名的文章對它進行介紹，名為PairProgramming（結(jié)對編程）。Standup，站立會議。每天早上，項目組的所有成員都會站立進行一次會議，由于是站立的，所以時間不會很長，一般來說是15-20分鐘。會議的內(nèi)容并不是需求分析、任務(wù)分配等，而是每個人都回答三個問題：1.你昨天做了什么？2.你今天要做什么？3.你遇到了

15、哪些困難？站立會議讓團隊進行交流，彼此相互熟悉工作內(nèi)容，如果有人曾經(jīng)遇到過和你類似的問題，那么在站立會議后，他就會和你進行討論。FrequentReleases，小版本發(fā)布。在敏捷開發(fā)中，不會出現(xiàn)這種情況，拿到需求以后就閉門造車，直到最后才將產(chǎn)品交付給客戶，而是盡量多的產(chǎn)品發(fā)布，一般以周、月為單位。這樣，客戶每隔一段時間就會拿到發(fā)布的產(chǎn)品進行試用，而我們可以從客戶那得到更多的反饋來改進產(chǎn)品。正因為發(fā)布頻繁，每一個版本新增的功能簡單，不需要復(fù)雜的設(shè)計，這樣文檔和設(shè)計就在很大程度上簡化了。又因為簡單設(shè)計，沒有復(fù)雜的架構(gòu)，所以客戶有新的需求或者需求進行變動，也能很快的適應(yīng)。MinimalDocume

16、ntation，較少的文檔。其實敏捷開發(fā)中并不是沒有文檔，而是有大量的文檔，即測試。這些測試代碼真實的反應(yīng)了客戶的需求以及系統(tǒng)API的用法，如果有新人加入團隊，最快的熟悉項目的方法就是給他看測試代碼，而比一邊看著文檔一邊進行debug要高效。如果用書面文檔或者注釋，某天代碼變化了，需要對這些文檔進行更新。一旦忘記更新文檔，就會出現(xiàn)代碼和文檔不匹配的情況，這更加會讓人迷惑。而在敏捷中并不會出現(xiàn)，因為只有測試變化了，代碼才會變化，測試是真實反應(yīng)代碼的。這時有人會問：代碼不寫注釋行嗎？一般來說好的代碼不是需要大量的注釋嗎？其實簡單可讀的代碼才是好的代碼，既然簡單可讀了，別人一看就能夠看懂，這時候根本

17、不需要對代碼進行任何注釋。若你覺得這段代碼不加注釋的話別人可能看不懂，就表示設(shè)計還不夠簡單，需要對它進行重構(gòu)。CollaborativeFocus，以合作為中心，表現(xiàn)為代碼共享。在敏捷開發(fā)中，代碼是歸團隊所有而不是哪些模塊的代碼屬于哪些人，每個人都有權(quán)利獲得系統(tǒng)任何一部分的代碼然后修改它，如果有人看到某些代碼不爽的話，那他能夠?qū)@部分代碼重構(gòu)而不需要征求代碼作者的同意，很可能也不知道是誰寫的這部分代碼。這樣每個人都能熟悉系統(tǒng)的代碼，即使團隊的人員變動，也沒有風(fēng)險。CustomerEngagement，現(xiàn)場客戶。敏捷開發(fā)中，客戶是與開發(fā)團隊一起工作的，團隊到客戶現(xiàn)場進行開發(fā)或者邀請客戶到團隊公司

18、里來開發(fā)。如果開發(fā)過程中有什么問題或者產(chǎn)品經(jīng)過一個迭代后，能夠以最快速度得到客戶的反饋。AutomatedTesting，自動化測試。為了減小人力或者重復(fù)勞動，所有的測試包括單元測試、功能測試或集成測試等都是自動化的，這對QA人員提出了更高的要求。他們要熟悉開發(fā)語言、自動化測試工具，能夠編寫自動化測試腳本或者用工具錄制。我們公司在自動化測試上做了大量的工作，包括Selenium開源項目。AdaptivePlanning，可調(diào)整計劃。敏捷開發(fā)中計劃是可調(diào)整的，并不是像以往的開發(fā)過程中，需求分析-概要設(shè)計-詳細設(shè)計-開發(fā)-測試-交付，每一個階段都是有計劃的進行，一個階段結(jié)束便開始下一個階段。而敏捷

19、開發(fā)中只有一次一次的迭代，小版本的發(fā)布，根據(jù)客戶反饋隨時作出相應(yīng)的調(diào)整和變化。敏捷開發(fā)過程與傳統(tǒng)的開發(fā)過程有很大不同，在這過程中，團隊是有激情有活力的，能夠適應(yīng)更大的變化，做出更高質(zhì)量的軟件。TDD：背景一個高效的軟件開發(fā)過程對軟件開發(fā)人員來說是至關(guān)重要的，決定著開發(fā)是痛苦的掙扎，還是不斷進步的喜悅。國人對軟件藍領(lǐng)的不屑，對繁瑣冗長的傳統(tǒng)開發(fā)過程的不耐，使大多數(shù)開發(fā)人員無所適從。最近興起的一些軟件開發(fā)過程相關(guān)的技術(shù)，提供一些比較高效、實用的軟件過程開發(fā)方法。其中比較基礎(chǔ)、關(guān)鍵的一個技術(shù)就是測試驅(qū)動開發(fā)(Test-DrivenDevelopment)。雖然TDD光大于極限編程，但測試驅(qū)動開發(fā)完全

20、可以單獨應(yīng)用。下面就從開發(fā)人員使用的角度進行介紹，使開發(fā)人員用最少的代價盡快理解、掌握、應(yīng)用這種技術(shù)。下面分優(yōu)勢，原理，過程，原則，測試技術(shù)，Tips等方面進行討論。優(yōu)勢TDD的基本思路就是通過測試來推動整個開發(fā)的進行。而測試驅(qū)動開發(fā)技術(shù)并不只是單純的測試工作。需求向來就是軟件開發(fā)過程中感覺最不好明確描述、易變的東西。這里說的需求不只是指用戶的需求，還包括對代碼的使用需求。很多開發(fā)人員最害怕的就是后期還要修改某個類或者函數(shù)的接口進行修改或者擴展，為什么會發(fā)生這樣的事情就是因為這部分代碼的使用需求沒有很好的描述。測試驅(qū)動開發(fā)就是通過編寫測試用例，先考慮代碼的使用需求（包括功能、過程、接口等），而

21、且這個描述是無二義的，可執(zhí)行驗證的。通過編寫這部分代碼的測試用例，對其功能的分解、使用過程、接口都進行了設(shè)計。而且這種從使用角度對代碼的設(shè)計通常更符合后期開發(fā)的需求。可測試的要求，對代碼的內(nèi)聚性的提高和復(fù)用都非常有益。因此測試驅(qū)動開發(fā)也是一種代碼設(shè)計的過程。開發(fā)人員通常對編寫文檔非常厭煩，但要使用、理解別人的代碼時通常又希望能有文檔進行指導(dǎo)。而測試驅(qū)動開發(fā)過程中產(chǎn)生的測試用例代碼就是對代碼的最好的解釋。快樂工作的基礎(chǔ)就是對自己有信心，對自己的工作成果有信心。當(dāng)前很多開發(fā)人員卻經(jīng)常在擔(dān)心：“代碼是否正確？”“辛苦編寫的代碼還有沒有嚴重bug?”“修改的新代碼對其他部分有沒有影響？”。這種擔(dān)心甚至

22、導(dǎo)致某些代碼應(yīng)該修改卻不敢修改的地步。測試驅(qū)動開發(fā)提供的測試集就可以作為你信心的來源。當(dāng)然測試驅(qū)動開發(fā)最重要的功能還在于保障代碼的正確性，能夠迅速發(fā)現(xiàn)、定位bug。而迅速發(fā)現(xiàn)、定位bug是很多開發(fā)人員的夢想。針對關(guān)鍵代碼的測試集，以及不斷完善的測試用例，為迅速發(fā)現(xiàn)、定位bug提供了條件。我的一段功能非常復(fù)雜的代碼使用TDD開發(fā)完成，真實環(huán)境應(yīng)用中只發(fā)現(xiàn)幾個bug，而且很快被定位解決。您在應(yīng)用后，也一定會為那種自信的開發(fā)過程，功能不斷增加、完善的感覺，迅速發(fā)現(xiàn)、定位bug的能力所感染，喜歡這個技術(shù)的。那么是什么樣的原理、方法提供上面說的這些好處哪？下面我們就看看TDD的原理。原理測試驅(qū)動開發(fā)的基

23、本思想就是在開發(fā)功能代碼之前，先編寫測試代碼。也就是說在明確要開發(fā)某個功能后，首先思考如何對這個功能進行測試，并完成測試代碼的編寫，然后編寫相關(guān)的代碼滿足這些測試用例。然后循環(huán)進行添加其他功能，直到完全部功能的開發(fā)。我們這里把這個技術(shù)的應(yīng)用領(lǐng)域從代碼編寫擴展到整個開發(fā)過程。應(yīng)該對整個開發(fā)過程的各個階段進行測試驅(qū)動，首先思考如何對這個階段進行測試、驗證、考核，并編寫相關(guān)的測試文檔，然后開始下一步工作，最后再驗證相關(guān)的工作。下圖是一個比較流行的測試模型：V測試模型。【圖V測試模型】畫求分新驗?zāi)翜y試E要設(shè)計系統(tǒng)測試詳31設(shè)計集威周試編碼單元測試vLJB在開發(fā)的各個階段，包括需求分析、概要設(shè)計、詳細設(shè)

24、計、編碼過程中都應(yīng)該考慮相對應(yīng)的測試工作，完成相關(guān)的測試用例的設(shè)計、測試方案、測試計劃的編寫。這里提到的開發(fā)階段只是舉例，根據(jù)實際的開發(fā)活動進行調(diào)整。相關(guān)的測試文檔也不一定是非常詳細復(fù)雜的文檔，或者什么形式，但應(yīng)該養(yǎng)成測試驅(qū)動的習(xí)慣。關(guān)于測試模型，還有X測試模型。這個測試模型，我認為，是對詳細階段和編碼階段進行建模，應(yīng)該說更詳細的描述了詳細設(shè)計和編碼階段的開發(fā)行為。及針對某個功能進行對應(yīng)的測試驅(qū)動開發(fā)。圖X測試模型】髯盍世測試理厚片民1XRE2執(zhí)行測述XAE5TAESAi?X計輕爭片用n基本原理應(yīng)該說非常簡單，那么如何進行實際操作哪，下面對開發(fā)過程進行詳細的介紹。過程軟件開發(fā)其他階段的測試驅(qū)動

25、開發(fā)，根據(jù)測試驅(qū)動開發(fā)的思想完成對應(yīng)的測試文檔即可。下面針對詳細設(shè)計和編碼階段進行介紹。測試驅(qū)動開發(fā)的基本過程如下：明確當(dāng)前要完成的功能?？梢杂涗洺梢粋€TODO列表?？焖偻瓿舍槍Υ斯δ艿臏y試用例編寫。測試代碼編譯不通過。編寫對應(yīng)的功能代碼。測試通過。對代碼進行重構(gòu)，并保證測試通過。循環(huán)完成所有功能的開發(fā)。為了保證整個測試過程比較快捷、方便，通常可以使用測試框架組織所有的測試用例。一個免費的、優(yōu)秀的測試框架是Xunit系列，幾乎所有的語言都有對應(yīng)的測試框架。我曾經(jīng)寫過一篇文章介紹CppUnit的文章。開發(fā)過程中，通常把測試代碼和功能代碼分開存放，這里提供一個簡單的測試框架使用例子，您可以通過它了

26、解測試框架的使用。下面是文件列表。project/project/test測試項目主目錄project/test/testSeq.cpp對其他功能文件的測試文件復(fù)制后修改即可測試seq_t的測試文件，project/test/testSeq.hproject/test/Makefileproject/test/main.cpp修改project/main.cppproject/seq_t.hproject/Makefile測試項目的Makefile測試項目的主文件，不需要項目的主文件功能代碼，被測試文件項目的Makefile項目主目錄主要流程基本如此，但要讓你的代碼很容易的進行測試，全面又不繁

27、瑣的進行測試，還是有很多測試原則和技術(shù)需要考慮。原則測試隔離。不同代碼的測試應(yīng)該相互隔離。對一塊代碼的測試只考慮此代碼的測試，不要考慮其實現(xiàn)細節(jié)(比如它使用了其他類的邊界條件)。一頂帽子。開發(fā)人員開發(fā)過程中要做不同的工作，比如：編寫測試代碼、開發(fā)功能代碼、對代碼重構(gòu)等。做不同的事，承擔(dān)不同的角色。開發(fā)人員完成對應(yīng)的工作時應(yīng)該保持注意力集中在當(dāng)前工作上，而不要過多的考慮其他方面的細節(jié)，保證頭上只有一頂帽子。避免考慮無關(guān)細節(jié)過多，無謂地增加復(fù)雜度。測試列表。需要測試的功能點很多。應(yīng)該在任何階段想添加功能需求問題時，把相關(guān)功能點加到測試列表中，然后繼續(xù)手頭工作。然后不斷的完成對應(yīng)的測試用例、功能代碼

28、、重構(gòu)。一是避免疏漏，也避免干擾當(dāng)前進行的工作。測試驅(qū)動。這個比較核心。完成某個功能，某個類，首先編寫測試代碼，考慮其如何使用、如何測試。然后在對其進行設(shè)計、編碼。先寫斷言。測試代碼編寫時，應(yīng)該首先編寫對功能代碼的判斷用的斷言語句，然后編寫相應(yīng)的輔助語句?？蓽y試性。功能代碼設(shè)計、開發(fā)時應(yīng)該具有較強的可測試性。其實遵循比較好的設(shè)計原則的代碼都具備較好的測試性。比如比較高的內(nèi)聚性，盡量依賴于接口等。及時重構(gòu)。無論是功能代碼還是測試代碼，對結(jié)構(gòu)不合理，重復(fù)的代碼等情況，在測試通過后，及時進行重構(gòu)。關(guān)于重構(gòu)，我會另撰文詳細分析。小步前進。軟件開發(fā)是個復(fù)雜性非常高的工作，開發(fā)過程中要考慮很多東西，包括代

29、碼的正確性、可擴展性、性能等等，很多問題都是因為復(fù)雜性太大導(dǎo)致的。極限編程提出了一個非常好的思路就是小步前進。把所有的規(guī)模大、復(fù)雜性高的工作，分解成小的任務(wù)來完成。對于一個類來說，一個功能一個功能的完成，如果太困難就再分解。每個功能的完成就走測試代碼功能代碼測試重構(gòu)的循環(huán)。通過分解降低整個系統(tǒng)開發(fā)的復(fù)雜性。這樣的效果非常明顯。幾個小的功能代碼完成后，大的功能代碼幾乎是不用調(diào)試就可以通過。一個個類方法的實現(xiàn)，很快就看到整個類很快就完成啦。本來感覺很多特性需要增加，很快就會看到?jīng)]有幾個啦。你甚至?xí)檫@個速度感到震驚。（我理解，是大幅度減少調(diào)試、出錯的時間產(chǎn)生的這種速度感）測試技術(shù)測試范圍、粒度對哪

30、些功能進行測試？會不會太繁瑣？什么時候可以停止測試？這些問題比較常見。按大師KentBenk的話，對那些你認為應(yīng)該測試的代碼進行測試。就是說，要相信自己的感覺，自己的經(jīng)驗。那些重要的功能、核心的代碼就應(yīng)該重點測試。感到疲勞就應(yīng)該停下來休息一下。感覺沒有必要更詳細的測試，就停止本輪測試。測試驅(qū)動開發(fā)強調(diào)測試并不應(yīng)該是負擔(dān)，而應(yīng)該是幫助我們減輕工作量的方法。而對于何時停止編寫測試用例，也是應(yīng)該根據(jù)你的經(jīng)驗，功能復(fù)雜、核心功能的代碼就應(yīng)該編寫更全面、細致的測試用例，否則測試流程即可。測試范圍沒有靜態(tài)的標準，同時也應(yīng)該可以隨著時間改變。對于開始沒有編寫足夠的測試的功能代碼，隨著bug的出現(xiàn)，根據(jù)bug

31、補齊相關(guān)的測試用例即可。小步前進的原則，要求我們對大的功能塊測試時，應(yīng)該先分拆成更小的功能塊進行測試，比如一個類A使用了類B、C,就應(yīng)該編寫到A使用B、C功能的測試代碼前，完成對B、C的測試和開發(fā)。那么是不是每個小類或者小函數(shù)都應(yīng)該測試哪？我認為沒有必要。你應(yīng)該運用你的經(jīng)驗，對那些可能出問題的地方重點測試，感覺不可能出問題的地方就等它真正出問題的時候再補測試吧。怎么編寫測試用例測試用例的編寫就用上了傳統(tǒng)的測試技術(shù)。操作過程盡量模擬正常使用的過程。全面的測試用例應(yīng)該盡量做到分支覆蓋，核心代碼盡量做到路徑覆蓋。測試數(shù)據(jù)盡量包括：真實數(shù)據(jù)、邊界數(shù)據(jù)。測試語句和測試數(shù)據(jù)應(yīng)該盡量簡單，容易理解。為了避免

32、對其他代碼過多的依賴，可以實現(xiàn)簡單的樁函數(shù)或樁類(MockObject)。如果內(nèi)部狀態(tài)非常復(fù)雜或者應(yīng)該判斷流程而不是狀態(tài)，可以通過記錄日志字符串的方式進行驗證。Tips很多朋友有疑問，“測試代碼的正確性如何保障？是寫測試代碼還是寫測試文檔？”這樣是不是會陷入“雞生蛋，蛋生雞”的循環(huán)。其實是不會的。通常測試代碼通常是非常簡單的，通常圍繞著某個情況的正確性判斷的幾個語句，如果太復(fù)雜，就應(yīng)該繼續(xù)分解啦。而傳統(tǒng)的開發(fā)過程通常強調(diào)測試文檔。但隨著開發(fā)節(jié)奏的加快，用戶需求的不斷變化，維護高層(需求、概要設(shè)計)的測試文檔可以，更低層的測試文檔的成本的確太大了。而且可實時驗證功能正確性的測試代碼就是對代碼最好

33、的文檔。軟件開發(fā)過程中，除了遵守上面提到的測試驅(qū)動開發(fā)的幾個原則外，一個需要注意的問題就是，謹防過度設(shè)計。編寫功能代碼時應(yīng)該關(guān)注于完成當(dāng)前功能點，通過測試，使用最簡單、直接的方式來編碼。過多的考慮后期的擴展，其他功能的添加，無疑增加了過多的復(fù)雜性，容易產(chǎn)生問題。應(yīng)該等到要添加這些特性時在進行詳細的測試驅(qū)動開發(fā)。到時候，有整套測試用例做基礎(chǔ)，通過不斷重構(gòu)很容易添加相關(guān)特性。XP：極限編程(ExtremeProgramming，XP)是一門針對業(yè)務(wù)和軟件開發(fā)的規(guī)則，它的作用在于將兩者的力量集中在共同的、可以達到的目標上。它是以符合客戶需要的軟件為目標而產(chǎn)生的一種方法論，XP使開發(fā)者能夠更有效的響應(yīng)

34、客戶的需求變化，哪怕是在軟件生命周期的后期。它強調(diào)，軟件開發(fā)是人與人合作進行的過程，因此成功的軟件開發(fā)過程應(yīng)該充分利用人的優(yōu)勢，而弱化人的缺點，突出了人在軟件開發(fā)過程中的作用。極端編程屬于輕量級的方法，認為文檔、架構(gòu)不如直接編程來的直接。XP實際上是一種經(jīng)歷過很多實踐考驗的一種軟件開發(fā)的方法，它誕生了大概有5年，它已經(jīng)被成功的應(yīng)用在許多大型的公司，如：BayerischeLandesbank，CreditSwissLife，DaimlerChrysler，F(xiàn)irstUnionNationalBankFordMotorCompanyandUBS.XP的成功得益于它對客戶滿意度的特別強調(diào),XP是以

35、開發(fā)符合客戶需要的軟件為目標而產(chǎn)生的一種方法論,XP使開發(fā)者能夠更有效的響應(yīng)客戶的需求變化，哪怕在軟件生命周期的后期。同時，XP也很強調(diào)團隊合作。團隊包括：項目經(jīng)理，客戶，開發(fā)者。他們團結(jié)在一起來保證高質(zhì)量的軟件。XP其實是一種保證成功的團隊開發(fā)的簡單而有效的方法。XP強調(diào)四種價值：交流，簡易，回饋，勇氣。XP程序員之間緊密的相互交流，XP程序員也和客戶緊密的交流。他們總是保持他們的設(shè)計簡單明了。項目一開始，XP就強調(diào)通過對軟件的不斷測試來獲得反饋，程序員盡可能早的把軟件交給客戶，并實現(xiàn)客戶對軟件需求提出的變化，有了這些基礎(chǔ)，XP程序員就可以自信的面對需求和軟件技術(shù)的變化。XP是與眾不同的，它

36、有點象快步的舞蹈。XP開發(fā)過程包括許多的小卡片，獨立的看，這些小卡片沒有什么意義，但是當(dāng)它們組合在一起，一幅完整的美麗的圖片就可以看見，XP方法有別于傳統(tǒng)軟件開發(fā)，它是軟件開發(fā)的一種新的重要的發(fā)展。它改變了我們開發(fā)程序的傳統(tǒng)思維方式。下面我們將介紹它帶給我們那些改變。XP屬于輕量開發(fā)方法中較有影響的一種方法。輕量開發(fā)方法是相對于傳統(tǒng)的重量開發(fā)方法而言。簡單地理解，“量”的輕重是指用于軟件過程管理和控制的、除程序量以外的文檔量的多少。XP等輕量開發(fā)方法認識到，在當(dāng)前很多情況下，按傳統(tǒng)觀念建立的大量文檔，一方面需要消耗大量開發(fā)資源，同時卻已失去幫助預(yù)見、管理、決策和控制的依據(jù)”的作用。因此必須重新

37、審視開發(fā)環(huán)節(jié)，去除臃腫累贅，輕裝上陣。一、XP的核心思想從長遠看，早期發(fā)現(xiàn)錯誤以及降低復(fù)雜度可以節(jié)約成本。極限編程強調(diào)我們將任務(wù)/系統(tǒng)細分為可以在較短周期解決的一個個子任務(wù)/模塊，并且強調(diào)測試、代碼質(zhì)量和及早發(fā)現(xiàn)問題。通常，通過一個個短小的迭代周期，我們就可以獲得一個個階段性的進展，并且可以及時形成一個版本供用戶參考，以便及時對用戶可能的需求變更作出響應(yīng)。二、XP的十二種方法規(guī)劃策略(ThePlanningGame)；結(jié)對編程(Pairprogramming)測試(Testing)重構(gòu)(Refractoring)簡單設(shè)計(SimpleDesign)代碼集體所有權(quán)(CollectiveCodeO

38、wnership)持續(xù)集成(ContinuousIntegration)現(xiàn)場客戶(On-siteCustomer)小型發(fā)布(SmallRelease)每周40小時工作制(40-hourWeek)編碼規(guī)范(CodeStandards)系統(tǒng)隱喻(SystemMetaphor)三、XP的四個核心價值極限編程中有四個核心價值是我們在開發(fā)中必須注意的：溝通(Communication)、簡單(Simplicity)、反饋(Feedback)和勇氣(Courage)。XP用“溝通、簡單、反饋和勇氣”來減輕開發(fā)壓力和包袱；無論是術(shù)語命名、專著敘述內(nèi)容和方式、過程要求，都可以從中感受到輕松愉快和主動奮發(fā)的態(tài)度

39、和氣氛。這是一種幫助理解和更容易激發(fā)人的潛力的手段。XP用自己的實踐，在一定范圍內(nèi)成功地打破了軟件工程“必須重量”才能成功的傳統(tǒng)觀念。XP精神可以啟發(fā)我們?nèi)绾螌W(xué)習(xí)和對待快速變化、多樣的開發(fā)技術(shù)。成功學(xué)習(xí)XP的關(guān)鍵，是用溝通、簡單、反饋和勇氣的態(tài)度來對待XP；輕松愉快地來感受XP的實踐思想；自己認真實踐后，通過對真實反饋的分析，來決定XP對自己的價值；有勇氣接受它，或改進它。四、XP帶給我們的變化通過軟件工程設(shè)計的簡單而優(yōu)美的軟件并不比那些設(shè)計復(fù)雜而難以維護的軟件有價值。這是真的嗎？XP認為事實并非如此。一個典型的項目花在人力上的金錢是花在硬件上的時間的20倍，這意味著一個項目每年要花200萬美

40、元在程序員身上，而僅僅花10萬美元在電腦設(shè)備上。很多聰明的程序員說：我們?nèi)绱寺斆?，發(fā)現(xiàn)一種方法可以節(jié)省20%的硬件開銷”，然后他們使得源程序大而且難懂和難以維護，他們會說：但是我們節(jié)省了20%或者2萬美元每年，很大的節(jié)省”。反之，如果我們寫我們的程序簡單而且容易擴展，我們將至少節(jié)省10%的人力開銷，一筆更大的節(jié)省，這是你客戶一定會注意到的一些事情。另外一個對客戶來說很重要的問題就是程序的BUGS。XP不只是強調(diào)測試，而且要求正確的測試。測試必須是能自動進行的，以便為程序和客戶提供一個安全的環(huán)境。在編碼的所有階段，我們不斷增加測試用例。當(dāng)找到bug時，我們就添加新的測試，一個緊密的安全網(wǎng)就這樣產(chǎn)

41、生了。同一個BUG不出現(xiàn)兩次，這些一定會引起用戶的注意。你的客戶必須注意的另外一件事情：XP開發(fā)者擁抱需求變化。XP使我們能夠接受需求的變化。一般情況下，客戶只有在系統(tǒng)被開發(fā)完成以后能真正去體會它。XP卻不一樣，它通過加強客戶的反饋來縮短開發(fā)的周期，同時獲得足夠的時間來改變功能和獲得用戶的認同。在XP中，你的客戶應(yīng)該明確的知道這一點。XP開發(fā)過程的大多的革命是在軟件開發(fā)的方法上，代碼質(zhì)量的重要程度超出人們一般所認為的。僅僅因為我們的客戶不能明白我們的源代碼并不意味著我們可以不努力去管理代碼的質(zhì)量。五、我們什么時候用XPXP方法的產(chǎn)生是因為難以管理的需求變化，從一開始你的客戶并不是很完全的知道他們要的系統(tǒng)是怎么樣的，你可能面對的系統(tǒng)的功能一個月變化多次。在大多數(shù)軟件開發(fā)環(huán)境中不斷變化的需求是唯一的不變，這個時候應(yīng)用XP就可以取得別的方法不可能取得的成功。XP方法的建立同時也是為了解決軟件開發(fā)項目中的風(fēng)險問題。假如你的客戶在特定的時間內(nèi)，需要一個相當(dāng)難開發(fā)的系統(tǒng)，而且對于你的項目組來