eXtreme Programming 極限編程-XP

XP概述

XP是一種輕量（敏捷）、高效、低風(fēng)險(xiǎn)、柔性、可預(yù)測(cè)、科學(xué)而且充滿樂趣的軟件開發(fā)方式。在以前的開發(fā)過程中，很多規(guī)則已經(jīng)難于遵循，很多流程復(fù)雜而難于理解，很多項(xiàng)目中文檔的制作過程正在失去控制。人們?cè)噲D提出更全面更好的一攬子方案，或者寄希望于更復(fù)雜的、功能更強(qiáng)大的輔助開發(fā)工具（CaseTools），但總是不能成功，而且開發(fā)規(guī)范和流程變得越來越復(fù)雜和難以實(shí)施。XP就是在這樣的情況下誕生的，它是靈巧的輕量級(jí)軟件開發(fā)方法，它跳出復(fù)雜的流程和文檔，而是以輕量的框架和極限的思想為核心進(jìn)行開發(fā)。

這里講的極限編程更像是一套理論知識(shí)，面向開發(fā)人員的指導(dǎo)，甚至是考核開發(fā)人員素質(zhì)或者說優(yōu)異程度的一個(gè)思想指標(biāo)。雖然以下理論看起來難免枯燥無味，但是真正想了解敏捷開發(fā)的一些知識(shí)的還是需要好好閱讀一下。我個(gè)人甚至覺得，XP提出的一些價(jià)值，原則，實(shí)踐，可以用來培訓(xùn)一些開發(fā)新手，成為一套有理論依據(jù)的準(zhǔn)則。當(dāng)然，這樣的準(zhǔn)則還是需要根據(jù)情況調(diào)整，而不是生搬硬套。

（文章理論上的東西比較多，不好消化，需要思考理解，如果讀者是快餐式閱讀，建議不要浪費(fèi)時(shí)間）

4大價(jià)值

溝通

XP方法論認(rèn)為，如果小組成員之間無法做到持續(xù)的、無間斷的交流，那么協(xié)作就無從談起，從這個(gè)角度能夠發(fā)現(xiàn)，通過文檔、報(bào)表等人工制品進(jìn)行交流面臨巨大的局限性。因此，XP組合了諸如對(duì)編程這樣的最佳實(shí)踐，鼓勵(lì)大家進(jìn)行口頭交流，通過交流解決問題，提高效率。

簡(jiǎn)單

XP方法論提倡在工作中秉承“夠用就好”的思路，也就是盡量地簡(jiǎn)單化，只要今天夠用就行，不考慮明天會(huì)發(fā)現(xiàn)的新問題。這一點(diǎn)看上去十分容易，但是要真正做到保持簡(jiǎn)單的工作其實(shí)很難的。因?yàn)樵趥鹘y(tǒng)的開發(fā)方法中，都要求大家對(duì)未來做一些預(yù)先規(guī)劃，以便對(duì)今后可能發(fā)生的變化預(yù)留一些擴(kuò)展的空間。

反饋

反饋在團(tuán)隊(duì)合作中是非常重要的，不僅是客戶與項(xiàng)目負(fù)責(zé)人之間的反饋，還應(yīng)該包括開發(fā)人員在內(nèi)，做到項(xiàng)目所有相關(guān)人自覺的反饋，讓他人知道項(xiàng)目進(jìn)度，每個(gè)開發(fā)人員任務(wù)完成情況，做到人人都能及時(shí)知道項(xiàng)目的情況，人員的情況。這樣所有人都能心里有數(shù)，才能做到相互配合，有效的溝通。

勇氣

要知道，XP是提倡擁抱變化的，那么要積極響應(yīng)變化就需要相關(guān)相關(guān)人員，特別是開發(fā)人員有勇氣來面對(duì)快速開發(fā)，重新開發(fā)，代碼重構(gòu)等情況，快速開發(fā)需要勇于面對(duì)更多h3ug，將一些h3ug留到下一版，重新開發(fā)要敢于廢棄之前的努力，不要因?yàn)橐呀?jīng)開發(fā)出來了即使沒有什么用處也要使用，重構(gòu)則是要勇于改變現(xiàn)狀，讓代碼脫胎換骨。

5個(gè)原則

快速反饋

