學習完整課程請移步 互聯(lián)網(wǎng) Java 全棧工程師
本節(jié)視頻
概述
敏捷方法論有一個共同的特點，那就是都將矛頭指向了“文檔”饱亿，它們認為傳統(tǒng)的軟件工程方法文檔量太“重”了芒划，稱為“重量級”方法夺脾，而相應的敏捷方法則是“輕量級”方法疗隶。正是因為“輕量級”感覺沒有什么力量摔握，不但不能夠有效體現(xiàn)靈活性键耕，反而顯得是不解決問題的方法論似的寺滚。因此迁霎，就有了一次劃時代的會議萨惑，創(chuàng)建了敏捷聯(lián)盟瞭恰。
在敏捷方法論領域中倔约，比較知名的宣决、有影響力的婉弹，是擁有與 Microsoft 的操作系統(tǒng)相同縮寫語——XP的極限編程（eXtreme Programming）荒叶。極限編程方法論可以說是敏捷聯(lián)盟中最鮮艷的一面旗幟豪筝，也是被研究惋嚎、嘗試杠氢、應用、贊揚另伍、批判最多的一種方法論鼻百，也是相對來說最成熟的一種。
這一被譽為“黑客文化”的方法論的雛形最初形成于1996—1999年間摆尝，Kent Beck温艇、Ward Cunninggham、Ron Jeffrey 在開發(fā) C3 項目（Chrysler Comprehensive Compensation）的實踐中總結出了 XP 的基本元素堕汞。在此之后勺爱，Kent Beck 和他的一些好朋友們一起在實踐中完善提高，終于形成了極限編程方法論讯检。
解析極限編程
那么什么是 XP 呢琐鲁？XP 是一種輕量（敏捷）、高效视哑、低風險绣否、柔性、可預測挡毅、科學而且充滿樂趣的軟件開發(fā)方式蒜撮。與其他方法論相比，其最大的不同在于：
- 在更短的周期內跪呈，更早地提供具體段磨、持續(xù)的反饋信息。
- 在迭代的進行計劃編制耗绿，首先在最開始迅速生成一個總體計劃苹支，然后在整個項目開發(fā)過程中不斷的發(fā)展它。
- 依賴于自動測試程序來監(jiān)控開發(fā)進度误阻，并及早地捕獲缺陷债蜜。
- 依賴于口頭交流晴埂、測試和源程序進行溝通。
- 倡導持續(xù)的演化式設計寻定。
- 依賴于開發(fā)團隊內部的緊密協(xié)作儒洛。
- 盡可能達到程序員短期利益和項目長期利益的平衡。
Kent Beck 曾經(jīng)說過“開車”就是一個 XP 的范例狼速，即使看上去進行得很順利琅锻，也不要把視線從公路上移開，因為路況的變化向胡，將使得你必須隨時做出一些這樣那樣的調整恼蓬。而在軟件項目中，客戶就是司機僵芹，他們也沒有辦法確切地知道軟件應該做什么处硬，因此程序員就需要向客戶提供方向盤，并且告知我們現(xiàn)在的位置拇派。
XP 包括寫什么呢郁油？如圖，XP 由價值觀攀痊、原則、實踐和行為四個部分組成拄显，它們彼此相互依賴苟径、關聯(lián)， 并通過行為貫穿于整個生命期躬审。
四大價值觀
XP 的核心是其總結的溝通（Communication）棘街、簡單（Simplicity）、反饋（Feedback）承边、勇氣（Courage）四大價值觀遭殉，它們是XP的基礎，也是XP的靈魂博助。
此外還擴展了第五個價值觀：謙遜（Modesty）险污。 XP用“溝通、簡單富岳、反饋蛔糯、勇氣和謙遜”來減輕開發(fā)壓力和包袱；XP 精神可以啟發(fā)我們如何學習和對待快速變化窖式、多樣的開發(fā)技術蚁飒。成功學習 XP 的關鍵，是用“溝通萝喘、簡單淮逻、反饋琼懊、勇氣和謙遜”的態(tài)度來對待 XP；輕松愉快地來感受 XP 的實踐思想爬早；自己認真實踐后哼丈，通過對真實反饋的分析，來決定 XP 對自己的價值凸椿；有勇氣接受它削祈，或改進它。
溝通
通常程序員給人留下的印象就是“內向脑漫、不善言談”髓抑，然后項目中的許多問題就出在這些缺乏溝通的開發(fā)人員身上。經(jīng)常由于某個程序員做出了一個設計決定优幸，但是卻不能及時地通知大家吨拍，結果使得大家在協(xié)作與配合上出現(xiàn)了很多的麻煩，而在傳統(tǒng)的方法論中网杆，并不在意這種口頭溝通不暢的問題羹饰，而是希望借助于完善的流程和面面俱到的文檔、報表碳却、計劃來替代队秩，但是這同時又引入了效率不高的新問題。
XP 方法論認為昼浦，如果小組成員之間無法做到持續(xù)的馍资、無間斷的交流，那么協(xié)作就無從談起关噪，從這個角度能夠發(fā)現(xiàn)鸟蟹，通過文檔、報表等人工制品進行交流面臨巨大的局限性使兔。因此建钥，XP 組合了諸如對編程這樣的最佳實踐，鼓勵大家進行口頭交流虐沥，通過交流解決問題熊经，提高效率。
簡單
XP 方法論提倡在工作中秉承“夠用就好”的思路置蜀，也就是盡量地簡單化奈搜，只要今天夠用就行，不考慮明天會發(fā)現(xiàn)的新問題盯荤。這一點看上去十分容易馋吗，但是要真正做到保持簡單的工作其實很難的。因為在傳統(tǒng)的開發(fā)方法中秋秤，都要求大家對未來做一些預先規(guī)劃宏粤，以便對今后可能發(fā)生的變化預留一些擴展的空間脚翘。
正如對傳統(tǒng)開發(fā)方法的認識一樣，許多開發(fā)人員也會質疑 XP绍哎，保持系統(tǒng)的擴展性很重要来农，如果都保持簡單，那么如何使得系統(tǒng)能夠有良好的擴展性呢崇堰？其實不然沃于，保持簡單的理由有兩個：
- 開發(fā)小組在開發(fā)時所做的規(guī)劃，并無法保證其符合客戶需要的海诲，因此做的大部分工作都將落空繁莹，使得開發(fā)過程中重復的、沒有必要的工作增加特幔，導致整體效率降低咨演。
- 另外，在 XP 中提倡時刻對代碼進行重構蚯斯，一直保持其良好的結構與可擴展性薄风。也就是說，可擴展性和為明天設計并不是同一個概念拍嵌，XP 是反對為明天考慮而工作遭赂，并不是說代碼要失去擴展性
而且簡單和溝通之間還有一種相對微妙的相互支持關系。當一個團隊之間横辆，溝通的越多嵌牺，那么就越容易明白哪些工作需要做，哪些工作不需要做龄糊。另一方面，系統(tǒng)越簡單募疮，需要溝通的內容也就越少炫惩，溝通也將更加全面。
反饋
是什么原因使得我們的客戶阿浓、管理層這么不理解開發(fā)團隊他嚷？為什么客戶、管理層總是喜歡給我們一個死亡之旅芭毙？究其癥結筋蓖，就是開發(fā)的過程中缺乏必要的反饋。在許許多多項目中退敦，當開發(fā)團隊經(jīng)歷過了需求分析階段之后粘咖，在相當長的一段時間內，是沒有任何反饋信息的侈百。整個開發(fā)過程對于客戶和管理層而言就像一個黑盒子瓮下，進度完全是不可見的翰铡。
而且在項目的過程中，這樣的現(xiàn)象不僅出現(xiàn)在開發(fā)團隊與客戶讽坏、管理層之間锭魔，還包括在開發(fā)團隊內部。這一切問題都需要我們更加注重反饋路呜。迷捧，反饋對于任何軟件項目的成功都是至關重要的，而在 XP 方法論中則更進一步胀葱，通過持續(xù)漠秋、明確的反饋來暴露軟件狀態(tài)的問題。具體而言就是：
- 在開發(fā)團隊內部巡社，通過提前編寫單元測試代碼膛堤，時時反饋代碼的問題與進展。
- 在開發(fā)過程中晌该，還應該加強集成工作肥荔，做到持續(xù)集成，使得每一次增量都是一個可執(zhí)行的工作版本朝群，也就是逐漸是軟件長大燕耿，整個過程中，應該通過向客戶和管理層演示這些可運行的版本姜胖，以便及早地反饋誉帅，及早地發(fā)現(xiàn)問題。
同時右莱，我們也會發(fā)現(xiàn)反饋與溝通也有著良好的配合蚜锨，及時和良好的反饋有助于溝通。而簡單的系統(tǒng)更有利于測試和反饋慢蜓。
勇氣
在應用 XP 方法論時亚再，我們每時每刻都在應對變化：由于溝通良好，因此會有更多需求變更的機會晨抡；由于時刻保持系統(tǒng)的簡單氛悬，因此新的變化會帶來一些重新開發(fā)的需要；由于反饋及時耘柱，因此會有更多中間打斷你的思路的新需求如捅。
總之這一切，使得你立刻處于變化之中调煎，因此這時就需要你有勇氣來面對快速開發(fā)镜遣，面對可能的重新開發(fā)。也許你會覺得士袄，為什么要讓我們的開發(fā)變得如此零亂烈涮，但是其實這些變化若你不讓它早暴露朴肺，那么它就會遲一些出現(xiàn)，并不會因此消亡坚洽，因此戈稿，XP 方法論讓它們早出現(xiàn)、早解決讶舰，是實現(xiàn)“小步快走”開發(fā)節(jié)奏的好辦法鞍盗。
也就是 XP 方法論要求開發(fā)人員穿上強大、自動測試的盔甲跳昼，勇往直前般甲，在重構、編碼規(guī)范的支持下鹅颊，有目的地快速開發(fā)敷存。
勇氣可以來源于溝通，因為它使得高風險堪伍、高回報的試驗成為可能锚烦；勇氣可以來源于簡單，因為面對簡單的系統(tǒng)帝雇，更容易鼓起勇氣涮俄；勇氣可以來源于反饋，因為你可以及時獲得每一步前進的狀態(tài)（自動測試）尸闸，會使得你更勇于重構代碼彻亲。
四大價值觀之外
在這四大價值觀之下，隱藏著一個更深刻的東西吮廉，那就是尊重苞尝。因為這一切都建立在團隊成員之間的相互關心、相互理解的基礎之上宦芦。
5 個原則
快速反饋
及時地野来、快速地獲取反饋，并將所學到的知識盡快地投入到系統(tǒng)中去踪旷。也就是指開發(fā)人員應該通過較短的反饋循環(huán)迅速地了解現(xiàn)在的產(chǎn)品是否滿足了客戶的需求。這也是對反饋這一價值觀的進一步補充豁辉。
簡單性假設
類似地令野，簡單性假設原則是對簡單這一價值觀的進一步補充。這一原則要求開發(fā)人員將每個問題都看得十分容易解決徽级，也就是說只為本次迭代考慮气破，不去想未來可能需要什么，相信具有將來必要時增加系統(tǒng)復雜性的能力餐抢，也就是號召大家出色地完成今天的任務现使。
逐步修改
就像開車打方向盤一樣低匙，不要一次做出很大的改變，那樣將會使得可控性變差碳锈，更適合的方法是進行微調顽冶。而在軟件開發(fā)中，這樣的道理同樣適用售碳，任何問題都應該通過一系列能夠帶來差異的微小改動來解決强重。
提倡更改
在軟件開發(fā)過程中，最好的辦法是在解決最重要問題時贸人，保留最多選項的那個间景。也就是說，盡量為下一次修改做好準備艺智。
優(yōu)質工作
在實踐中倘要，經(jīng)常看到許多開發(fā)人員喜歡將一些細小的問題留待后面解決十拣。例如封拧，界面的按鈕有一些不平整，由于不影響使用就先不管父晶；某一兩個成員函數(shù)暫時沒用就不先寫等哮缺。這就是一種工作拖泥帶水的現(xiàn)象，這樣的壞習慣一旦養(yǎng)成甲喝，必然使得代碼質量大打折扣尝苇。
而在 XP 方法論中，貫徹的是“小步快走”的開發(fā)原則埠胖，因此工作質量決不可打折扣糠溜，通常采用測試先行的編碼方式來提供支持。
13 個最佳實踐
在 XP 中直撤，集成了 13 個最佳實踐非竿，有趣的是，它們沒有一個是創(chuàng)新的概念谋竖，大多數(shù)概念和編程一樣老红柱。其主要創(chuàng)新點在于提供一種良好的思路，將這些最佳實踐結合在一起蓖乘，并且確保盡可能徹底地執(zhí)行它們锤悄，使得它們能夠在最大程度上相互支持，緊接下來嘉抒，我們就對每一種最佳實踐進行一番了解零聚。
計劃游戲
計劃游戲的主要思想就是先快速地制定一份概要的計劃，然后隨著項目細節(jié)的不斷清晰，再逐步完善這份計劃隶症。計劃游戲產(chǎn)生的結果是一套用戶故事及后續(xù)的一兩次迭代的概要計劃政模。
“客戶負責業(yè)務決策，開發(fā)團隊負責技術決策”是計劃游戲獲得成功的前提條件蚂会。也就是說淋样，系統(tǒng)的范圍、下一次迭代的發(fā)布時間颂龙、用戶故事的優(yōu)先級應該由客戶決定习蓬；而每個用戶故事所需的開發(fā)時間、不同技術的成本措嵌、如何組建團隊躲叼、每個用戶故事的風險，以及具體的開發(fā)順序應該由開發(fā)團隊決定企巢。
好了枫慷，明白這些就可以進行計劃游戲了。首先客戶和開發(fā)人員坐在同一間屋子里浪规，每個人都準備一支筆或听、一些用于記錄用戶故事的紙片，最好再準備一個白板笋婿，就可以開始了誉裆。
- 客戶編寫故事：由客戶談論系統(tǒng)應該完成什么功能，然后用通俗的自然語言缸濒，使用自己的語匯足丢，將其寫在卡片上，這也就是用戶故事庇配。
- 開發(fā)人員進行估算：首先客戶按優(yōu)先級將用戶故事分成必須要有斩跌、希望有、如果有更好三類捞慌，然后開發(fā)人員對每個用戶故事進行估算耀鸦，先從高優(yōu)先級開始估算。如果在估算的時候啸澡，感到有一些故事太大袖订，不容易進行估算，或者是估算的結果超過 2人/周嗅虏，那么就應該對其進行分解洛姑，拆成 2 個或者多個小故事。
- 確定迭代的周期：接下來就是確定本次迭代的時間周期旋恼，這可以根據(jù)實際的情況進行確定，不過最佳的迭代周期是 2~3 周。有了迭代的時間之后冰更，再結合參與的開發(fā)人數(shù)产徊，算出可以完成的工作量總數(shù)。然后根據(jù)估算的結果蜀细，與客戶協(xié)商舟铜，挑出時間上夠、優(yōu)先級合適的用戶故事組合奠衔，形成計劃谆刨。
小型發(fā)布
XP 方法論秉承的是“持續(xù)集成，小步快走”的哲學归斤，也就是說每一次發(fā)布的版本應該盡可能的小痊夭，當然前提條件是每個版本有足夠的商業(yè)價值，值得發(fā)布脏里。
由于小型發(fā)布可以使得集成更頻繁她我，客戶獲得的中間結果也越頻繁，反饋也就越頻繁迫横，客戶就能夠實時地了解項目的進展情況番舆，從而提出更多的意見，以便在下一次迭代中計劃進去矾踱。以實現(xiàn)更高的客戶滿意度恨狈。
隱喻
相對而言，隱喻這一個最佳實踐是最令人費解的呛讲。什么是隱喻呢禾怠？根據(jù)詞典中的解釋是：“一種語言的表達手段，它用來暗示字面意義不相似的事物之間的相似之處”圣蝎。那么這在軟件開發(fā)中又有什么用呢刃宵？總結而言，常常用于四個方面徘公。
- 尋求共識：也就是鼓勵開發(fā)人員在尋求問題共識時牲证，可以借用一些溝通雙方都比較熟悉的事物來做類比，從而幫助大家更好地理解解決方案的關鍵結構关面，也就是更好地理解系統(tǒng)是什么坦袍、能做什么。
- 發(fā)明共享詞匯：通過隱喻等太，有助于提出一個用來表示對象捂齐、對象間的關系通用名稱。例如缩抡，策略模式（用來表示可以實現(xiàn)多種不同策略的設計模式）奠宜、工廠模式（用來表示可以按需“生產(chǎn)”出所需類得設計模式）等。
- 創(chuàng)新的武器：有的時候，可以借助其他東西來找到解決問題的新途徑压真。例如：“我們可以將工作流看做一個生產(chǎn)線”娩嚼。
- 描述體系結構：體系結構是比較抽象的，引入隱喻能夠大大減輕理解的復雜度滴肿。例如管道體系結構就是指兩個構件之間通過一條傳遞消息的“管道”進行通信岳悟。
當然，如果能夠找到合適的隱喻是十分快樂的泼差，但并不是每種情況都可以找到恰當?shù)碾[喻贵少，你也沒有必要強求
簡單設計
強調簡單設計的價值觀，引出了簡單性假設原則堆缘，落到實處就是“簡單設計”實踐滔灶。這個實踐看上去似乎很容易理解，但卻又經(jīng)常被誤解套啤，許多批評者就指責 XP 忽略設計是不正確的宽气。其實，XP 的簡單設計實踐并不是要忽略設計潜沦，而且認為設計不應該在編碼之前一次性完成萄涯，因為那樣只能建立在“情況不會發(fā)生變化”或者“我們可以預見所有的變化”之類的謊言的基礎上的。
Kent Beck 概念中簡單設計是這樣的：
- 能夠通過所有的測試程序唆鸡。
- 沒有包括任何重復的代碼涝影。
- 清楚地表現(xiàn)了程序員賦予的所有意圖。
- 包括盡可能少的類和方法
- 他認為要想保持設計簡單的系統(tǒng)争占，需要具備簡單思考的能力燃逻，擁有理解代碼和修改的勇氣，以及為了消除代碼的“壞味道”而定期重構的習慣臂痕。
- 那么如何開始進行簡單的設計呢伯襟？XP 實踐者們也總結也一些具體的、可操作的思考方法握童。
- 首先寫測試代碼：具體將在后面詳細描述姆怪。
- 保持每個類只負責一件事：SRP（單一職責原則）是面向對象設計的基礎原則之一。
- 使用 Demeter（迪米特）法則：迪米特法則澡绩，也稱為 LoD 法則稽揭、最少知識原則。也就是指一個對象應當對其他對象盡可能少地了解肥卡。用隱喻的方法來解釋的話就是“只與你直接的朋友通信”溪掀、“不要和陌生人說話”。
- 使用 CRC 卡片進行探索步鉴。
測試先行／測試驅動開發(fā)
當我第一次看到“測試先行”這個概念的時候揪胃，我的第一感覺就是不解璃哟，陷入了“程序都還沒有寫出來，測試什么呀喊递？”的迷思沮稚。我開始天馬行空地尋求相關的隱喻，終于找到了能夠啟發(fā)我的工匠册舞，首先，我們來看看兩個不同的工匠是如何工作的吧障般。
- 工匠一：先拉上一根水平線调鲸，砌每一塊磚時，都與這跟水平線進行比較挽荡，使得每一塊磚都保持水平藐石。
- 工匠二：先將一排磚都砌完，然后再拉上一根水平線定拟，看看哪些磚有問題于微，對有問題的磚進行適當?shù)恼{整。
你會選擇哪種工作方法呢青自？你一定會罵工匠二笨吧株依！這樣多浪費時間呀季蚂！然而你自己想想雕拼，你平時在編寫程序的時候又是怎么做的呢？我們就是按工匠二的方法在工作呀焰手！甚至有時候比工匠二還笨逆瑞，是整面墻都砌完了荠藤，直接進行“集成測試”，經(jīng)常讓整面的墻倒塌获高」ぃ看到這里，你還會覺得自己的方法高明嗎念秧？這個連工匠都明白的道理淤井，自己卻畫地為牢呀。
不僅我們沒有采用工匠一的工作方法出爹，甚至有的時候程序員會以“開發(fā)工作太緊張”為理由庄吼，而忽略測試工作。但這樣卻導致了一個惡性循環(huán)严就，越是沒有空編寫測試程序总寻，代碼的效率與質量越差，花在找 Bug梢为、解決 Bug 的時間也越來越多渐行，實際產(chǎn)能大打降低轰坊。由于產(chǎn)能降低了，因此時間更緊張祟印，壓力更大肴沫。你想想，為什么不拉上一根水平線呢蕴忆？難道颤芬，我們不能夠將后面浪費的時間花在單元測試上，使得我們的程序一開始就更健壯套鹅，更加易于修改嗎站蝠？不過，編寫測試程序當然要比拉一條水平線難道多卓鹿，所以我們需要引入“自動化測試工具”菱魔，免費的 xUnit 測試框架就是你最佳的選擇。
為了鼓勵程序員原意甚至喜歡在編寫程序之前編寫測試代碼吟孙，XP 方法論還提供了許多有說服力的理由澜倦。
- 如果你已經(jīng)保持了簡單的設計，那么編寫測試代碼根本不難杰妓。
- 如果你在結對編程藻治，那么如果你想出一個好的測試代碼，那么你的伙伴一定行巷挥。
- 當所有的測試都通過的時候栋艳，你再也不會擔心所寫的代碼今后會“暗箭傷人”，那種感覺是相當棒的句各。
- 當你的客戶看到所有的測試都通過的時候吸占，會對程序充滿前所未有的信心。
- 當你需要進行重構時凿宾，測試代碼會給你帶來更大的勇氣矾屯，因為你要測試是否重構成功只需要一個按鈕。
測試先行是 XP 方法論中一個十分重要的最佳實踐初厚，并且其中所蘊含的知識與方法也十分豐富件蚕。
重構
重構時一種對代碼進行改進而不影響功能實現(xiàn)的技術，XP 需要開發(fā)人員在聞到代碼的壞味道時产禾，有重構代碼的勇氣排作。重構的目的是降低變化引發(fā)的風險，使得代碼優(yōu)化更加容易亚情。通常重構發(fā)生在兩種情況之下妄痪。
- 實現(xiàn)某個特性之前：嘗試改變現(xiàn)有的代碼結構，以使得實現(xiàn)新的特性更加容易楞件。
- 實現(xiàn)某個特性之后：檢查剛剛寫完的代碼后衫生，認真檢查一下裳瘪，看是否能夠進行簡化。
在《重構》一書中罪针，作者 Martin Fowler 提示我們：在考慮重構時彭羹，應該要養(yǎng)成編寫并經(jīng)常運行測試代碼的習慣；要先編寫代碼泪酱，再進行重構派殷；把每一次增加功能都當做一次重構的好時機；將每一個糾正錯誤當做一次重構的重要時機墓阀。同時愈腾，該書中也列出大量需要重構的情況和重構方法。
最后類似地岂津，給還沒有足夠勇氣進行重構的程序員打幾劑強心針：
- XP 提倡集體代碼所有制，因此你可以大膽地在任何需要修改的地方做改動悦即。
- 由于在 XP 項目組中有完整的編碼標準吮成，因此在重構前無須重新定義格式。
- 在重構中遇到困難辜梳，和你結對編程的伙伴能夠為你提供有效的幫助粱甫。
- 簡單的設計，會給重構帶來很大的幫助作瞄。
- 測試先行讓你擁有了一個有效的檢驗器茶宵，隨時運行一下就知道你重構的工作是否帶來了影響。
- 由于 XP 在持續(xù)集成宗挥，因此你重構所帶來的破壞很快就能夠暴露乌庶，并且得以解決。
重構技術是對簡單性設計的一個良好的補充契耿，也是 XP 中重視“優(yōu)質工作”的體現(xiàn)瞒大，這也是優(yōu)秀的程序員必備的一項技能。
結對編程
“什么搪桂！兩個人坐在一起寫程序透敌？那豈不是對人力的巨大浪費嗎？而且我在工作時可不喜歡有一個人坐在邊上當檢察官踢械⌒锏纾”是的，正如這里列舉出來的問題一樣内列，結對編程技術還是被很多人質疑的撵术。
不過，自從 20 世紀 60 年代话瞧，就有類似的實踐在進行荷荤，長期以來的研究結果卻給出了另外一番景象退渗，那就是結對編程的效率反而比單獨編程更高。一開始雖然會犧牲一些速度蕴纳，但慢慢的会油，開發(fā)速度會逐漸加快，究其原因古毛，主要是結對編程大打降低了溝通的成本翻翩，提供了工作的質量，具體表現(xiàn)在：
- 所有的設計決策確保不是由一個人做出的稻薇。
- 系統(tǒng)的任何一個部分都肯定至少有 2 個人以上熟悉嫂冻。
- 幾乎不可能有 2 個人都忽略的測試項或者其他任務
- 結對組合的動態(tài)性，是一個企業(yè)知識管理的好途徑塞椎。
- 代碼總是能夠保證被評審過桨仿。
- 而且 XP 方法論集成的其他最佳實踐也能夠使得結對編程更加容易進行：
- 編碼標準可以消除一些無謂的分歧。
- 隱喻可以幫助結對伙伴更好地溝通案狠。
- 簡單設計可以使得結對伙伴更了解他們所從事的工作服傍。
結對編程技術被譽為 XP 保持工作質量、強調人文主義的一個典型的實踐骂铁，應用得當還能夠使得開發(fā)團隊之前的協(xié)作更加流暢吹零、知識交流與共享更加頻繁，團隊的穩(wěn)定性也會更加穩(wěn)固拉庵。
集體代碼所有制
由于 XP 方法論鼓勵團隊進行結對編程灿椅，而且認為結對編程的組合應該動態(tài)地搭配，根據(jù)任務的不同钞支、專業(yè)技能的不同進行最優(yōu)組合茫蛹。由于每個人都肯定會遇到不同的代碼，所以代碼的所有制就不再適合于私有烁挟，因為那樣會給修改工作帶來巨大的不便麻惶。
也就是說，團隊中的每個成員都擁有對代碼進行改進的權利信夫，每個人都擁有全部代碼窃蹋，也都需要對全部代碼負責。同時静稻，XP 強調代碼是誰破壞的（也就是修改后發(fā)生問題）警没，就應該由誰來修復。
由于在 XP 中振湾，有一些與之匹配的最佳實踐杀迹，因此你并無須擔心采用集體代碼所有制會讓你的代碼變得越來越亂：
- 由于在 XP 項目中，集成工作是一件經(jīng)常性得工作押搪，因此當有人修改代碼而帶來了集成的問題树酪，會在很快的時間內被發(fā)現(xiàn)浅碾。
- 由于每一個類都會有一個測試代碼，因此不論誰修改了代碼续语，都需要運行這個測試代碼垂谢，這樣偶然性的破壞發(fā)生的概率將很小。
- 由于每一個代碼的修改就是通過了結對的兩個程序員共同思考疮茄，因此通常做出的修改都是對系統(tǒng)有益的滥朱。
- 由于大家都堅持了相同的編碼標準，因此代碼的可讀性力试、可修改性都會比較好徙邻，而且還能夠避免由于命名法、縮進等小問題引發(fā)經(jīng)常性得代碼修改畸裳。
集成代碼所有制是 XP 與其他敏捷方法的一個較大不同缰犁，也是從另一個側面體現(xiàn)了 XP 中蘊含的很深厚的編碼情節(jié)。
持續(xù)集成
在前面談到小型發(fā)布怖糊、重構帅容、結對編程、集體代碼所有制等最佳實踐的時候蓬抄，我們多次看到“持續(xù)集成”的身影，可以說持續(xù)集成是對這些最佳實踐的基本支撐條件夯到。
可能大家會對持續(xù)集成與小型發(fā)布代表的意思混淆不清嚷缭，其實小型發(fā)布是指在開發(fā)周期經(jīng)常發(fā)布中間版本，而持續(xù)集成的含義則是要求 XP 團隊每天盡可能多次地做代碼集成耍贾，每次都在確保系統(tǒng)運行的單元測試通過之后進行阅爽。
這樣，就可以及早地暴露荐开、消除由于重構付翁、集體代碼所有制所引入的錯誤，從而減少解決問題的痛苦
要在開發(fā)過程中做到持續(xù)集成并不容易晃听，首先需要養(yǎng)成這個習慣百侧。而且集成工作往往是十分枯燥、煩瑣的能扒，因此適當?shù)匾朊咳占晒ぞ呤鞘直匾挠犊省P 建議大家首先使用配置管理服務器將代碼管理起來，然后使用 Ant 或 Nant 等 XP 工具初斑，編寫集成腳本辛润，調用 xUint 等測試框架，這樣就可以實現(xiàn)每當程序員將代碼 Check in 到配置服務器上時见秤，Ant 就會自動完成編譯和集成砂竖，并調用測試代碼完成相應的測試工作真椿。
每周工作 40 小時／可持續(xù)的速度
這是最讓開發(fā)人員開心的、管理者反對的一個最佳實踐了乎澄，加班突硝、再加班早已成為開發(fā)人員的家常便飯，也是管理者最常使用的一種策略三圆，而 XP 方法論認為狞换，加班最終會扼殺團隊的積極性，最終導致項目失敗舟肉，這也充分體現(xiàn)了 XP 方法關注人的因素比關注過程的因素更多一些修噪。
Kent Beck 認為開發(fā)人員即使能夠工作更長的時間，他們也不該這樣做路媚，因為這樣做會使他們更容易厭倦編程工作黄琼，從而產(chǎn)生一些影響他們效能的其他問題。因此整慎，每周工作 40 小時是一種順勢行為脏款，是一種規(guī)律。其實對于開發(fā)人員和管理者來說裤园，違反這種規(guī)律是不值得的撤师。
- 開發(fā)人員：如果不懂得休息，那么就無法將自己的節(jié)奏調整到最佳狀態(tài)拧揽，那么就會帶來很大的負面影響剃盾。而且在精神不集中的狀態(tài)下，開發(fā)質量也得不到保證淤袜。
- 管理者：也許這可以稱得上“第二種人月神話”痒谴，那就是你不得不通過延長每天的工作時間來獲得更多的人月。這是因為铡羡，每個開發(fā)人員的工作精力是有限的积蔚，不可能無限增長，在精力不足的時候烦周，不僅寫出來的代碼質量沒有保障尽爆，而且還可能為項目帶來退步的效果。因此采用加班的方式并不是一個理性的方式读慎，是得不償失的教翩。
不過有一點是需要解釋的，“每周工作 40 小時”中的 40 不是一個絕對數(shù)贪壳，它所代表的意思是團隊應該保證按照“正常的時間”進行工作饱亿。那么如何做到這一點呢？
- 首先，定義符合你團隊情況的“正常工作時間”彪笼。
- 其次钻注，逐步將工作時間調整到“正常工作時間”。
- 再次配猫，除非你的時間計劃一團糟幅恋，否則不應該在時間妥協(xié)。
- 最后泵肄，鼓起勇氣捆交，制定一個合情合理的時間表。
正如米盧說過的“享受足球”一樣腐巢，同樣地品追，每一個開發(fā)人員應該做到“享受編程”，那么“每周工作 40 小時”就是你的起點冯丙。
團隊只有持久才有獲勝的希望肉瓦。他們以能夠長期維持的速度努力工作，他們保存精力胃惜，他們把項目看作是馬拉松長跑泞莉，而不是全速短跑。
現(xiàn)場客戶
為了保證開發(fā)出來的結果與客戶的預想接近船殉，XP 方法論認為最重要的需要將客戶請到開發(fā)現(xiàn)場鲫趁。就像計劃游戲中提到過的，在 XP 項目中利虫，應該時刻保證客戶負責業(yè)務決策挨厚，開發(fā)團隊負責技術決策。因此列吼，在項目中有客戶在現(xiàn)場明確用戶故事幽崩，并做出相應的業(yè)務決策苦始，對于 XP 項目而言有著十分重要的意義寞钥。
也許有人會問，客戶提交了用戶故事之后不就完成工作了嗎陌选？其實很多嘗試過用戶故事的團隊都會發(fā)現(xiàn)其太過簡單理郑，包含的信息量極少，XP方法論不會不了解咨油，因此您炉，不會把用戶故事當做開發(fā)人員交付代碼的唯一指示。用戶故事只是一個起點役电，后面的細節(jié)還需要開發(fā)人員與客戶之間建立起來的良好溝通來補充赚爵。
作為一名有經(jīng)驗的開發(fā)人員，絕對不會對現(xiàn)場客戶的價值產(chǎn)生任何懷疑，但是都會覺得想要實現(xiàn)現(xiàn)場客戶十分困難冀膝。要實現(xiàn)這一點唁奢，需要對客戶進行溝通，讓其明白窝剖，想對于開發(fā)團隊麻掸，項目成功對于客戶而言更為重要。而現(xiàn)場客戶則是保障項目成功的一個重要措施赐纱，想想在你裝修房子的時候脊奋，你是不是常常在充當現(xiàn)場客戶的角色呢？其實這隱喻就是讓客戶理解現(xiàn)場客戶重要性最好的突破口疙描。
其實現(xiàn)場客戶在具體實施時诚隙，也不是一定需要客戶一直和開發(fā)團隊在一起，而是在開發(fā)團隊應該和客戶能夠隨時溝通淫痰，可以是面談最楷，可以是在線聊天，可以是電話待错，當然面談是必不可少的籽孙。其中的關鍵是當開發(fā)人員需要客戶做出業(yè)務決策是，需要進一步了解業(yè)務細節(jié)時能夠隨時找到相應的客戶火俄。
不過犯建，也有一些項目是可以不要現(xiàn)場客戶參與的：
- 當開發(fā)組織中已經(jīng)有相關的領域專家時。
- 當做一些探索性工作瓜客，而且客戶也不知道他想要什么時（例如新產(chǎn)品适瓦、新解決方案的研究與開發(fā)）。
去嘗試吧谱仪，現(xiàn)場客戶不僅可以爭取得到玻熙，而且還能使得團隊煥然一新，與客戶建立起良好的合作與信任疯攒。
編碼標準
編碼標準是一個“雅俗共享”的最佳實踐嗦随，不管是代表重型方法論的 RUP，PSP敬尺，還是代表敏捷方法論的 XP枚尼，都認為開發(fā)團隊應該擁有一個編碼標準。XP 方法論認為擁有編碼標準可以避免團隊在一些與開發(fā)進度無關的細節(jié)問題上發(fā)生爭論砂吞，而且會給重構署恍、結對編程帶來很大麻煩。試想如果有人將你上次寫的代碼的變量命名法做了修改蜻直，下次你需要再改這部分代碼時盯质，會是一種什么感覺呢袁串？
不過，XP 方法論的編碼標準的目的不是創(chuàng)建一個事無巨細的規(guī)則表呼巷，而是只要能夠提供一個確保代碼清晰般婆，便于交流的指導方針。
如果你的團隊已經(jīng)擁有編碼標準朵逝，就可以直接使用它蔚袍，并在過程中進行完善。如果還沒有配名，那么大家可以先進行編碼啤咽，然后在過程中逐步總結出編碼規(guī)則，邊做邊形成渠脉。當然除了這種文字規(guī)范以外宇整，還可以采用一些如自動格式化代碼工具之類的方法進行代碼規(guī)范。芋膘，事實上鳞青，你只需要很好地貫徹執(zhí)行其他的實踐并且進行溝通，編碼標準會很容易地浮現(xiàn)出來为朋。
配合是關鍵
有句經(jīng)典名言“1+1 > 2 ”最適合表達 XP 的觀點臂拓，Kent Beck 認為 XP 方法論的最大價值在于在項目中融會貫通地運用12個最佳實踐，而非單獨地使用习寸。你當然可以使用其中的一些實踐胶惰，但這并不意味著你就運用了 XP 方法論。XP 方法論真正能夠發(fā)揮其效能霞溪，就必須完整地運用12個實踐孵滞。
