極限程式設計 - 實踐
極限程式設計中有四個基本活動。它們是：
編碼
測試
傾聽
設計
這四個基本活動需要根據極限程式設計的原則進行結構化。為實現這一點，定義了極限程式設計實踐。
這12個極限程式設計實踐實現了極限程式設計的目標，並且在其中一個實踐薄弱的情況下，其他實踐的優勢將彌補它。
“極限程式設計解釋”的作者肯特·貝克 (Kent Beck) 將 12 個極限程式設計實踐定義如下：
計劃遊戲
短迭代釋出
隱喻
簡單設計
測試
重構
結對程式設計
集體程式碼所有制
持續整合
40 小時工作制
現場客戶
編碼規範
極限程式設計的四個領域
極限程式設計實踐可以分為四個領域：
快速、細緻的反饋：
測試
現場客戶
結對程式設計
持續流程：
持續整合
重構
短迭代釋出
共享理解：
計劃遊戲
簡單設計
隱喻
集體程式碼所有制
編碼規範
開發者福利：
40 小時工作制
在本章中，您將詳細瞭解極限程式設計實踐以及每種實踐的優勢。
極限程式設計實踐一覽
下圖顯示了極限程式設計是如何圍繞極限程式設計實踐展開的：
計劃遊戲
極限程式設計中的主要規劃過程稱為計劃遊戲。遊戲是每次迭代（通常每週一次）都會進行的會議。計劃遊戲的目的是透過結合業務優先順序和技術估算來快速確定下一個版本的範圍。隨著現實超越計劃，更新計劃。
業務和開發需要同步做出決策。業務決策和開發的技術決策必須相互協調。
業務人員需要決定：
範圍 - 系統在生產中具有價值需要解決多少問題？業務人員能夠理解什麼是不夠的，什麼又是過多的。
優先順序 - 如果你可以選擇，你想要哪個？業務人員比開發人員更能根據客戶的意見來確定這一點。
版本的構成 - 在業務方面，軟體比沒有軟體更好之前需要做多少工作？開發人員對這個問題的直覺可能完全錯誤。
版本的日期 - 軟體（或部分軟體）的存在會在哪些重要日期產生重大影響？
技術人員需要決定：
估算 - 實現一個功能需要多長時間？
後果 - 只有在瞭解技術後果的情況下，才應做出戰略性業務決策。開發人員需要解釋後果。
流程 - 工作和團隊將如何組織？團隊需要適應其運營的文化。軟體必須編寫良好，而不是保留封閉文化的非理性。
詳細排程 - 在一個版本中，哪些故事應該首先完成？開發人員需要自由地首先安排開發中最冒險的部分，以降低專案的整體風險。在此約束下，他們仍然傾向於將業務優先順序提前到開發中，從而減少由於時間限制而必須在釋出開發結束時刪除重要故事的可能性。
因此，計劃是客戶、業務人員和開發人員之間合作的結果。
計劃遊戲 - 優勢
計劃遊戲具有以下優勢：
減少浪費在無用功能上的時間
提高客戶對功能成本的認識
減少計劃中的猜測工作
短迭代釋出
您應該快速將簡單的系統投入生產，然後以非常短的週期釋出新版本。每個版本都應該儘可能小，以便它是：
可在短週期內完成
包含最有價值和最直接的業務需求
一個可執行的系統
短週期的持續時間可能因需要構建的軟體而異。但是，需要確保選擇最短的持續時間。
短迭代釋出 - 優勢
短迭代釋出的優勢在於：
頻繁的反饋
跟蹤
減少整體專案延誤的可能性
隱喻
根據劍橋線上詞典 - 隱喻是一種表達方式，經常在文學作品中發現，它透過指代被認為具有與該人或物體相似特徵的事物來描述一個人或物體。例如，“心靈是一片海洋”和“城市是一片叢林”都是隱喻。
您應該用一個簡單的共享故事來指導整個開發，講述整個系統的工作方式。您可以將隱喻視為要構建的系統的架構，以便所有參與開發的人都易於理解。
隱喻由特定領域的元素組成，並顯示它們的互連性。使用的語言是領域語言。為了識別技術實體，需要一致地使用隱喻中的詞語。
隨著開發的進行和隱喻的成熟，整個團隊將從檢查隱喻中找到新的靈感。
良好架構的目標是為每個人提供一個連貫的故事來工作，一個易於被業務和技術成員共享的故事。因此，在極限程式設計中，透過要求隱喻，我們很可能會得到一個易於溝通和闡述的架構。
隱喻 - 優勢
隱喻的優勢在於：
鼓勵使用系統的通用術語
減少流行語和術語
一種快速簡便的解釋系統的方法
簡單設計
系統應該在任何給定時刻儘可能簡單地設計。額外的複雜性一旦被發現就會被消除。
在任何給定時間的軟體的正確設計是：
執行所有測試
沒有重複的邏輯，例如並行的類層次結構
陳述對開發人員重要的每一個意圖
具有儘可能少的類和方法
為了獲得簡單的設計，請消除任何您可以消除的設計元素，而不會違反前三條規則。這與建議相反 - 為今天實現，為明天設計。如果您認為未來是不確定的，並且您可以快速增強設計，那麼不要在猜測上新增任何功能。
簡單設計 - 優勢
簡單設計的優勢在於：
不會浪費時間新增多餘的功能
更容易理解正在發生的事情
使重構和集體所有制成為可能
幫助程式設計師保持正軌
測試
開發人員不斷編寫單元測試，開發需要透過這些測試才能繼續。客戶編寫測試以驗證功能是否已實現。測試是自動化的，因此它們成為系統的一部分，並且可以持續執行以確保系統的執行。結果是一個能夠接受變化的系統。
測試 - 優勢
測試的優勢在於：
單元測試促進測試完整性
測試優先為開發人員設定目標
自動化提供了套件迴歸測試
重構
在實現功能時，開發人員總是會問是否有方法更改現有程式碼以簡化新增功能。在新增功能後，開發人員會問他們現在是否可以看到如何簡化程式碼，同時仍然執行所有測試。他們重構系統而不改變其行為以消除重複，改進溝通，簡化或增加靈活性。這稱為重構。
重構 - 優勢
重構的優勢在於：
促使開發人員主動改進整個產品
提高開發人員對系統的瞭解
結對程式設計
在結對程式設計中，所有程式碼都是由一臺機器上的兩名開發人員編寫的，使用一個鍵盤和一個滑鼠。
每對中有兩個角色：
第一位開發人員（擁有鍵盤和滑鼠的人）考慮如何最好地在此處實現此方法。
另一位開發人員則從更戰略的角度思考：
這種方法是否可行？
還可能有哪些其他測試用例無效？
是否有辦法簡化整個系統，以便當前問題消失？
配對是動態的。這意味著兩個角色 A 和 B 可以交換位置，或者他們可以與其他團隊成員配對。更常見的是，團隊中的任何人都可以作為合作伙伴。例如，如果您對某個您不熟悉的領域的某個任務負有責任，您可以要求最近有經驗的人與您配對。
結對程式設計 - 優勢
結對程式設計的優勢在於：
三個臭皮匠，頂個諸葛亮
專注
兩個人更有可能回答以下問題：
這種方法是否可行？
有哪些測試用例可能無效？
有什麼辦法簡化它？
集體程式碼所有制
在極限程式設計中，整個團隊對整個系統負責。雖然每個人都瞭解每個部分的一些內容，但並非每個人都同樣瞭解每個部分。
如果一對正在工作，並且他們看到改進程式碼的機會，他們就會繼續改進它。
集體程式碼所有制 - 優勢
集體程式碼所有制的優勢在於：
有助於減輕離職團隊成員造成的損失。
促使開發人員對整個系統負責，而不是對系統的一部分負責。
持續整合
程式碼每天整合和測試多次，一次一組更改。一個簡單的做法是有一臺專門用於整合的機器。一對準備好整合的程式碼：
在機器空閒時坐下。
載入當前版本。
載入他們的更改（檢查並解決任何衝突）。
執行測試直到它們透過（100% 正確）。
一次整合一組更改有助於瞭解誰應該修復失敗的測試。答案是當前配對，因為上一對將測試留在了 100%。他們可能不得不丟棄他們所做的工作並重新開始，因為他們可能不知道足夠的程式碼來實現該功能。
持續整合 - 優勢
持續整合的優勢在於：
減少了本來很長的持續時間。
由於釋出前所需的時間最短，因此可以實現短迭代釋出實踐。
40 小時工作制
極限程式設計強調每個團隊成員每週的工作時間有限，基於可持續性，最多每週45小時。如果有人工作時間超過這個時間，則被認為是加班。加班最多允許一週。此做法旨在確保每個團隊成員保持精力充沛、富有創造力、謹慎細緻且充滿信心。
每週40小時制——優勢
每週40小時制的優勢在於：
大多數開發人員超過40小時後效率就會下降。
重視開發人員的福祉。
迫使管理層尋找真正的解決方案。
現場客戶
在團隊中加入一位真實的、全職的現場使用者，以回答問題、解決爭議和設定小型優先順序。這位使用者不必只花費40小時在這個角色上，也可以專注於其他工作。
現場客戶——優勢
擁有現場客戶的優勢在於：
可以快速、準確地回答真實的開發問題。
確保開發出的產品正是所需的產品。
正確地確定功能優先順序。
編碼規範
開發人員編寫的所有程式碼都符合以下規則：
透過程式碼進行溝通。
儘可能減少工作量。
遵循“只寫一次”原則（避免重複程式碼）。
團隊成員自願遵守。
這些規則在極限程式設計中是必要的，因為所有開發人員：
可以從系統的某一部分切換到系統的另一部分。
每天輪換搭檔幾次。
不斷重構彼此的程式碼。
如果不遵循這些規則，開發人員就會傾向於採用不同的編碼實踐，程式碼隨著時間的推移會變得不一致，並且無法確定團隊中誰編寫了哪段程式碼。
編碼規範——優勢
編碼規範的優勢在於：
減少開發人員重構他人程式碼的時間。
減少對內部註釋的需求。
要求程式碼清晰、明確。