極限編程（英語：Extreme programming，縮寫為XP），是一種軟件工程方法學(xué)，是敏捷軟件開發(fā)中應(yīng)用最為廣泛和最富有成效的幾種方法學(xué)之一。如同其他敏捷方法學(xué)，極限編 程和傳統(tǒng)方法學(xué)的本質(zhì)不同在于它更強調(diào)可適應(yīng)性而不是可預(yù)測性。極限編程的支持者認(rèn)為軟件需求的不斷變化是很自然的現(xiàn)象，是軟件項目開發(fā)中不可避免的、也 是應(yīng)該欣然接受的現(xiàn)象；他們相信，和傳統(tǒng)的在項目起始階段定義好所有需求再費盡心思的控制變化的方法相比，有能力在項目周期的任何階段去適應(yīng)變化，將是更 加現(xiàn)實更加有效的方法。
極限編程為管理人員和開發(fā)人員開出了一劑指導(dǎo)日常實踐的良方；這個實踐意味著接受并鼓勵某些特別的有價值的方法。支持者相信，這些在傳統(tǒng)的軟件工程中看來是“極端的”實踐，將會使開發(fā)過程比傳統(tǒng)方法更加好的響應(yīng)用戶需求，因此更加敏捷，更好的構(gòu)建出高質(zhì)量軟件。
極限編程的創(chuàng)始者是肯特·貝克、沃德·坎寧安和羅恩·杰弗里斯，他們在為克萊斯勒綜合報酬系統(tǒng)（C3）的薪水冊項目工作時提出了極限編程方法。肯 特·貝克在1996年3月成為C3的項目負(fù)責(zé)人，開始對項目的開發(fā)方法學(xué)進(jìn)行改善。他寫了一本關(guān)于這個改善后的方法學(xué)的書，并且于1999年10月將之發(fā) 行，這就是《極限編程解析》（2005第二版出版）?？巳R斯勒在2000年2月取消了實質(zhì)上并未成功的C3項目，但是這個方法學(xué)卻一直流行在軟件工程領(lǐng)域 中。至今，很多軟件開發(fā)項目都一直以極限編程做為他們的指導(dǎo)方法學(xué)。
極限編程的目標(biāo)
極限編程的主要目標(biāo)在于降低因需求變更而帶來的成本。在傳統(tǒng)系統(tǒng)開發(fā)方法中，系統(tǒng)需求是在項目開發(fā)的開始階段就確定下來，并在之后的開發(fā)過程中保持 不變的。這意味著項目開發(fā)進(jìn)入到之后的階段時出現(xiàn)的需求變更將導(dǎo)致開發(fā)成本急速增加，而這樣的需求變更在一些發(fā)展極快的領(lǐng)域中是不可避免的。
極限編程通過引入基本價值、原則、方法等概念來達(dá)到降低變更成本的目的。一個應(yīng)用了極限編程方法的系統(tǒng)開發(fā)項目在應(yīng)對需求變更時將顯得更為靈活。
極限編程的12個核心實踐
短交付周期
極限編程和Scrum一樣采用迭代的交付方式，每個迭代1-3周時間。在每個迭代結(jié)束的時候，團(tuán)隊交付可運行的，經(jīng)過測試的功能，這些功能可以馬上投入使用。
計劃游戲
XP的計劃過程主要針對軟件開發(fā)中的兩個問題：預(yù)測在交付日期前可以完成多少工作；現(xiàn)在和下一步該做些什么。不斷的回答這兩個問題，就是直接服務(wù)于 如何實施及調(diào)整開發(fā)過程；與此相比，希望一開始就精確定義整個開發(fā)過程要做什么事情以及每件事情要花多少時間，則事倍功半。針對這兩個問題，XP中又兩個 主要的相應(yīng)過程：
軟件發(fā)布計劃（ReleasePlanning）。客戶闡述需求，開發(fā)人員估算開發(fā)成本和風(fēng)險?？蛻舾鶕?jù)開發(fā)成本、風(fēng)險和每個需求的重要性，制訂一 個大致的項目計劃。最初的項目計劃沒有必要（也沒有可能）非常準(zhǔn)確，因為每個需求的開發(fā)成本、風(fēng)險及其重要性都不是一成不變的。而且，這個計劃會在實施過 程中被不斷地調(diào)整以趨精確。
周期開發(fā)計劃（IterationPlanning）。開發(fā)過程中，應(yīng)該有很多階段計劃（比如每三個星期一個計劃）。開發(fā)人員可能在某個周期對系統(tǒng) 進(jìn)行內(nèi)部的重整和優(yōu)化（代碼和設(shè)計），而在某個周期增加了新功能，或者會在一個周期內(nèi)同時做兩方面的工作。但是，經(jīng)過每個開發(fā)周期，用戶都應(yīng)該能得到一個 已經(jīng)實現(xiàn)了一些功能的系統(tǒng)。而且，每經(jīng)過一個周期，客戶就會再提出確定下一個周期要完成的需求。在每個開發(fā)周期中，開發(fā)人員會把需求分解成一個個很小的任 務(wù)，然后估計每個任務(wù)的開發(fā)成本和風(fēng)險。這些估算是基于實際開發(fā)經(jīng)驗的，項目做得多了，估算自然更加準(zhǔn)確和精確；在同一個項目中，每經(jīng)過一個開發(fā)周期，下 一次的估算都會有更過的經(jīng)驗、參照和依據(jù)，從而更加準(zhǔn)確。這些簡單的步驟對客戶提供了豐富的、足夠的信息，使之能靈活有效地調(diào)控開發(fā)進(jìn)程。每過兩三個星 期，客戶總能夠?qū)崒嵲谠诘乜吹介_發(fā)人員已經(jīng)完成的需求。在XP里，沒有什么“快要完成了”、“完成了90%”的模糊說法，要不是完成了，要不就是沒完成。 這種做法看起來好像有利有弊：好處是客戶可以馬上知道完成了哪些、做出來的東西是否合用、下面還要做些什么或改進(jìn)什么等等；壞處是客戶看到做出來的東西， 可能會很不滿意甚至中止合同。實際上，XP的這種做法是為了及早發(fā)現(xiàn)問題、解決問題，而不是等到過了幾個月，用戶終于看到開發(fā)完的系統(tǒng)了，然后才告訴你這 個不行、那個變了、還要增加哪個內(nèi)容等等。
結(jié)對編程
結(jié)對編程是指代碼由兩個人坐在一臺電腦前一起完成。一個程序員控制電腦并且主要考慮編碼細(xì)節(jié)。另外一個人主要關(guān)注整體結(jié)構(gòu)，不斷的對第一個程序員寫的代碼進(jìn)行評審。
結(jié)對不是固定的：我們甚至建議程序員盡量交叉結(jié)對。這樣，每個人都可以知道其它人的工作，每個人都對整個系統(tǒng)熟悉，結(jié)對程序設(shè)計加強了團(tuán)隊內(nèi)的溝通。這與代碼集體所有制是息息相關(guān)的。
可持續(xù)的節(jié)奏
團(tuán)隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。
代碼集體所有
代碼集體所有意味著每個人都對所有的代碼負(fù)責(zé)；這一點，反過來又意味著每個人都可以更改代碼的任意部分。結(jié)隊程序設(shè)計對這一實踐貢獻(xiàn)良多：借由在不 同的結(jié)隊中工作，所有的程序員都能看到完全的代碼。集體所有制的一個主要優(yōu)勢是提升了開發(fā)程序的速度，因為一旦代碼中出現(xiàn)錯誤，任何程序員都能修正它。
在給予每個開發(fā)人員修改代碼的權(quán)限的情況下，可能存在程序員引入錯誤的風(fēng)險，他／她們知道自己在做什么，卻無法預(yù)見某些依賴關(guān)系。完善的單元測試可以解決這個問題：如果未被預(yù)見的依賴產(chǎn)生了錯誤，那么當(dāng)單元測試運行時，它必定會失敗。
編碼規(guī)范
XP開發(fā)小組中的所有人都遵循一個統(tǒng)一的編程標(biāo)準(zhǔn)，因此，所有的代碼看起來好像是一個人寫的。因為有了統(tǒng)一的編程規(guī)范，每個程序員更加容易讀懂其他人寫的代碼，這是是實現(xiàn)代碼集體所有的重要前提之一。
簡單設(shè)計
XP中讓初學(xué)者感到最困惑的就是這點。XP要求用最簡單的辦法實現(xiàn)每個小需求，前提是按照這些簡單設(shè)計開發(fā)出來的軟件必須通過測試。這些設(shè)計只要能 滿足系統(tǒng)和客戶在當(dāng)下的需求就可以了，不需要任何畫蛇添足的設(shè)計，而且所有這些設(shè)計都將在后續(xù)的開發(fā)過程中就被不斷地重整和優(yōu)化。
在XP中，沒有那種傳統(tǒng)開發(fā)模式中一次性的、針對所有需求的總體設(shè)計。在XP中，設(shè)計過程幾乎一直貫穿著整個項目開發(fā)：從制訂項目的計劃，到制訂每 個開發(fā)周期（Iteration）的計劃，到針對每個需求模塊的簡捷設(shè)計，到設(shè)計的復(fù)核，以及一直不間斷的設(shè)計重整和優(yōu)化。整個設(shè)計過程是個螺旋式的、不 斷前進(jìn)和發(fā)展的過程。從這個角度看，XP是把設(shè)計做到了極致。
測試驅(qū)動開發(fā)
測試驅(qū)動開發(fā)的基本思想就是在開發(fā)功能代碼之前，先編寫測試代碼，然后只編寫使測試通過的功能代碼，從而以測試來驅(qū)動整個開發(fā)過程的進(jìn)行。這有助于編寫簡潔可用和高質(zhì)量的代碼，有很高的靈活性和健壯性，能快速響應(yīng)變化，并加速開發(fā)過程。
測試驅(qū)動開發(fā)的基本過程如下：
① 快速新增一個測試
② 運行所有的測試（有時候只需要運行一個或一部分），發(fā)現(xiàn)新增的測試不能通過
③ 做一些小小的改動，盡快地讓測試程序可運行，為此可以在程序中使用一些不合情理的方法
④ 運行所有的測試，并且全部通過
⑤ 重構(gòu)代碼，以消除重復(fù)設(shè)計，優(yōu)化設(shè)計結(jié)構(gòu)
簡單來說，就是不可運行/可運行/重構(gòu)——這正是測試驅(qū)動開發(fā)的口號
重構(gòu)
XP強調(diào)簡單的設(shè)計，但簡單的設(shè)計并不是沒有設(shè)計的流水賬式的程序，也不是沒有結(jié)構(gòu)、缺乏重用性的程序設(shè)計。開發(fā)人員雖然對每個USERSTORY 都進(jìn)行簡單設(shè)計，但同時也在不斷地對設(shè)計進(jìn)行改進(jìn)，這個過程叫設(shè)計的重構(gòu)（Refactoring）。這個名字最早出現(xiàn)在MartinFowler寫的 《Refactoring:ImprovingtheDesignofExistingCode》這本書中。
Refactoring主要是努力減少程序和設(shè)計中重復(fù)出現(xiàn)的部分，增強程序和設(shè)計的可重用性。Refactoring的概念并不是XP首創(chuàng)的，它 已經(jīng)被提出了近30年了，而且一直被認(rèn)為是高質(zhì)量的代碼的特點之一。但XP強調(diào)，把Refactoring做到極致，應(yīng)該隨時隨地、盡可能地進(jìn)行 Refactoring，只要有可能，程序員都不應(yīng)該心疼以前寫的程序，而要毫不留情地改進(jìn)程序。當(dāng)然，每次改動后，程序員都應(yīng)該運行測試程序，保證新系 統(tǒng)仍然符合預(yù)定的要求。
系統(tǒng)隱喻
為了幫助每個人一致清楚地理解要完成的客戶需求、要開發(fā)的系統(tǒng)功能，XP開發(fā)小組用很多形象的比喻來描述系統(tǒng)或功能模塊是怎樣工作的。比如，對于一個搜索引擎，它的Metaphor可能就是“一大群蜘蛛，在網(wǎng)上四處尋找要捕捉的東西，然后把東西帶回巢穴。”
持續(xù)集成
集成軟件的過程不是新問題，如果項目開發(fā)的規(guī)模比較小，比如一個人的項目，如果它對外部系統(tǒng)的依賴很小，那么軟件集成不是問題，但是隨著軟件項目復(fù) 雜度的增加（即使增加一個人），就會對集成和確保軟件組件能夠在一起工作提出了更多的要求-要早集成，常集成。早集成，頻繁的集成幫助項目在早期發(fā)現(xiàn)項目 風(fēng)險和質(zhì)量問題，如果到后期才發(fā)現(xiàn)這些問題，解決問題代價很大，很有可能導(dǎo)致項目延期或者項目失敗。
持續(xù)集成是一種軟件開發(fā)實踐，即團(tuán)隊開發(fā)成員經(jīng)常集成它們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發(fā)生多次集成。每次集成都通 過自動化的構(gòu)建（包括編譯，發(fā)布，自動化測試)來驗證，從而盡快地發(fā)現(xiàn)集成錯誤。許多團(tuán)隊發(fā)現(xiàn)這個過程可以大大減少集成的問題，讓團(tuán)隊能夠更快的開發(fā)內(nèi)聚 的軟件。
現(xiàn)場客戶
在極限編程中，“客戶”并不是為系統(tǒng)付帳的人，而是真正使用該系統(tǒng)的人。極限編程認(rèn)為客戶應(yīng)該時刻在現(xiàn)場解決問題。例如：在團(tuán)隊開發(fā)一個財務(wù)管理系統(tǒng)時，開發(fā)小組內(nèi)應(yīng)包含一位財務(wù)管理人員?？蛻糌?fù)責(zé)編寫故事和驗收測試，現(xiàn)場客戶可以使團(tuán)隊和客戶有更頻繁的交流和討論。
極限編程的4個價值
除了XP實踐，極限編程還提倡四大價值：溝通、簡單、回饋、勇氣。
溝通
構(gòu)建一個軟件系統(tǒng)的基本任務(wù)之一就是與系統(tǒng)的開發(fā)者交流以明確系統(tǒng)的具體需求。在一些正式的軟件開發(fā)方法中，這一任務(wù)是通過文檔來完成的。
極限編程技術(shù)可以被看成是在開發(fā)小組的成員之間迅速構(gòu)建與傳播制度上的認(rèn)識的一種方法。它的目標(biāo)是向所有開發(fā)人員提供一個對于系統(tǒng)的共享的視角，而 這一視角又是與系統(tǒng)的最終用戶的視角相吻合的。為了達(dá)到這一目標(biāo)，極限編程支持設(shè)計、抽象、還有用戶-程序員間交流的簡單化，鼓勵經(jīng)常性的口頭交流與回 饋。
簡單
極限編程鼓勵從最簡單的解決方式入手再通過不斷重構(gòu)達(dá)到更好的結(jié)果。這種方法與傳統(tǒng)系統(tǒng)開發(fā)方式的不同之處在于，它只關(guān)注于對當(dāng)前的需求來進(jìn)行設(shè) 計、編碼，而不去理會明天、下周或者下個月會出現(xiàn)的需求。極限編程的擁護(hù)者承認(rèn)這樣的考慮是有缺陷的，即有時候在修改現(xiàn)有的系統(tǒng)以滿足未來的需求時不得不 付出更多的努力。然而他們主張“不對將來可能的需求上投入精力”所得到的好處可以彌補這一點，因為將來的需求在他們還沒提出之前是很可能發(fā)生變化的。為了 將來不確定的需求進(jìn)行設(shè)計以及編碼意味著在一些可能并不需要的方面浪費資源。而與之前提到的“交流”這一價值相關(guān)聯(lián)來看，設(shè)計與代碼上的簡化可以提高交流 的質(zhì)量。一個由簡單的編碼實現(xiàn)的簡單的設(shè)計可以更加容易得被小組中的每個程序員所理解。
反饋
XP團(tuán)隊重視反饋，反饋越快越好。在極限編程中，“反饋”是和系統(tǒng)開發(fā)的很多不同方面相關(guān)聯(lián)的：
來自系統(tǒng)的反饋：通過編寫單元測試，程序員能夠很直觀的得到經(jīng)過修改后系統(tǒng)的狀態(tài)。
來自客戶的反饋：功能性測試是由客戶還有測試人員來編寫的。他們能由此得知當(dāng)前系統(tǒng)的狀態(tài)。這樣的評審一般計劃2、3個禮拜進(jìn)行一次，這樣客戶可以非常容易的了解、掌控開發(fā)的進(jìn)度。
來自小組的反饋：當(dāng)客戶帶著新需求來參加項目計劃會議時，小組可以直接對于實現(xiàn)新需求所需要的時間進(jìn)行評估然后反饋給客戶。
反饋是與“交流”、“簡單”這兩條價值緊密聯(lián)系的。為了溝通系統(tǒng)中的缺陷，可以通過編寫單元測試，簡單的證明某一段代碼存在問題。來自系統(tǒng)的直接反 饋信息將提醒程序員注意這一部分。用戶可以以定義好的功能需求為依據(jù)，對系統(tǒng)進(jìn)行周期性的測試。用Kent Beck的話來說：“編程中的樂觀主義是危險的，而及時反饋則是解決它的方法。”
勇氣
極限編程理論中的“系統(tǒng)開發(fā)中的勇氣”最好用一組實踐來詮釋。其中之一就是“只為今天的需求設(shè)計以及編碼，不要考慮明天”這條戒律。這是努力避免陷 入設(shè)計的泥潭、而在其他問題上花費了太多不必要的精力。勇氣使得開發(fā)人員在需要重構(gòu)他們的代碼時能感到舒適。這意味著重新審查現(xiàn)有系統(tǒng)并完善它會使得以后 出現(xiàn)的變化需求更容易被實現(xiàn)。另一個勇氣的例子是了解什么時候應(yīng)該完全丟棄現(xiàn)有的代碼。每個程序員都有這樣的經(jīng)歷：他們花了一整天的時間糾纏于自己設(shè)計和 代碼中的一個復(fù)雜的難題卻無所得，而第二天回來以一個全新而清醒的角度來考慮，在半小時內(nèi)就輕松解決了問題。
極限編程的5個原則
組成極限編程基礎(chǔ)的原則，正是基于上面描述的那幾條價值。在系統(tǒng)開發(fā)項目中，這些原則被用來為決策做出指導(dǎo)。與價值相比，原則被描述的更加具體化，以便在實際應(yīng)用中更為簡單的轉(zhuǎn)變?yōu)榫唧w的指導(dǎo)意見。
1. 快速反饋
當(dāng)反饋能做到及時、迅速，將發(fā)揮極大的作用。一個事件和對這一事件做出反饋之間的時間，一般被用來掌握新情況以及做出修改。與傳統(tǒng)開發(fā)方法不同，與 客戶的發(fā)生接觸是不斷反復(fù)出現(xiàn)的。客戶能夠清楚地洞察開發(fā)中系統(tǒng)的狀況。他／她能夠在整個開發(fā)過程中及時給出反饋意見，并且在需要的時候能夠掌控系統(tǒng)的開 發(fā)方向。
單元測試同樣對貫徹反饋原則起到作用。在編寫代碼的過程中，應(yīng)需求變更而做出修改的系統(tǒng)將出現(xiàn)怎樣的反應(yīng)，正是通過單元測試來給出直接反饋的。比 如，某個程序員對系統(tǒng)中的一部分代碼進(jìn)行了修改，而假如這樣的修改影響到了系統(tǒng)中的另一部分（超出了這個程序員的可控范圍），則這個程序員不會去關(guān)注這個 缺陷。往往這樣的問題會在系統(tǒng)進(jìn)入生產(chǎn)環(huán)節(jié)時暴露出來。
2. 假設(shè)簡單
假設(shè)簡單認(rèn)為任何問題都可以”極度簡單”地解決。傳統(tǒng)的系統(tǒng)開發(fā)方法要考慮未來的變化，要考慮代碼的可重用性。極限編程拒絕這樣做。
3. 增量變化
極限編程的提倡者總是說：羅馬不是一天建成的。一次就想進(jìn)行一個大的改造是不可能的。極限編程采用增量變化的原則。比如說，可能每三個星期發(fā)布一個包含小變化的新版本。這樣一小步一小步前進(jìn)的方式，使得整個開發(fā)進(jìn)度以及正在開發(fā)的系統(tǒng)對于用戶來說變得更為可控。
4. 擁抱變化
可以肯定地是，不確定因素總是存在的。“擁抱變化”這一原則就是強調(diào)不要對變化采取反抗的態(tài)度，而應(yīng)該擁抱它們。比如，在一次階段性會議中客戶提出了一些看來戲劇性的需求變更。作為程序員，必須擁抱這些變化，并且擬定計劃使得下一個階段的產(chǎn)品能夠滿足新的需求。
5. 高質(zhì)量的工作
沒人喜歡拖泥帶水，每個人都期望出色的完成工作。極限編程的提倡者認(rèn)為范圍、時間、成本和質(zhì)量這個四個軟件開發(fā)的變量，只有質(zhì)量不可妥協(xié)的。