極限程式設計

極限程式設計（ExtremeProgramming，簡稱XP）是一種軟體工程方法學，是敏捷軟體開發中可能是最富有成效的幾種方法學之一。如同其他敏捷方法學，極限程式設計和傳統方法學的本質不同在於它更強調可適應效能性以及面臨的困難。
簡介
極限程式設計是一個輕量級的、靈巧的軟體開發方法；同時它也是一個非常嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣；即，任何一個軟體專案都可以從四個方面入手進行改善：加強交流；從簡單做起；尋求反饋；勇於實事求是。
XP是一種近螺旋式的開發方法，它將複雜的開發過程分解為一個個相對比較簡單的小週期；通過積極的交流、反饋以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際情況及時地調整開發過程。
極限程式設計的目標
極限程式設計的主要目標在於降低因需求變更而帶來的成本。在傳統系統開發方法中，系統需求是在專案開發的開始階段就確定下來，並在之後的開發過程中保持不變的。這意味著專案開發進入到之後的階段時出現的需求變更（而這樣的需求變更在一些發展極快的領域中是不可避免的）將導致開發成本急速增加。
極限程式設計透過引入基本價值、原則、方法等概念來達到降低變更成本的目的。一個應用了極限程式設計方法的系統開發專案在應對需求變更時將顯得更為靈活。
極限程式設計的特徵
極限程式設計方法的基本特徵是：增量和反覆式的開發----一次小的改進跟著一個小的改進。
反覆性，通常是自動重複的單元測試，迴歸測試。
結對程式設計
在程式設計團隊中的使用者互動（在場的客戶）
軟體重構
共享的程式碼所有權
簡單
反饋
用隱喻來組織系統
可以忍受的速度
極限程式設計的4個價值
除了XP實踐，極限程式設計還提倡四大價值：溝通、簡單、回饋、勇氣。
溝通
構建一個軟體系統的基本任務之一就是與系統的開發者交流以明確系統的具體需求。在一些正式的軟體開發方法中，這一任務是通過文件來完成的。
極限程式設計技術可以被看成是在開發小組的成員之間迅速構建與傳播制度上的認識的一種方法。它的目標是向所有開發人員提供一個對於系統的共享的視角，而這一視角又是與系統的終端使用者的視角相吻合的。為了達到這一目標，極限程式設計支援設計、抽象、還有使用者-程式設計師間交流的簡單化，鼓勵經常性的口頭交流與回饋。
簡單
極限程式設計鼓勵從最簡單的解決方式入手再通過不斷重構達到更好的結果。這種方法與傳統系統開發方式的不同之處在於，它只關注於對當前的需求來進行設計、編碼，而不去理會明天、下週或者下個月會出現的需求。極限程式設計的擁護者承認這樣的考慮是有缺陷的，即有時候在修改現有的系統以滿足未來的需求時不得不付出更多的努力。然而他們主張“不對將來可能的需求上投入精力”所得到的好處可以彌補這一點，因為將來的需求在他們還沒提出之前是很可能發生變化的。為了將來不確定的需求進行設計以及編碼意味著在一些可能並不需要的方面浪費資源。而與之前提到的“交流”這一價值相關聯來看，設計與程式碼上的簡化可以提高交流的質量。一個由簡單的編碼實現的簡單的設計可以更加容易得被小組中的每個程式設計師所理解。
反饋
XP團隊重視反饋，反饋越快越好。在極限程式設計中，“反饋”是和系統開發的很多不同方面相關聯的：
來自系統的反饋：通過編寫單元測試，程式設計師能夠很直觀的得到經過修改後系統的狀態。
來自客戶的反饋：功能性測試是由客戶還有測試人員來編寫的。他們能由此得知當前系統的狀態。這樣的評審一般計劃2、3個禮拜進行一次，這樣客戶可以非常容易的瞭解、掌控開發的進度。
來自小組的反饋：當客戶帶著新需求來參加專案計劃會議時，小組可以直接對於實現新需求所需要的時間進行評估然後反饋給客戶。
反饋是與“交流”、“簡單”這兩條價值緊密聯絡的。為了溝通系統中的缺陷，可以通過編寫單元測試，簡單的證明某一段程式碼存在問題。來自系統的直接反饋資訊將提醒程式設計師注意這一部分。使用者可以以定義好的功能需求為依據，對系統進行週期性的測試。用Kent Beck的話來說：“程式設計中的樂觀主義是危險的，而及時反饋則是解決它的方法。”
勇氣
極限程式設計理論中的“系統開發中的勇氣”最好用一組實踐來詮釋。其中之一就是“只為今天的需求設計以及編碼，不要考慮明天”這條戒律。這是努力避免陷入設計的泥潭、而在其他問題上花費了太多不必要的精力。勇氣使得開發人員在需要重構他們的程式碼時能感到舒適。這意味著重新審查現有系統並完善它會使得以後出現的變化需求更容易被實現。另一個勇氣的例子是瞭解什麼時候應該完全丟棄現有的程式碼。每個程式設計師都有這樣的經歷：他們花了一整天的時間糾纏於自己設計和程式碼中的一個複雜的難題卻無所得，而第二天回來以一個全新而清醒的角度來考慮，在半小時內就輕鬆解決了問題。
極限程式設計的5個原則
組成極限程式設計基礎的原則，正是基於上面描述的那幾條價值。在系統開發專案中，這些原則被用來為決策做出指導。與價值相比，原則被描述的更加具體化，以便在實際應用中更為簡單的轉變為具體的指導意見。
1. 快速反饋
當反饋能做到及時、迅速，將發揮極大的作用。一個事件和對這一事件做出反饋之間的時間，一般被用來掌握新情況以及做出修改。與傳統開發方法不同，與客戶的發生接觸是不斷反覆出現的。客戶能夠清楚地洞察開發中系統的狀況。他／她能夠在整個開發過程中及時給出反饋意見，並且在需要的時候能夠掌控系統的開發方向。
單元測試同樣對貫徹反饋原則起到作用。在編寫程式碼的過程中，應需求變更而做出修改的系統將出現怎樣的反應，正是通過單元測試來給出直接反饋的。比如，某個程式設計師對系統中的一部分程式碼進行了修改，而假如這樣的修改影響到了系統中的另一部分（超出了這個程式設計師的可控範圍），則這個程式設計師不會去關注這個缺陷。往往這樣的問題會在系統進入生產環節時暴露出來。
2. 假設簡單
假設簡單認為任何問題都可以”極度簡單”地解決。傳統的系統開發方法要考慮未來的變化，要考慮程式碼的可重用性。極限程式設計拒絕這樣做。
3. 增量變化
極限程式設計的提倡者總是說：羅馬不是一天建成的。一次就想進行一個大的改造是不可能的。極限程式設計採用增量變化的原則。比如說，可能每三個星期釋出一個包含小變化的新版本。這樣一小步一小步前進的方式，使得整個開發進度以及正在開發的系統對於使用者來說變得更為可控。
4. 擁抱變化
可以肯定地是，不確定因素總是存在的。“擁抱變化”這一原則就是強調不要對變化採取反抗的態度，而應該擁抱它們。比如，在一次階段性會議中客戶提出了一些看來戲劇性的需求變更。作為程式設計師，必須擁抱這些變化，並且擬定計劃使得下一個階段的產品能夠滿足新的需求。
5. 高質量的工作
沒人喜歡拖泥帶水，每個人都期望出色的完成工作。極限程式設計的提倡者認為範圍、時間、成本和質量這個四個軟體開發的變數，只有質量不可妥協的。