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