盡磅的編程

盡磅的編程（英語：Extreme programming，縮寫為 XP）， 是一種軟體工程方法學，是敏捷軟體開發的一種方式。親像其他敏捷方法學，極限編程佮傳統方法學的本質無仝佇咧伊閣較強調會當適應性毋是會當預測性。極限編程的支持者認為軟體需求的不斷變化是真自然的現象，是軟體專案開發中不可避免的、嘛是應該欣然接受的現象；𪜶相信講，佮傳統的專案起始階段定義好所有的需求愛盡心思的控制變化的方法相比，有能力佇咧專案周期的任何階段去適應變化，將是更加現實更加有效的方法。

盡磅編程為管理人員佮開發人員開出一劑指導日常實踐的良方；這个實踐意味來接受並鼓勵某一寡特別的價值的方法。支持者相信，這寡佇咧傳統的軟體工程內底看起來是「極端的」實踐，將會使開發過程比傳統方法閣較好的回應使用者需求，所以閣較扭掠，閣較好的構建出高品質軟體。

歷史

極限編程的創始者是肯特 ・ 貝克、沃德 ・ 坎寧安佮羅恩 ・ 傑傑里斯，𪜶咧為克萊斯勒綜合報酬系統的薪水冊專案的工作時提出極限編程方法。肯特 ・ 貝克佇一九九六年三月成做克萊斯勒系統的專案負責人，開始對專案的開發方法學進行改善。伊寫了一本關於這个改善了後的方法學的冊，並且佇一九九九年十月會之發行，這就是《誠有限的編程解析》（二千空五第二版出版）。 克萊斯勒佇二空空年二月取消矣實質上閣無成功的克萊斯勒系統，但是這个方法學煞一直流行佇軟體工程領域內底。一直到二空空六年，真濟軟體開發專案攏一直以極限編程做為𪜶的指導方法學。

該書闡述了這馬上極限編程的哲學思想：

• 一種社會性的變化機制
• 一種開發模式
• 一種改進的方法
• 一種協調生產率佮人性的試驗
• 一種軟體開發方法共極限編程一般化並用佇其他型別的專案叫做極限專案管理。

極限編程的推廣之一為共無仝的敏捷軟體實踐佮傳統實踐節奏地敆起來，彈性地合用佇無仝企業開發環境。這就是軟體開發節奏（Software Development Rhythms）的中心思想

目標

極限編程的主要目標是佇咧降低因為這个需求變閣較會當帶來的成本。佇傳統系統開發方法內底，系統需求是佇咧專案開發的開始階段就確定落來，並且佇咧了後的開發過程中保持不變的。這意味著專案開發進入到了後的階段時出現的需求變更（按呢的需求變閣較佇咧一寡發展極快的領域內底是不可避免的）將致使開發成本急速增加。

極限編程透過引入基本價值、原則、方法等概念來達到降低變成本的目的。一个應用真有限編程方法的系統開發專案應對需求變更時會顯得更加做靈活。

核心實踐

極限編程實踐作業的核心會用予人分做以下四个範圍（十二个實踐作業）:

細細回饋

• 結對程式設計
• 策劃遊戲
• 測試驅動開發
• 全隊（原名：在場客戶）

一直有程式

• 繼續整合
• 設計最佳化（原名：軟體重構）
• 小型的發佈

共識

• 編碼標準
• 程式碼集體共有
• 簡單設計
• 系統隱喻

程式設計師的利益

• 會持之恆的速度佇第二版的《誠有限的編程解析》中，咱這馬主要的實踐以外，猶列出了一系列延伸的實踐。

核心實踐源自被廣泛接受的最佳實踐，並且予人捒對極致：