及時(shí)地、快速地獲取反饋，并將所學(xué)到的知識(shí)盡快地投入到系統(tǒng)中去。也就是指開發(fā)人員應(yīng)該通過較短的反饋循環(huán)，迅速地了解現(xiàn)在的產(chǎn)品是否滿足了客戶的需求。也就是需要我們持續(xù)交付，調(diào)整功能，這也是對(duì)反饋這一價(jià)值觀的進(jìn)一步補(bǔ)充?？焖俜答佂瑯舆m用于開發(fā)人員之間，團(tuán)隊(duì)人員之間，及時(shí)反饋，有效溝通。

簡(jiǎn)單性假設(shè)

類似地，簡(jiǎn)單性假設(shè)原則是對(duì)簡(jiǎn)單這一價(jià)值觀的進(jìn)一步補(bǔ)充。這一原則要求開發(fā)人員將每個(gè)問題都看得十分容易解決，也就是說只為本次迭代考慮，不去想未來可能需要什么，相信具有將來必要時(shí)增加系統(tǒng)復(fù)雜性的能力，也就是號(hào)召大家出色地完成今天的任務(wù)。這點(diǎn)下文還會(huì)繼續(xù)說明。

逐步修改

就像開車打方向盤一樣，不要一次做出很大的改變，那樣將會(huì)使得可控性變差，更適合的方法是進(jìn)行微調(diào)。而在軟件開發(fā)中，這樣的道理同樣適用，任何問題都應(yīng)該通過一系列能夠帶來差異的微小改動(dòng)來解決。

提倡更改

在軟件開發(fā)過程中，在解決最重要問題時(shí)，盡量為下一次修改做好準(zhǔn)備。開發(fā)不息，h3ug不斷，我們都要打從心里明白，h3ug是不可能有完全修改完的一天的，所以需要不斷進(jìn)行更改，也不要守著最初的方案，不敢做任何變動(dòng)，要為隨時(shí)可能到來的改動(dòng)做好心里準(zhǔn)備。

優(yōu)質(zhì)工作

在實(shí)踐中，經(jīng)?？吹皆S多開發(fā)人員喜歡將一些細(xì)小的問題留待后面解決。例如，界面的按鈕有一些不平整，由于不影響使用就先不管；某一兩個(gè)成員函數(shù)暫時(shí)沒用就不先寫等。這就是一種工作拖泥帶水的現(xiàn)象，這樣的壞習(xí)慣一旦養(yǎng)成，必然使得代碼質(zhì)量大打折扣。而在XP方法論中，貫徹的是“小步快走”的開發(fā)原則，因此工作質(zhì)量決不可打折扣，通常采用測(cè)試先行的編碼方式來提供支持。

總結(jié)

優(yōu)質(zhì)工作這點(diǎn)是個(gè)人自覺問題，特別體現(xiàn)開發(fā)人員的個(gè)人素質(zhì)，拖泥帶水這個(gè)問題經(jīng)常出現(xiàn)在進(jìn)度比較趕的情況下，但PM或者leader也不能在這點(diǎn)上面妥協(xié)，而且一般這種問題也不會(huì)消耗很多開發(fā)時(shí)間，都是一兩句代碼的事，有時(shí)只是開發(fā)人員懶得去修改而已。一旦妥協(xié)，以后這種情況必然反復(fù)出現(xiàn)。逐步修改這點(diǎn)除了開發(fā)人員實(shí)現(xiàn)，同時(shí)還需PM來配合，在迭代中進(jìn)行微調(diào)，將更改控制在可控范圍，不會(huì)造成太大影響。

13個(gè)最佳實(shí)現(xiàn)

計(jì)劃游戲

計(jì)劃游戲的主要思想就是先快速地制定一份概要的計(jì)劃，然后隨著項(xiàng)目細(xì)節(jié)的不斷清晰，再逐步完善這份計(jì)劃。計(jì)劃游戲產(chǎn)生的結(jié)果是一套用戶故事及后續(xù)的一兩次迭代的概要計(jì)劃。

編寫故事：由客戶或者PM談?wù)撓到y(tǒng)應(yīng)該完成什么功能，確定需求。

進(jìn)行估算：開發(fā)人員對(duì)每個(gè)用戶故事進(jìn)行估算，先從高優(yōu)先級(jí)開始估算。如果在估算的時(shí)候，感到有一些故事太大，不容易進(jìn)行估算，或者是估算的結(jié)果超過2人/周，那么就應(yīng)該對(duì)其進(jìn)行分解，拆成2個(gè)或者多個(gè)小故事。

