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

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

一、計劃游戲

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

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

二、隱喻

    在XP中，人們經常會使用隱喻來代替傳統開發過程中的體系結構設計。從指導開發的角度來說，隱喻似乎不夠精確，容易讓人誤解。但是，對于具有類似背景的同一個項目組中的開發人員來說，隱喻則更便于理解和交流。很難想象兩個程序員面對著一張龐大的體系結構圖時能夠真正有效的溝通，而隱喻很好的解決了這個問題。

三、簡單設計

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

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

四、測試優先

沒有代碼要測試程序有什么用？這是測試優先最容易讓人誤解的地方。測試優先能夠讓開發人員更清楚的認識到，程序將會如何被使用。通過對不同的測試用例的思考，開發人員也能夠更清晰的認識到程序的功能外延。而更多的其他的開發人員，則通過測試用例就可以獲得一份精確的使用手冊，在這份使用手冊中，描述了作者考慮到的所有輸入和輸出結果，這樣不僅便于人們了解程序，更增加了發現程序錯誤的機會（缺失的測試用例往往體現出作者忽視的某些使用情況）。

五、結對編程

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

事實并非如此。在一個正確的、合理的、能夠實現的大目標下，程序員們不僅能夠和平共處，更可以相互合作，創造出優秀的、高質量的程序。溝通一直是軟件項目管理中的一個重要議題，而結對編程提供了一個十分有效的溝通渠道。此外，結對編程也更容易讓新人融入團體。在幾個高級程序員的指引下，他會更容易找出程序的脈絡，把握程序的思想。較之正規的培訓，這種方式更輕松也更有效。對于團隊中的所有程序員來說，結對編程都是一個了解其他人設計思想的機會，通過結對編程，能夠更好的實現代碼集體所有權，也能夠降低因為人員流動造成的風險。

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

六、持續集成

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

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

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

上文簡單敘述了XP中常會引起爭議的六個最佳實踐的優點。下面本文將結合實際談談實施XP中需要注意的一些問題。

一、適用性問題

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

二、最佳實踐間的關聯

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

三、寬松的環境

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

四、忍受變化

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

五、慢慢來

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

以上即是我在軟件工程過程課程中以及平時工作、學習中對XP的一些認識。

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