• 開發人員佮客戶之間的互動是有益的。所以，一个極限編程的小組對理論上要求需要一个軟體使用者佇身軀邊，這使用者制定軟體的工課需求佮優先等級，並且趕緊佇各種問題出現的時陣隨就會當回答（實際工作當中，這个角色是由客戶代理商完成的）.
• 若學習是好的，就共做到底：按呢減少矣開發佮回饋周期的長度，測試也會當完成。
• 簡單的代碼閣較有可能工作。所以極限編程的程式設計師佇咧一个軟體專案內底唯寫出會當滿足目前實際需求的代碼，按呢或者是濟或者是降低代碼的複雜性佮重複性。
• 若簡單的代碼是好的，遐爾共變複雜的代碼覆寫做簡單的。
• 代碼評審是好的嘛。所以，極限編程程式設計師以兩人合作的方式工作。𪜶共享一个螢幕佮鍵盤，增加隊員之間的交流，嘛予代碼佇遐咧寫出的時陣就去予人評審矣。
• 測試代碼是好的。所以，佇盡磅編程當中，測試用例佇實際代碼進前就予人寫出來矣。代碼干焦咧通過試的時陣才去予人認為完成矣。（當然喔，需要進一步來分解降低複雜性）。 整個軟體系統用一種周期化的，即時的，予人預先編予好的自動化測試方式來保證伊的確有作用。參看測試驅動的開發。
• 一般來講，極限編程予人認為對較少佇十二人的小團隊真有路用。一寡人認為極限編程會使用大的團隊，猶毋過其他的人認為 Rational 統一過程閣較適合大的團隊。毋過，極限的編程是誠歹佇咧一寡超過一百人的開發小組內得著成功。並毋是極限編程袂當推廣到閣較大的團隊，是罕得有閣較大的團隊來試用伊。極限編程的人員嘛拒絕去凊彩推測這个問題。

概念

活動

極限編程描述了佇軟體開發過程中四種基本的行為，包括一 . 拍碼二 . 測試三 . 聽候心 . 設計極限編程的提倡者就諍講佇系統開發過程的產物內底真正重要的干焦編碼，並認為無經過測試的程式碼啥物攏毋是。你若無試，客戶可能攏袂感覺，足濟軟體咧發佈的時陣無經過完整的測試，𪜶閣攏咧做工課（抑是濟抑是少少仔工課）。 盡磅的編程認為，佇軟體開發程式當中，若一个函式無經過測試就袂當認為伊會當做工課。

價值

盡磅編程技術以溝通、簡單、回饋、勇氣佮尊重做價值標準。

溝通

構建一个軟體系統的基本任務之一就是佮系統的開發者交流以明確係統的具體需求。佇咧一寡正式的軟體開發方法內底，這一任務是通過文件來完成的。

極限編程技術會當予人看做是咧開發小組的成員之間快速構建佮傳播制度上的認捌的一種方法。伊的目標是向所有開發人員提供一个對系統的共享的視角，啊若這視角閣是佮系統的終端使用者的視角相對同的。欲達成這目標，極限編程支援設計、抽象、閣有使用者-程式設計師間交流的簡單化，鼓勵不三時的口頭交流和回饋。

簡單

極限編程鼓勵對上簡單的解決的方式入手閣通過不斷重構達到閣較好的結果。這種方法佮傳統系統開發方式的無仝的所在佇咧，伊干焦注意對當前的需求來進行設計、編碼，毋去理會明仔載、後禮拜抑是後個月會出現的需求。極限編程的擁護者承認按呢的考慮是有缺陷的，即時咧修改現有的系統以滿足未來的需求的時不得不付出閣較濟的努力。毋過𪜶主張「毋著將來可能的需求上投入精力」所得著的好處會當彌補這點仔，因為將來的需求佇𪜶猶未提出進前是真可能發生變化的。為著將來無確定的需求進行設計以及編碼意味著佇咧一寡可能並無需要的方面浪費資源。佇佮進前講的「交流」這一價值相牽連來看，設計佮代碼上的簡化會當提懸交流的品質。一个由簡單的編碼實現的簡單的設計會當閣較會當予小組內底的每一个程式設計師所理解。

回饋