迭代周期：接下來就是確定本次迭代的時(shí)間周期，這可以根據(jù)實(shí)際的情況進(jìn)行確定，不過最佳的迭代周期是2~3周。

小型發(fā)布

XP方法論秉承的是“持續(xù)集成，小步快走”的哲學(xué)，也就是說每一次發(fā)布的版本應(yīng)該盡可能的小，當(dāng)然前提條件是每個(gè)版本有足夠的商業(yè)價(jià)值，值得發(fā)布。

由于小型發(fā)布可以使得集成更頻繁，客戶獲得的中間結(jié)果也越頻繁，反饋也就越頻繁，客戶就能夠?qū)崟r(shí)地了解項(xiàng)目的進(jìn)展情況，從而提出更多的意見，以便在下一次迭代中計(jì)劃進(jìn)去。以實(shí)現(xiàn)更高的客戶滿意度。

隱喻

創(chuàng)造心照不宣的詞匯和列子，更形象有趣的溝通。比喻有時(shí)候更能讓人更快更好的理解你的意思，而不是一堆晦澀專業(yè)術(shù)語(yǔ)。

簡(jiǎn)單設(shè)計(jì)

簡(jiǎn)單設(shè)計(jì)這個(gè)實(shí)現(xiàn)是一個(gè)很容易讓人誤解，也讓許多批評(píng)者詬病的一條實(shí)現(xiàn)，因?yàn)樗小皦蛴镁秃谩钡乃悸?，盡量地簡(jiǎn)單化，只要今天夠用就行，不考慮明天會(huì)發(fā)現(xiàn)的新問題，明明是擁抱變化，怎么又不考慮明天的問題了呢。而在傳統(tǒng)的開發(fā)中，需要我們考慮后期可能的需求，讓代碼做到高可擴(kuò)展性，要求我們經(jīng)?？紤]后期需求。這樣看起來，傳統(tǒng)開發(fā)在這個(gè)方面似乎比XP更貼近擁抱變化的思想，我們?cè)僮屑?xì)看看。

這里的簡(jiǎn)單設(shè)計(jì)提出沒有重復(fù)代碼，盡量少的類和方法，使用迪米特法則等，只是針對(duì)今天而言，不要因?yàn)楹笃诳赡軙?huì)用到，就添加了一個(gè)現(xiàn)在不用的類或者方法，而不是不做可擴(kuò)展性，這兩者并不沖突。即使因?yàn)闆]有考慮很多，而可拓展性沒有做到很好，XP提倡重構(gòu)也能將擴(kuò)展性提高一個(gè)檔次，而且更精確更符合現(xiàn)在的需求。而傳統(tǒng)的方式將一切考慮到位也不見得擴(kuò)展性就完美，畢竟變化是不可預(yù)測(cè)的，現(xiàn)在考慮的擴(kuò)展性在幾個(gè)月后可能也用不上了，到時(shí)必然也是要重構(gòu)。

簡(jiǎn)單設(shè)計(jì)從本質(zhì)上來說擴(kuò)展性就很強(qiáng)，就像一張白紙，要怎么畫都行，就看你能不能體會(huì)到其中的深度了。

測(cè)試驅(qū)動(dòng)開發(fā)

這個(gè)是常規(guī)思維難以理解的概念，測(cè)試先行，程序都沒寫出了，怎么測(cè)試？參考資料的例子非常好：

