接觸極限編程一段時間，找到以下四點反駁它的理由：
[1]代碼質(zhì)量
極限編程運用測試驅(qū)動開發(fā)（TDD），其理論基礎(chǔ)是需求應(yīng)該是可測試的，其目的在于保證軟件系統(tǒng)的正確性和健壯性（測試用例足夠充分的話）。可以這么認為：極限編程關(guān)心的是結(jié)果，不關(guān)心過程。因此它忽略了軟件系統(tǒng)的結(jié)構(gòu)性和開放性。我們知道結(jié)構(gòu)性有助于修改，開放性有助于擴展，而極限編程卻放棄這種追求，導(dǎo)致的結(jié)果就是產(chǎn)生一大堆丑陋的代碼，而且隨時有可能被徹底拋棄。
極限編程解決效率，結(jié)構(gòu)性和開放性問題的對策是重構(gòu)，它宣稱重構(gòu)無處不在，但是重構(gòu)是一種補救的方式，為什么不在設(shè)計初期進行預(yù)防呢？極限編程回避不了這些問題，而只是將它們推到了后面的階段，但是付出的代價可能會更高。
[2]工作進度
極限編程直接將代碼作為文檔，弱化傳統(tǒng)文檔的作用。既然如此，那么代碼就應(yīng)該有規(guī)范的格式和詳盡的注釋，以便提高它的可讀性，但是由于極限編程采用的是團隊合作方式，代碼規(guī)范很難得到統(tǒng)一。那么通過注釋吧，可是極限編程認為注釋是一種負擔(dān)，無法適應(yīng)頻繁修改的代碼。
極限編程解決溝通問題的對策是結(jié)對編程，它認為頻繁的溝通勝過面面俱到的文檔，但是文檔是永久的，溝通卻是短暫的，大家可以看同一份文檔，卻要進行多次兩兩溝通，所需時間也許并不比寫文檔的時間少。更糟糕的是，經(jīng)常地切換搭檔將極大地破壞工作的延續(xù)性，只能拖慢進度。
[3]工作量
測試驅(qū)動開發(fā)具體應(yīng)該怎么做呢？測試驅(qū)動決不是說代碼從測試寫起，在寫測試用例之前，肯定要對需求有完整的了解，否則測試無從寫起，其實這就是需求分析以及設(shè)計，還是與瀑布模型一樣的流程，只不過沒有文檔化而已。唯一不同的是極限編程要求需求都是可測試的，因此要把這些需求翻譯成系統(tǒng)測試用例，集成測試用例，和單元測試用例。由于寫程序必須同時寫它的測試，因此如果改程序則必須改測試，這將達到兩倍的工作量。
[4]目的
極限編程認為需求是不斷變化的，因此軟件能滿足當(dāng)前需求就好，沒有必要構(gòu)造框架之類可復(fù)用的東西，它認為這是一種過度設(shè)計。這種思想是極端的，因為框架就是為了解決需求變化問題而出現(xiàn)的。舉個例子，MFC就是一套框架（盡管我厭惡它），但是基于MFC卻可以開發(fā)網(wǎng)絡(luò)，多媒體，數(shù)據(jù)庫甚至游戲應(yīng)用程序。面向?qū)ο蟮哪康木褪菫榱藦?fù)用，而且好的框架能夠做到隔離變化，依賴抽象，如果認為軟件系統(tǒng)的一切東西都是暫時的，無疑是與面向?qū)ο笏枷氡车蓝Y的。