佇盡磅編程當中，「 回饋」是和系統開發的足濟無仝方面相關的：

• 來自系統的回饋：通過編寫單元測試，程式設計師會當足直觀的得著經過修改了後系統的狀態。
• 來自客戶的回饋：功能性測試是由客戶猶閣有測試人員來編寫的。𪜶會當按呢知影講做前系統的狀態。這款的評審一般計畫二、三禮拜進行一遍，按呢客戶會當非常容易的了解、掌控開發的進度。
• 來自小組的回饋：客戶紮新需求來參加專案計畫會議的時，小組會當直接對𪜶實現新需求所需要的時間來進行評估然後回饋予客戶。

回饋是佮「交流」、「 簡單」這兩條價值牽牢牢。為著溝通系統中的缺陷，會當迵過編寫單元測試，簡單的證明某一段代碼存在問題。來自系統的直接回饋資訊會提醒程式設計師注意這一部份。使用者會當定義好的功能需求為依據，對系統進行周期性的測試。用 Kent Beck 的話來講：「 編程當中的樂觀主義是危險的，猶閣有時陣回饋是解決伊的方法。」

勇氣

盡磅編程理論當中的「系統開發中的勇氣」上好用一組實踐來詮釋。其中之一就是講「干焦為著目前的需求設計以及編碼，莫為不可按算的未來做傷濟考慮」這條戒律。這是拍拚避免陷落設計的塗潭、啊若佇其他問題內底開傷濟無必要的精神。勇氣予開發人員佇需要重構𪜶的代碼的時陣會當感覺四序。這意味著重新審查現有系統並完善伊會予出現的變化需求閣較會予實現。另外一个勇氣的例是了解當時應該完全擲捒現有的代碼。逐个程式的設計師攏有按呢的經驗：𪜶開規工的時間交纏佇家己設計佮代碼中的一个複雜的難題煞無地步，第二工轉來以一个全新而清醒的角度來考慮，佇半點鐘內就輕鬆解決矣問題。

尊重

尊重的價值體這馬足濟方面。佇盡磅編程當中，團隊成員間的互相尊重體這馬每一个人保證提交的任何的改變袂致使編譯無法度通過、抑是致使現有的測試案例失敗、抑是用其他方式致使工作延期。團隊的成員對𪜶工作的尊重體這馬𪜶總是堅持追求高品質，堅持通過重構的手路來為手頭的工課揣著上好的解決設計方案。

原則

組成盡磅編程基礎的原則，正是基於頂頭所講的彼幾條價值。佇咧系統開發專案內底，遮的原則予人用來做決策做出指導。佮價值咧比並，原則予人描述的閣較大體化，通好佇實際應用中閣較簡單的轉變做是具體的指導意見。

快速回饋

回饋會當做到赴的時、快速，將發揮真大的作用。一个事件佮對這个事件做出回饋之間的時間，一般被用來掌握新情形以及做出修改。佮傳統開發的方法無仝款，佮客戶的發生接觸是一直湠出來的。客戶會當清楚地空察開發中系統的狀況。伊／伊會當規个開發過程當中及時予出回饋意見，並且佇需要的時陣會當掌控系統的開發方向。

單元測試仝款對貫徹回饋原則起到作用。咧編寫代碼的過程中，應需求變更加做出修改的系統會出現按怎的反應，正正是通過單元測試來共出直接回饋的。比如講，某一个程式設計師對系統中的一部份代碼進行矣修改，假使講若像按呢的修改影響著系統中的另外一部份（超出這个程式設計師的可控範圍）， 則這个程式設計師袂去關注這个缺陷。往往按呢的問題會佇系統進入生產環節的時陣共暴露出來。

假設簡單

準講簡單認為任何問題攏會使 " 極度簡單 " 地解決。傳統的系統開發方法愛考慮未來的變化，欲考慮程式碼的可重用性。極限編程拒絕按呢做。

包容變化