• 工匠一：先拉上一根水平線，砌每一塊磚時(shí)，都與這跟水平線進(jìn)行比較，使得每一塊磚都保持水平。
• 工匠二：先將一排磚都砌完，然后再拉上一根水平線，看看哪些磚有問題，對(duì)有問題的磚進(jìn)行適當(dāng)?shù)恼{(diào)整。

工匠一代表的就是測(cè)試驅(qū)動(dòng)開發(fā)的方法，當(dāng)然為了有效的實(shí)現(xiàn)它，需要我們借助一些自動(dòng)化測(cè)試工具。

XP鼓勵(lì)程序員原意甚至喜歡在編寫程序之前編寫測(cè)試代碼，所以提供了以下一些理由：

• 如果你已經(jīng)保持了簡(jiǎn)單的設(shè)計(jì)，那么編寫測(cè)試代碼根本不難。
• 如果你在結(jié)對(duì)編程，那么如果你想出一個(gè)好的測(cè)試代碼，那么你的伙伴一定行。
• 當(dāng)所有的測(cè)試都通過的時(shí)候，你再也不會(huì)擔(dān)心所寫的代碼今后會(huì)“暗箭傷人”，那種感覺是相當(dāng)棒的。
• 當(dāng)你的客戶看到所有的測(cè)試都通過的時(shí)候，會(huì)對(duì)程序充滿前所未有的信心。
• 當(dāng)你需要進(jìn)行重構(gòu)時(shí)，測(cè)試代碼會(huì)給你帶來更大的勇氣，因?yàn)槟阋獪y(cè)試是否重構(gòu)成功只需要一個(gè)按鈕。

這樣的嘗試還是需要勇氣的，這也是XP的核心價(jià)值，不真正去使用去理解，一般人都會(huì)覺得天馬行空。

重構(gòu)

重構(gòu)時(shí)一種對(duì)代碼進(jìn)行改進(jìn)而不影響功能實(shí)現(xiàn)的技術(shù)，XP需要開發(fā)人員在聞到代碼的壞味道時(shí)，有重構(gòu)代碼的勇氣。重構(gòu)的目的是降低變化引發(fā)的風(fēng)險(xiǎn)，使得代碼優(yōu)化更加容易。重構(gòu)有時(shí)并不是需要做很大的修改，不用談虎色變，對(duì)于XP來說，它只是一個(gè)常規(guī)操作。

結(jié)對(duì)編程

簡(jiǎn)單來說就是兩個(gè)人坐在一起寫程序，結(jié)對(duì)編程也是一個(gè)飽受質(zhì)疑的舉措，一般認(rèn)為它過于耗費(fèi)人力資源，自尊心較強(qiáng)的開發(fā)人員也比較排斥結(jié)對(duì)編程。

當(dāng)然結(jié)對(duì)編程也有結(jié)對(duì)編程的好處：

• 所有的設(shè)計(jì)決策確保不是由一個(gè)人做出的。
• 系統(tǒng)的任何一個(gè)部分都肯定至少有2個(gè)人以上熟悉。
• 幾乎不可能有2個(gè)人都忽略的測(cè)試項(xiàng)或者其他任務(wù)
• 結(jié)對(duì)組合的動(dòng)態(tài)性，是一個(gè)企業(yè)知識(shí)管理的好途徑。
• 代碼總是能夠保證被評(píng)審過。

而且XP方法論集成的其他最佳實(shí)踐也能夠使得結(jié)對(duì)編程更加容易進(jìn)行：

• 編碼標(biāo)準(zhǔn)可以消除一些無謂的分歧。
• 隱喻可以幫助結(jié)對(duì)伙伴更好地溝通。
• 簡(jiǎn)單設(shè)計(jì)可以使得結(jié)對(duì)伙伴更了解他們所從事的工作。

結(jié)對(duì)編程還是要視情況使用，并不是有理論支持的就一定適用，如果覺得使用結(jié)對(duì)效率不高，還可以通過Leader審核代碼來替代。

集體代碼所有制

由于XP方法論鼓勵(lì)團(tuán)隊(duì)進(jìn)行結(jié)對(duì)編程，而且認(rèn)為結(jié)對(duì)編程的組合應(yīng)該動(dòng)態(tài)地搭配，根據(jù)任務(wù)的不同、專業(yè)技能的不同進(jìn)行最優(yōu)組合。由于每個(gè)人都肯定會(huì)遇到不同的代碼，所以代碼的所有制就不再適合于私有，因?yàn)槟菢訒?huì)給修改工作帶來巨大的不便。

也就是說，團(tuán)隊(duì)中的每個(gè)成員都擁有對(duì)代碼進(jìn)行改進(jìn)的權(quán)利，每個(gè)人都擁有全部代碼，也都需要對(duì)全部代碼負(fù)責(zé)。同時(shí)，XP強(qiáng)調(diào)代碼是誰(shuí)破壞的（也就是修改后發(fā)生問題），就應(yīng)該由誰(shuí)來修復(fù)。

