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