會當肯定地是，無確定因素總是存在的。「包容變化」這原則就是強調講莫對變化採取反抗的態度，應該包容𪜶。比如講，佇一改階段性會議中客戶提出一寡看起來戲劇性的需求變更。做為程式的設計師，著愛包容遮的變化，並且擬定計畫會當後一个階段的產品會當滿足新的需求。

實踐

策劃遊戲

佇咧極限編程當中主要的策劃程式號做策劃遊戲，本節會通過程式模型介紹這个程式。

策劃程式分做兩部份：

• 發佈策劃：
• 反覆狀態：

送出狀態—發佈計劃

這个階段牽成本、利純佮計劃這三个因素，包含四个部份：

• 按照價值排序：業務方按照商業價值為使用者故事排序。
• 照風險排序：開發方揤風險為著使用者故事排序。
• 設定周轉率：開發方決定以啥物款的速度開展專案。
• 選擇範圍：揀選佇後一个發佈當中需要被完成的使用者故事，提供使用者故事決定發佈日期。

價值排序

業務方按照商業價值為使用者故事排序。𪜶會分做三類：

• 關鍵：無這故事系統無法度運作抑變甲無意義。
• 重要的商業價值：有重要業務價值的非關鍵使用者故事。
• 上好會當有：並無重要商業價值的使用者故事；譬如講佇可用性抑是使用者介面上的改進。

風險排序

程式設計師按照風險對使用者故事做排序。伊／𪜶共使用者故事的風險劃做三類：低、中、懸。以下是這款方式的一个範例：

• 決定風險索引：依照以下的因素予逐个使用者故事一个零到二的索引：
• 完全度（咱敢已經了解咱所有的故事細節？）
• 完全（零）
• 無完全（一）
• 未知（二）
• 發散性（敢有可能會發生變化？）
• 低（零）
• 中（一）
• 懸（二）
• 複雜度（敢是以建構？）
• 簡單（零）
• 標準（一）
• 複雜（二）

共每一个使用者的故事增加所有遮的索引了後，給這個的使用者故事指定一个風險索引：低（零–一）， 中（二–四）， 懸（五–六）。

激勵狀態—發佈計劃

佇作業階段開發人員佮業務人員會當「操縱」這个規个程式。這意味對，𪜶會當做出改變。個體的使用者故事，抑是無仝使用者故事的相對優先等級，攏有可能改變；預估時間嘛可能會出現精差。這是做出相應調整的機會。

探索階段—重複計劃

計畫內底的探索階段是關於建立任務佮預估實施時間。

• 收集使用者故事：收集並編輯後一个發佈的所有使用者故事。
• 組合／分割任務：若是程式設計師因為任務傷大抑是傷細袂當按算任務完成時間，著愛組合抑是分割此任務。
• 預估任務：預測需要實作此任務的時間。

定階段—重複計劃

佇咧反覆計畫的約定階段以無仝使用者故事成做參考的任務予人派到程式設計師。

• 程式設計師接受任務：每一个程式設計師攏揀一个伊／伊負責的任務。
• 程式設計師按算任務：因為程式設計師對這項任務負責，伊／伊必須愛予出一个任務的估計時間。
• 設定負載的數：負載係數表示逐个程式設計師佇一个反起中理想的開發時間。比如講：一禮拜的工課四十點鐘，其中五點鐘用於開會，則負載係數袂超過三十五點鐘。
• 做平衡：做團隊內底所有程式的設計師攏已經予組態矣任務，就會佇預估時間佮負載數間做出較。任務組態佇咧程式設計師內底達到平衡。若有一个程式設計師的開發任務過重，其他程式設計師著愛共接／伊的一部份任務，反之亦然。

作業階段—重複計劃

各個任務是佇咧反覆計畫的作業階段中一步實作的。

