這是一本關於**極限程式設計（Extreme Programming, XP）**的書。XP 是一套輕量級方法論，適用於中小型團隊，在需求模糊或快速變動的情況下開發軟體。
本書的目的，是幫助你判斷 XP 適不適合你。
如果你讀完這本書後正確地決定不採用 XP，作者認為目標同樣達成了——與你正確地決定採用它，價值相等。
為什麼叫「極限」#
對某些人來說，XP 看起來只是常識而已。那為什麼叫「極限」？因為 XP 把這些常識級的原則與實踐推到極端：
- 如果程式碼審查是好的，那就隨時都在審查——結對程式設計（pair programming）
- 如果測試是好的，那就讓每個人隨時都在測試——單元測試（unit testing），連客戶也一起測——功能測試（functional testing）
- 如果設計是好的，那就讓它成為每個人每天的工作——重構（refactoring）
- 如果簡單是好的，那就永遠讓系統維持在「能支撐現有功能的最簡設計」——能動的最簡方案（the simplest thing that could possibly work）
- 如果架構很重要，那就讓每個人隨時都在定義與精煉架構——隱喻（metaphor）
- 如果整合測試很重要，那就一天整合並測試好幾次——持續整合（continuous integration）
- 如果短迭代是好的，那就把迭代縮到極短——以秒、分、小時計，而非週、月、年——規劃遊戲（the Planning Game）
貝克（Kent Beck）最初構思 XP 時，腦中的畫面是一片控制面板上的旋鈕：每個旋鈕都是一項他從經驗中確認有效的實踐。他把所有旋鈕全部轉到 10，看看會發生什麼事。結果令他有些意外——整套實踐組合起來竟然是穩定、可預測且靈活的。
XP 的兩組承諾#
- 對程式設計師：每天都能做真正重要的事；不必獨自面對可怕的處境；能盡一切努力讓系統成功；能做出自己最適合做的決策，也不必去做自己不夠格做的決策。
- 對客戶與管理者：每一個程式設計週都能榨出最大價值；每隔幾週就能看到自己在乎的目標上有具體進展；能在開發途中改變專案方向，而不必付出高昂代價。
一句話：XP 承諾同時降低專案風險、提升對業務變化的回應力、在系統的整個生命週期中提升生產力，並且讓團隊寫軟體變得有趣。
XP 是什麼#
XP 是一種輕量、高效、低風險、靈活、可預測、科學且有趣的軟體開發方式。它與其他方法論的區別在於：
- 來自短週期的早期、具體且持續的回饋
- 增量式規劃：迅速產出整體計畫，並預期它會隨專案生命週期演化
- 能彈性排程功能實作，回應變動中的業務需求
- 依賴由程式設計師與客戶撰寫的自動化測試，用來監控開發進度、讓系統得以演化、及早捕捉缺陷
- 依賴口頭溝通、測試與原始碼來傳達系統結構與意圖
- 依賴一套與系統同壽的演化式設計流程
- 依賴具備一般技能的程式設計師之間的緊密協作
- 依賴同時貼合程式設計師短期直覺與專案長期利益的實踐
XP 是一種紀律（discipline）。之所以稱為紀律，是因為有些事你必須做才算在做 XP。你沒有「要不要寫測試」的選擇權——不寫測試，就不是極限，沒得討論。
適用範圍#
XP 設計來服務這樣的專案：
- 團隊規模為 2 到 10 名程式設計師
- 不受既有運算環境的嚴苛限制
- 測試能在半天以內跑完一輪合理的量
XP 的創新之處#
XP 第一次接觸時會嚇到或激怒某些人，但其中沒有一個想法是新的——多數與程式設計本身一樣古老。從這個角度看，XP 其實是保守的：所有技術都經過數十年（實作策略）甚至數百年（管理策略）的驗證。
XP 真正的創新在於三件事：
- 把這些實踐全部收攏在同一把傘下
- 確保它們被盡可能徹底地執行
- 確保這些實踐盡最大可能相互支撐
「夠用」的心態#
XP 是一場實驗，回答的問題是：「如果時間夠用，你會怎麼寫程式？」
你不可能真的多要到時間——這畢竟是生意，而且我們是要贏的。但如果時間夠用，你會寫測試；你會在學到新東西時重構系統；你會多和同事、多和客戶交談。
這種**「充足的心態」（mentality of sufficiency）**是人道的，不像那些不可能達成的強加期限所帶來的無盡苦役——正是後者把大量人才逼出了程式設計這一行。而充足的心態同時也是好生意：它會自己創造出效率，正如匱乏的心態會自己創造出浪費。
延伸：森林人與山地人的對照
人類學家滕布爾（Colin Turnbull）在《The Forest People》與《The Mountain People》中描繪了兩個社會的對比。
- 山地：資源稀缺，人們長期瀕臨飢餓。演化出的文化極其可怕——母親一旦判斷嬰兒有存活機會，就把他丟給四處遊蕩的野孩子群；暴力、殘忍與背叛是日常。
- 森林：資源充足，一個人每天只需花半小時就能滿足基本需求。森林文化恰是山地文化的鏡像——成人共同養育孩子，孩子被呵護與疼愛直到能自理；若有人失手殺了人（蓄意犯罪聞所未聞），會被放逐，但只需走進森林一小段距離、待上幾個月，期間族人還會帶食物去探望。
本書結構#
本書的寫法，彷彿是你和作者一起在創造一套新的軟體開發紀律：先檢視我們對軟體開發的基本假設，接著創造這套紀律本身，最後檢視它的意涵——如何導入、何時不該導入，以及它為商業創造了什麼機會。
全書分為三部：
- 問題——從〈風險：根本問題〉到〈回歸基本功〉。設定 XP 想解決的問題，並提出評估解法的判準，讓你掌握 XP 的整體世界觀。
- 解法——從〈快速概覽〉到〈測試策略〉。把第一部的抽象想法轉化為一套具體方法論的實踐。這一部不會告訴你「確切怎麼執行」，而是談這些實踐的大致形狀，並將每項實踐扣回第一部提出的問題與原則。
- 實施 XP——從〈採用 XP〉到〈XP 與合約形式〉。討論實施 XP 的各種主題：如何導入、極限專案中各種角色被期待做什麼、XP 在商業人士眼中是什麼樣子。
這本書談的是 XP 背後的思考——它的根源、哲學、故事與迷思，而不是「精確地該怎麼做 XP」。書中不會有大量檢核表、範例或程式設計故事。
延伸：加瑪（Erich Gamma）的推薦序
極限程式設計把寫程式提名為軟體專案全程的核心活動。這不可能行得通！
但加瑪反思自己的開發工作：他身處一個即時（just-in-time）的軟體文化，發布週期被壓縮，還摻雜高技術風險——讓「改變」成為朋友是一種生存技能。在常常地理分散的團隊之內與之間，溝通是用程式碼進行的：
- 讀程式碼來理解新的或演化中的子系統 API
- 複雜物件的生命週期與行為，定義在測試案例裡——同樣是程式碼
- 問題回報附帶重現問題的測試案例——又是程式碼
- 最後，用重構持續改善既有程式碼
顯然這是以程式碼為中心的開發，而他們確實準時交付了軟體——所以這終究行得通。
但要下結論說「交付軟體只需要亡命徒式的寫程式」就錯了。交付軟體很難，準時交付高品質軟體更難，要辦到得靠有紀律地運用額外的最佳實踐——這正是貝克這本書的起點。
加瑪指出，XP 描述的開發途徑，把許多成功開發者實際採用、卻被龐大的軟體方法與流程文獻掩埋的實踐重新組合起來。如同模式（patterns）一樣，XP 建立在單元測試、結對程式設計、重構這些最佳實踐之上；而在 XP 中，這些實踐被組合成彼此互補、且往往互相制衡的關係。這種不同實踐之間的交互作用，正是本書的重要貢獻。
——加瑪（Erich Gamma）
延伸：致謝
作者以第一人稱書寫，不是因為這些是他的想法，而是因為這是他對這些想法的視角——XP 中大多數實踐都和程式設計一樣古老。
- **康寧漢（Ward Cunningham）**是書中大部分內容的直接來源。作者說，過去十五年他幾乎都在試著向別人解釋康寧漢自然而然在做的事。
- 感謝**傑佛瑞斯（Ron Jeffries）**願意實際嘗試，並讓它變得更好。
- 感謝**福勒（Martin Fowler）**用不具威脅性的方式解釋它。
- 感謝**加瑪（Erich Gamma）**在利馬特河（Limmat）畔看天鵝時的長談，以及不放過任何草率的思考。
- 感謝作者的父親道格・貝克（Doug Beck），那些年操練程式設計手藝的身影。
- 感謝克萊斯勒（Chrysler）的 C3 團隊跟著他上山，然後在攻頂路上超越了他；特別感謝經理 Sue Unger 與 Ron Savage 有勇氣給他們嘗試的機會。
- 感謝 Daedalos Consulting 支持本書的寫作。
- 最佳審閱者的殊榮歸於 Paul Chisholm——他大量、深思熟慮、而且常常令人惱火的意見，讓這本書的品質提升了一倍不止。