作為敏捷軟件開發(fā)領(lǐng)域主流的開發(fā)方法，極限編程與其說是一種系統(tǒng)的方法學(xué)，倒更像是一系列最佳實踐的有機(jī)結(jié)合。在這些最佳實踐中，有些是已經(jīng)廣為人們所接受的（如編碼標(biāo)準(zhǔn)），而更多的則極具顛覆性，初看之下讓人似乎難以接受。

本文中，我將針對這些看似怪異的最佳實踐闡述我的觀點，并簡述我對實施這些最佳實踐的一些思考。

一、計劃游戲

能夠把計劃叫做“游戲”是需要一定勇氣的。在傳統(tǒng)的軟件開發(fā)方法學(xué)中，計劃是舉足輕重的一環(huán)，在制訂計劃前需要仔細(xì)的估算，在計劃實施的過程中，還要不停的跟蹤、修正，直至整個項目完成。

而在XP中，計劃似乎要輕松許多。這并不是因為計劃本身變得草率和無關(guān)痛癢，而是得益于XP的小版本發(fā)布思維。軟件的一個版本是如此短小簡單，以至于對它進(jìn)行完整的評估、預(yù)算、跟蹤和修正要容易許多。事實上，XP中采用的計劃方式（業(yè)務(wù)人員和開發(fā)人員共同參與，各司其職）在大多數(shù)現(xiàn)代軟件企業(yè)中早已采用，但是由于項目過于龐大，很難在開始階段制訂出完善的計劃。而在XP中，人們只需要針對一個一兩個月的小項目進(jìn)行跟蹤和管理，無形中降低了計劃的風(fēng)險。

二、隱喻

    在XP中，人們經(jīng)常會使用隱喻來代替?zhèn)鹘y(tǒng)開發(fā)過程中的體系結(jié)構(gòu)設(shè)計。從指導(dǎo)開發(fā)的角度來說，隱喻似乎不夠精確，容易讓人誤解。但是，對于具有類似背景的同一個項目組中的開發(fā)人員來說，隱喻則更便于理解和交流。很難想象兩個程序員面對著一張龐大的體系結(jié)構(gòu)圖時能夠真正有效的溝通，而隱喻很好的解決了這個問題。

三、簡單設(shè)計

不知道從什么時候開始，開發(fā)人員習(xí)慣了為明天而設(shè)計。一個開發(fā)人員設(shè)計了一個復(fù)雜的類繼承結(jié)構(gòu)，只是為了提高程序的所謂靈活性。沒人知道這樣值不值，并不是軟件的每一個部分都需要擴(kuò)展。但是，對于傳統(tǒng)的軟件開發(fā)人員來說，這么做又是迫不得已。如果沒有預(yù)先做好準(zhǔn)備，在變化來臨時就會措手不及，付出沉重的代價。

但是在XP中，小版本發(fā)行的方法使得變化并不那么可怕，而重構(gòu)的廣泛采用，使得代碼總是可以在需要時變得更加靈活。此外，由于你的代碼總是會被別人審查（代碼集體所有權(quán)和結(jié)對編程），因此也可以避免過于追求簡單而忽視了重要的細(xì)節(jié)。

四、測試優(yōu)先

沒有代碼要測試程序有什么用？這是測試優(yōu)先最容易讓人誤解的地方。測試優(yōu)先能夠讓開發(fā)人員更清楚的認(rèn)識到，程序?qū)绾伪皇褂谩Ｍㄟ^對不同的測試用例的思考，開發(fā)人員也能夠更清晰的認(rèn)識到程序的功能外延。而更多的其他的開發(fā)人員，則通過測試用例就可以獲得一份精確的使用手冊，在這份使用手冊中，描述了作者考慮到的所有輸入和輸出結(jié)果，這樣不僅便于人們了解程序，更增加了發(fā)現(xiàn)程序錯誤的機(jī)會（缺失的測試用例往往體現(xiàn)出作者忽視的某些使用情況）。

五、結(jié)對編程

兩個程序員坐在一起，能夠提高開發(fā)效率嗎？程序員難道不是一群高傲的貓，習(xí)慣于離群索居，把頭抬得高高嗎？

事實并非如此。在一個正確的、合理的、能夠?qū)崿F(xiàn)的大目標(biāo)下，程序員們不僅能夠和平共處，更可以相互合作，創(chuàng)造出優(yōu)秀的、高質(zhì)量的程序。溝通一直是軟件項目管理中的一個重要議題，而結(jié)對編程提供了一個十分有效的溝通渠道。此外，結(jié)對編程也更容易讓新人融入團(tuán)體。在幾個高級程序員的指引下，他會更容易找出程序的脈絡(luò)，把握程序的思想。較之正規(guī)的培訓(xùn)，這種方式更輕松也更有效。對于團(tuán)隊中的所有程序員來說，結(jié)對編程都是一個了解其他人設(shè)計思想的機(jī)會，通過結(jié)對編程，能夠更好的實現(xiàn)代碼集體所有權(quán)，也能夠降低因為人員流動造成的風(fēng)險。