• 取得一張任務卡片：程式的設計師提著一張由在伊／伊負責的任務的卡片。
• 走揣一名同伴：這个程式設計師將佮另外一个程式設計師做伙完成開發工課。這佇實施結隊程式設計中會閣較深入的探討。
• 設計這个任務：若需要，兩位程式設計師會設計這个任務所達成的功能。
• 編輯單元測試：佇咧程式設計師開始編輯實作功能的程式碼進前，伊／𪜶首先編輯自動測試。這佇實施單元測試內底會閣較深入的探討。
• 編輯程式碼：兩位程式設計師開始編輯程式碼。
• 執行測試：執行單元測試來確定程式碼會當正常工作。
• 執行功能測試：執行功能測試（是相關使用者故事佮任務卡片內底的需求）。

結對程式設計

結對程式設計的意思是所有的程式碼攏是由兩个人坐佇一台電腦前做伙完成的。一个程式設計師控制電腦並且主要考慮編碼細節。另外一个人主要是愛關注整體的結構，不斷的對頭一个程式設計師寫的程式碼來進行評審。

結著毋是固定的：阮甚至建議程式設計師盡量交插結對。按呢乎，逐个人攏會當知影其他的人的工作，逐家攏對規个系統的熟似，結對程式設計加強團隊內底的溝通。（這佮程式碼集體所有制是相關的）.

集體所有制

集體所有制意味著逐个人攏對所有的程式碼負責；這點，倒反閣意味著逐个人攏會當更改程式碼的任意部份。結隊程式設計對這一實踐貢獻良多：透過佇咧無仝款的結隊做工課，所有的程式設計師攏看會著完全的程式碼。集體所有制的一个主要的優勢是提升了開發程式的速度，因為一旦程式碼中出現錯誤，任何程式設計師攏會當修正伊。

會當予每一个開發人員修改程式碼的權限的情況下，可能存在程式設計師引入錯誤的風險，伊／𪜶知影家己咧做啥物，煞無法度去預見某一寡仔依賴關係。完善的單元測試會當解決這个問題：若無予人預見的依賴產生錯誤，遐做單元測試執行的時，伊必定會失敗。

現場客戶

佇盡磅編程當中，「 客戶」毋是為系統付數的人，顛倒是真正使用該系統的人。盡磅編程認為客戶應該時間踮現場解決問題。比如講：佇團隊開發一个財務管理系統時，開發小組內應包含一位財務管理人員。

單元測試

單元測試是用試一段路程式的自動測試（比如講：類，方法）。 佇盡磅編程當中，佇咧程式碼編輯進前就編輯單元測試。這種方式的目的是激勵程式設計師共想看覓／伊的程式碼佇啥物款的條件下跤會走閃去。極限的編程認為當程式設計師無法度閣想出閣較濟會當使伊／伊的程式碼脫箠的情況時，遮的程式碼便算完成。

重構

因為極限編程教條提倡編輯程式的時陣只滿足目前的需求，並且以盡可能簡單的方式實際上。有時會拄著一套硬擴擴的系統，所謂硬成的系統，表現之一是需要雙重（抑是偌重）維護：功能變化需要對濟份仝款（抑是類似）的程式碼進行修改；另外一種表現是對程式碼的一部份進行修改的時陣會影響其他很多部份。XP 教條認為這種狀況發生的時陣，意味系統正咧共你講通過改變系統架構以重構程式碼，使伊閣較簡單、閣較泛用。參見重構。

極限編程的特徵

極限編程方法的基本特徵是：

• 增加佮反覆式的開發-一改小的改進綴一个小的改進。
• 重複性，通常是自動重複的單元測試，回歸測試。參見 JUnit。
• 結對程式設計
• 佇咧程式設計團隊內面的使用者互動（在場的客戶）
• 軟體重構
• 共享的程式碼所有權
• 簡單
• 回饋
• 用隱喻來組織系統
• 會當忍受的速度

爭論的觀點

盡磅的編程嘛有其予人爭論的一面：