• 由于在XP項(xiàng)目中，集成工作是一件經(jīng)常性得工作，因此當(dāng)有人修改代碼而帶來了集成的問題，會(huì)在很快的時(shí)間內(nèi)被發(fā)現(xiàn)。
• 由于每一個(gè)類都會(huì)有一個(gè)測(cè)試代碼，因此不論誰(shuí)修改了代碼，都需要運(yùn)行這個(gè)測(cè)試代碼，這樣偶然性的破壞發(fā)生的概率將很小。
• 由于每一個(gè)代碼的修改就是通過了結(jié)對(duì)的兩個(gè)程序員共同思考，因此通常做出的修改都是對(duì)系統(tǒng)有益的。
• 由于大家都堅(jiān)持了相同的編碼標(biāo)準(zhǔn)，因此代碼的可讀性、可修改性都會(huì)比較好，而且還能夠避免由于命名法、縮進(jìn)等小問題引發(fā)經(jīng)常性得代碼修改。

持續(xù)集成

持續(xù)集成是指團(tuán)隊(duì)每天盡可能多次的進(jìn)行代碼集成，保證團(tuán)隊(duì)獲取的代碼都是近期統(tǒng)一過的代碼，避免太多不一致造成沖突。而上文說的小型發(fā)布則是更多的發(fā)布測(cè)試版本，中間版本，讓客戶或者PM審核，確認(rèn)功能開發(fā)沒有錯(cuò)誤。需要我們引入代碼管理工具，版本控制工具。

可持續(xù)的速度

簡(jiǎn)單來說，就是反對(duì)加班，將進(jìn)度控制在合理的范圍，讓開發(fā)人員保持一個(gè)健康高效的狀態(tài)。

做到讓開發(fā)人員享受開發(fā)，而不是讓他們感受到了煎熬。

現(xiàn)場(chǎng)客戶

為了保證開發(fā)出來的結(jié)果與客戶的預(yù)想接近，XP方法論認(rèn)為最重要的需要將客戶請(qǐng)到開發(fā)現(xiàn)場(chǎng)。就像計(jì)劃游戲中提到過的，在XP項(xiàng)目中，應(yīng)該時(shí)刻保證客戶負(fù)責(zé)業(yè)務(wù)決策，開發(fā)團(tuán)隊(duì)負(fù)責(zé)技術(shù)決策。因此，在項(xiàng)目中有客戶在現(xiàn)場(chǎng)明確用戶故事，并做出相應(yīng)的業(yè)務(wù)決策，對(duì)于XP項(xiàng)目而言有著十分重要的意義。特別是在發(fā)布中間版本后，需要客戶進(jìn)行體驗(yàn)，確保業(yè)務(wù)功能正確。

編碼標(biāo)準(zhǔn)

如果你的團(tuán)隊(duì)已經(jīng)擁有編碼標(biāo)準(zhǔn)，就可以直接使用它，并在過程中進(jìn)行完善。如果還沒有，那么大家可以先進(jìn)行編碼，然后在過程中逐步總結(jié)出編碼規(guī)則，邊做邊形成。當(dāng)然除了這種文字規(guī)范以外，還可以采用一些如自動(dòng)格式化代碼工具之類的方法進(jìn)行代碼規(guī)范。事實(shí)上，你只需要很好地貫徹執(zhí)行其他的實(shí)踐并且進(jìn)行通，編碼標(biāo)準(zhǔn)會(huì)很容易地浮現(xiàn)出來。

配合是關(guān)鍵

有句經(jīng)典名言“1+1>2”最適合表達(dá)XP的觀點(diǎn)，Kent h3eck認(rèn)為XP方法論的最大價(jià)值在于在項(xiàng)目中融會(huì)貫通地運(yùn)用12個(gè)最佳實(shí)踐，而非單獨(dú)地使用。你當(dāng)然可以使用其中的一些實(shí)踐，但這并不意味著你就運(yùn)用了XP方法論。XP方法論真正能夠發(fā)揮其效能，就必須完整地運(yùn)用12個(gè)實(shí)踐。你甚至可以跳出XP開發(fā)方法，和其他開發(fā)方法進(jìn)行結(jié)合，只要是遵循敏捷宣言的方法，必定有它們共同之處，也有能夠相互配合，更加完善的地方。

作者：Frayne，個(gè)人博客：Frayne.githuh3.io/Agile/xp.html

本文由 @Frayne 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。