結(jié)對編程最大的好處在于，能夠極大的減少程序中潛在變化的可能性。兩個人通過交流互相交換自己對程序的不同理解，更容易找出程序中可能出現(xiàn)的變化或錯誤，從而使程序更加可靠和健壯。

六、持續(xù)集成

集成一直是最費(fèi)力的工作之一，本來工作的好好的代碼，放在一起就不能運(yùn)轉(zhuǎn)，更糟糕的是成百上千條不知所云的錯誤碼，沒有人知道這些錯誤碼來自何處。這是每個項目幾乎都會遇到的最困難的階段，程序員們必須集合在一起，翻閱數(shù)量巨大的接口定義文件，反復(fù)查看代碼，同時還要不斷的做出承諾。

持續(xù)集成正是解決上述問題的方法。通過多次、小增量的集成，我們總是能夠以最快的速度定位錯誤出現(xiàn)的位置（因為增加的代碼很少），結(jié)合大量測試用例，我們也可以確保每一個集成版本都盡可能的可靠。

此外，持續(xù)集成幾乎可以在任何時間向我們提供一個可以工作的版本，我們可以將這個版本用于內(nèi)部討論和測試、客戶展示、客戶測試、小版本發(fā)布等等，這使得我們不需要花費(fèi)太多的時間對現(xiàn)有的程序修修補(bǔ)補(bǔ)，以生成一個demo。

上文簡單敘述了XP中常會引起爭議的六個最佳實踐的優(yōu)點。下面本文將結(jié)合實際談?wù)剬嵤P中需要注意的一些問題。

一、適用性問題

XP理論在提出時，明確的說明：XP是適用于中小型團(tuán)隊在需求不明確或者迅速變化的情況下進(jìn)行軟件開發(fā)的輕量級方法。這就意味著，XP并不適用于所有情況。在準(zhǔn)備實施XP前，你也許需要仔細(xì)評估項目的具體情況，以決定是否真的需要采用XP。

二、最佳實踐間的關(guān)聯(lián)

XP的一個特點是，它所推崇的最佳實踐幾乎總是和其它實踐關(guān)聯(lián)緊密，在實施一項最佳實踐時，如果不同時實施其它實踐，往往難以達(dá)到最初的目的。因此，在實施XP時，需要仔細(xì)研究各項實踐間的關(guān)聯(lián)，以確定最佳的實施方案。

三、寬松的環(huán)境

XP是一種追求自然的工作方法。它所倡導(dǎo)的是，程序員們以最自然開發(fā)的方式完成他們的工作。對于習(xí)慣了傳統(tǒng)開發(fā)方法嚴(yán)格管理制度的管理人員來說，這往往是很難接受的。于是就出現(xiàn)了，雖然最高決策人決定實施XP，但管理層卻無法（或不愿）給開發(fā)人員提供寬松的環(huán)境。在一個古板僵化的方框里，開發(fā)人員不會真正的回復(fù)自然，他們會裝作正在實踐XP，但事實上，他們依然在老路上行走（可以見到很多這樣的例子，比如一些虛張聲勢的測試用例等等）。

四、忍受變化

XP對于傳統(tǒng)軟件項目管理思想的沖擊，可能會使很多管理人員感到不舒服。也許XP一經(jīng)實施，就會給項目組帶來翻天覆地的變化。如果這樣的變化讓你感到恐懼，那么請暫時忍耐，你不能肯定這種變化不好，除非你親眼看到。到那時再決定也不遲。

五、慢慢來

實施XP的過程不能操之過急。最好的方法是，在部分項目組中先行實施，實施時也不需要同時實施所有實踐（但要注意各個實踐間的關(guān)聯(lián)問題）。有的時候你會發(fā)現(xiàn)，在實施了部分實踐后，其它的實踐也成為水到渠成的事情。當(dāng)經(jīng)過仔細(xì)評估，確信XP在項目組中確實有效后，再逐步在企業(yè)范圍內(nèi)推廣，必要的時候，需要采取自愿的原則，由項目組的成員決定是否需要實施XP。

以上即是我在軟件工程過程課程中以及平時工作、學(xué)習(xí)中對XP的一些認(rèn)識。

來源： http://blog.csdn.net/leasun/archive/2006/08/15/1067508.aspx