• 無書面的詳細的規格說明書
• 客戶代表予人安排佇咧專案當中
• 程式設計師以結對的方式做工課
• 測試驅動的開發絕大多數設計活動攏趕緊過，閣漸漸進式的，開始一个「上簡單的可能工課的物件」並彼陣其需要時間（測試失敗）才增加複雜性。單元測試促成做設計紀律。

參考文獻

來源

冊

• 肯特 ・ 貝克：《 誠致使編程解析：攬變化》，Addison-Wesley , ISBN 二孵空一百六十一知六千四百十六
• 阿里斯代而已 ・ 褲本：《 扭掠軟體開發》，Addison-Wesley , ISBN 二孵空一百六十九石九千六百九十九
• 雷劍文：《 超越傳統的軟體開發—— 足致使編程的幻象佮真實》，電子工業出版社，ISBN 七刣一百二十一刣六百五十七-X
• Lui , Kim Man 雷劍文，Software Development Rhythms : Harmonizing Agile Practices for Synergy , John Wiley and Sons , 兩千空八（http : / / as . wiley . com / WileyCDA / WileyTitle / productCd 鋪四四七千空七陽三千八百六十一 . html）

延伸閱讀

• Ken Auer and Roy Miller . _ Extreme Programming Applied : Playing To Win _ , Addison–Wesley .
• Ken Auer ; Ron Jeffries ; Jeff Canna ; Glen B . Alleman ; Lisa Crispin ; Janet Gregory . Are Testers eXtinct ? How Can Testers Contribute to XP Teams ? . Springer-Verlag . 兩千空二 . doi : 十 . 三分之一千空七刣五百四十五五十六百七十二孵四 \ _ 五十 .
• Kent Beck : _ Extreme Programming Explained : Embrace Change _ , Addison–Wesley .
• Kent Beck and Martin Fowler : _ Planning Extreme Programming _ , Addison–Wesley .
• Kent Beck and Cynthia Andres . _ Extreme Programming Explained : Embrace Change , Second Edition _ , Addison–Wesley .
• Alistair Cockburn : _ Agile Software Development _ , Addison–Wesley .
• Martin Fowler : _ Refactoring : Improving the Design of Existing Code _ , Addison–Wesley .
• Harvey Herela ( 兩千空五 ) . Case Study : The Chrysler Comprehensive Compensation System . Galen Lab , U . C . Irvine .
• Jim Highsmith . _ Agile Software Development Ecosystems _ , Addison–Wesley .
• Ron Jeffries , Ann Anderson and Chet Hendrickson ( 兩千 ) , _ Extreme Programming Installed _ , Addison–Wesley .
• Craig Larman & V . Basili ( 兩千空三 ) . " Iterative and Incremental Development : A Brief History " , Computer ( IEEE Computer Society ) 三十六 ( 六 ) : 四十七–五十六 .
• Matt Stephens and Doug Rosenberg ( 兩千空三 ) . _ Extreme Programming Refactored : The Case Against XP _ , Apress .
• Waldner , JB . ( 兩千空八 ) . " Nanocomputers and Swarm Intelligence " . In : ISTE , 兩百二十五–兩百五十六 .

外部連結

• 沃德 ・ 坎寧安的網站，極致的編程，關於極致編程佮相關主題的閣較濟資訊。
• 面對客戶的極致編程介紹
• 羅恩 ・ 傑曉斯的網路雜誌 XProgramming . com-真致使編程資源
• ExtremeProgramming . org
• 馬特史蒂芬斯的批評網站，對極致編程的問題誠深的批評（參見這个該頁得著閣較濟對極致編程的批評的連結）
• 馬丁 ・ 福勒論極致的編程
• 合作編程，足致使編程實踐
• 敏捷軟體開發的宣言
• 工具：" XPlanner "
• 工具：" XPWeb "
• 來自 CiteSeer 的引文
• 來自方法佮工具雜誌的文章脫離極致編程的極致編程測試：利用敏捷測試實踐的優勢
• 來自方法佮工具雜誌的文章結對程式設計真正會當改進你的專案？