極限程式設計 - 支援性實踐
如果孤立地實施極限程式設計實踐，可能會很薄弱，從而導致失敗。在極限程式設計中，所有實踐都需要作為一個整體來考慮，以便它們相互支援。一個實踐的弱點會被其他實踐的優勢所彌補。
在本章中，我們將重點關注每種實踐如果孤立實施可能存在的弱點。我們將瞭解極限程式設計如何在與其他實踐結合使用時支援這種實踐克服弱點。
計劃遊戲 – 來自其他 XP 實踐的支援
在本節中，我們將瞭解計劃遊戲的弱點以及其他 XP 實踐如何支援它。
計劃遊戲 – 缺點
計劃遊戲的缺點是，您不可能僅憑一個粗略的計劃就開始開發，並且您不能不斷更新計劃，因為這會花費太長時間並讓客戶感到不安。
計劃遊戲與其他 XP 實踐
其他 XP 實踐以以下方式支援計劃遊戲：
在計劃遊戲中，客戶也參與更新計劃，基於開發人員提供的估算。
您進行短週期釋出，以便計劃中的任何錯誤最多隻會產生幾周或幾個月的影響。
您的客戶與團隊一起工作，因此他們可以快速發現潛在的變化和改進機會（線上客戶）。
持續測試幫助開發人員和客戶確定立即需要什麼。
因此，您可以從一個簡單的計劃開始開發，並在進行過程中不斷完善它。
短週期釋出 – 來自其他 XP 實踐的支援
短週期釋出 – 缺點
您不可能在幾個月後投入生產。您當然不可能以每天到每隔幾個月為週期的頻率釋出新系統版本。這是因為您需要時間來吸收新的需求，並將更改整合到當前程式碼中。
短週期釋出與其他 XP 實踐。
其他 XP 實踐以以下方式支援短週期釋出：
計劃遊戲幫助您處理最有價值的故事，因此即使是一個小型系統也會具有業務價值。
持續整合使打包釋出的成本降到最低。
測試將缺陷率降低到足以使釋出前不需要冗長的測試周期的程度。
您可以進行簡單的設計，足以滿足本次釋出的需求，而不是永遠都適用。
因此，您可以在開發開始後不久就進行短週期釋出。
隱喻 – 來自其他 XP 實踐的支援
您不可能僅僅依靠一個隱喻就開始開發。它可能缺乏足夠的細節，而且您可能是錯的。
隱喻與其他 XP 實踐
其他 XP 實踐以以下方式支援隱喻：
透過結對程式設計，您將從已實現的程式碼和測試中獲得快速具體的反饋，瞭解隱喻是否正常工作。
您的現場客戶可以輕鬆地使用隱喻來談論系統。
持續重構允許您改進您對隱喻在實現中含義的理解。
簡單設計幫助您與隱喻建立對映。
因此，您可以僅僅依靠一個隱喻就開始開發。
簡單設計 – 來自其他 XP 實踐的支援
簡單設計 - 缺點
您不可能只為今天的程式碼設計足夠的設計，而且您的設計可能無法繼續發展系統。
簡單設計與其他 XP 實踐。
其他 XP 實踐以以下方式支援簡單設計：
重構允許您進行更改。
透過整體隱喻，您可以確保未來的設計更改將趨於遵循收斂路徑。
結對程式設計幫助您確信您正在進行一個有效的工作簡單設計。
40 小時工作制幫助您專注於正確的設計。
持續單元測試和客戶測試確保您的簡單設計走在正軌上。
因此，您可以針對今天做最好的設計，無需進行推測。
測試 – 來自其他 XP 實踐的支援
測試 - 缺點
您可能會認為：
您不可能編寫所有這些測試。
編寫測試可能需要花費太多時間。
開發人員不會編寫測試。
測試與其他 XP 實踐
其他 XP 實踐以以下方式支援測試：
簡單設計使編寫測試變得容易。
重構允許您確定哪些測試是必要的。
透過結對程式設計，即使您想不出另一個測試，您的搭檔也可以。您可以讓您的搭檔接管鍵盤並執行測試，當您看到所有測試都執行成功時，您會感到自信。
集體所有權確保具有所需技能的開發人員正在處理任何複雜的編碼和測試部分。
持續整合並立即執行每組由搭檔進行的更改的測試，以確保：
如果 100% 的測試透過，則新程式碼有效，或者
如果任何測試失敗，則表示是該搭檔的程式碼導致系統失敗，以便可以立即撤消更改，並且搭檔可以重新開始編碼，並清楚地瞭解他們正在實現的功能。
短週期釋出確保為客戶提供一個可執行的系統以進行測試並提供反饋。
線上客戶將有時間執行所有測試並立即對可執行的系統提供反饋。
計劃遊戲確保在測試後獲取客戶的反饋，以規劃下一次釋出。
因此，開發人員和客戶將編寫測試。此外，測試是自動化的，以確保其餘極限程式設計的正常工作。
重構 – 來自其他 XP 實踐的支援
重構 - 缺點
您不可能一直重構系統的設計。這將：
花費太長時間。
難以控制，並且
很可能破壞系統。
重構與其他 XP 實踐
其他 XP 實踐以以下方式支援重構：
透過集體所有權，您可以在需要的地方進行更改。
透過編碼標準，您無需在重構之前進行重新格式化。
透過結對程式設計，您有勇氣處理棘手的重構。
透過簡單設計，重構更容易。
透過隱喻，您可以輕鬆地進行溝通。
透過測試，您不太可能在不知情的情況下破壞某些東西。
透過持續整合，如果您意外地破壞了某些東西，或者您的重構與其他人的工作發生衝突，您將在幾個小時內得知。
透過 40 小時工作制，您得到了休息，因此您更有勇氣並且不太可能犯錯。
因此，您可以隨時重構，只要您有機會：
使系統更簡單
減少重複
更清晰地進行溝通
結對程式設計 – 來自其他 XP 實踐的支援
結對程式設計 - 弱點
您不可能所有程式碼都結對編寫。這會太慢。如果兩個人相處不好，會使情況變得困難。
結對程式設計與其他 XP 實踐。
其他 XP 實踐以以下方式支援結對程式設計：
編碼標準減少了衝突。
透過 40 小時工作制，每個人都精力充沛且專注，進一步減少了不必要討論的機會。
搭檔一起編寫測試，讓他們有機會在著手實現部分之前統一理解。
隱喻幫助搭檔為命名和基本設計奠定基礎
簡單設計使搭檔能夠達成共識。
重構幫助搭檔討論並在使系統簡單化方面做出共同決定。
持續整合使搭檔有機會在出現任何錯誤時進行糾正，因此當另一個人進行一些實驗時，搭檔不會反對。
集體所有權使團隊能夠進行混合搭配，並允許他們保持融洽的關係。
因此，您可以所有程式碼都結對編寫。另一方面，如果團隊單獨工作，他們更有可能犯錯，過度設計並忽視其他實踐。
集體所有權 – 來自其他 XP 實踐的支援
集體所有權 – 缺點
您不可能讓每個人在系統的任何地方更改任何內容。因為有可能在不知情的情況下破壞系統，並且整合的成本會急劇上升。
集體所有權與其他 XP 實踐
其他 XP 實踐以以下方式支援集體所有權：
持續整合減少了衝突的可能性。
測試降低了意外破壞事物的可能性。
透過結對程式設計，您不太可能破壞程式碼，並且開發人員可以更快地瞭解他們可以有利地更改哪些內容。
透過編碼標準，您將不會在程式碼上發生衝突。
透過重構，您可以保持系統的簡單性，以便每個人都能理解它。
因此，當他們有機會改進系統時，任何人都可以在系統的任何地方更改程式碼。另一方面，如果沒有集體所有權，設計演變的速度會急劇下降。
持續整合 - 來自其他 XP 實踐的支援
持續整合 – 缺點
你不可能在僅僅幾個小時的工作後就進行整合，因為整合需要很長時間，並且存在太多衝突和意外破壞某些東西的可能性。
持續整合與其他XP實踐
其他XP實踐以以下方式支援持續整合：
快速測試可以幫助你瞭解你是否破壞了任何東西。
透過結對程式設計，需要整合的變更流減少了一半。
透過重構，程式碼被分解成更小的部分，從而降低了衝突的可能性。
透過程式碼規範，程式碼將保持一致。
短迭代確保了對系統的及時反饋。
集體程式碼所有權確保無論誰更改程式碼並進行整合，都將擁有對整個系統的完整檢視。
因此，你可以在幾個小時後進行整合。另一方面，如果你不快速整合，那麼衝突的可能性就會增加，整合成本也會急劇上升。
40小時工作制——其他XP實踐的支援
40小時工作制——缺點
你不可能每週工作40個小時。你無法在40小時內創造足夠的商業價值。
40小時工作制與其他XP實踐
其他XP實踐以以下方式支援40小時工作制：
計劃遊戲為你提供了更多有價值的工作去做。
計劃遊戲和測試的結合確保你只需要處理你計劃要做的事情。
簡單設計和重構使你能夠保持專注並按時完成。
結對程式設計幫助你處理你能處理的工作，並將其他工作與你的搭檔分享。
這些實踐作為一個整體幫助你以最高速度開發，因此你無法更快。
因此，你可以在40小時工作制中產生足夠的商業價值。另一方面，如果團隊無法保持精力充沛，那麼他們將無法執行其餘的實踐。
現場客戶——其他XP實踐的支援
現場客戶——缺點
你不可能讓一個真正的客戶全職加入團隊，而他們卻沒有任何產出。他們在其他地方可以為企業創造更大的價值。
現場客戶與其他XP實踐
其他XP實踐以以下方式支援現場客戶。
他們可以為專案創造價值：
在計劃遊戲中，為開發人員做出優先順序和範圍決策。
透過隱喻，為開發人員帶來對領域的清晰認識。
在測試中，編寫驗收測試並在每次短迭代後執行驗收測試。
因此，他們可以透過為專案做出貢獻，為組織創造更多價值。
程式碼規範——其他XP實踐的支援
程式碼規範——缺點
你不可能要求團隊按照通用標準編寫程式碼，因為開發人員通常都是個人主義者。
程式碼規範與其他XP實踐
其他XP實踐以以下方式支援程式碼規範：
結對程式設計使他們能夠輕鬆地適應必要的程式碼規範。
持續整合強制他們遵循標準，以便程式碼保持一致。
集體程式碼所有權鼓勵他們與標準保持一致，以便在任何需要的時候進行更改。