名詞的解釋和相關內容:
用戶故事
事實上用戶故事是極限編程13個實踐(請看文末第一篇參考文章)中的計划.
計划游戲的主要思想就是先快速地制定一份概要的計划，然后隨着項目細節的不斷清晰，再逐步完善這份計划。計划游戲產生的結果是一套用戶故事及后續的一兩次迭代的概要計划。
首先客戶和開發人員坐在同一間屋子里，每個人都准備一支筆、一些用於記錄用戶故事的紙片，最好再准備一個白板，就可以開始了。
- 客戶編寫故事：由客戶談論系統應該完成什么功能，然后用通俗的自然語言，使用自己的語匯，將其寫在卡片上，這也就是用戶故事。
- 開發人員進行估算：首先客戶按優先級將用戶故事分成必須要有、希望有、如果有更好三類，然后開發人員對每個用戶故事進行估算，先從高優先級開始估算。如果在估算的時候，感到有一些故事太大，不容易進行估算，或者是估算的結果超過 2人/周，那么就應該對其進行分解，拆成 2 個或者多個小故事。
- 確定迭代的周期：接下來就是確定本次迭代的時間周期，這可以根據實際的情況進行確定，不過最佳的迭代周期是 2~3 周。有了迭代的時間之后，再結合參與的開發人數，算出可以完成的工作量總數。然后根據估算的結果，與客戶協商，挑出時間上夠、優先級合適的用戶故事組合，形成計划。
隱喻
相對而言，隱喻這一個最佳實踐是最令人費解的。什么是隱喻呢？根據詞典中的解釋是：“一種語言的表達手段，它用來暗示字面意義不相似的事物之間的相似之處”。那么這在軟件開發中又有什么用呢？總結而言，常常用於四個方面。
- 尋求共識：也就是鼓勵開發人員在尋求問題共識時，可以借用一些溝通雙方都比較熟悉的事物來做類比，從而幫助大家更好地理解解決方案的關鍵結構，也就是更好地理解系統是什么、能做什么。
- 發明共享詞匯：通過隱喻，有助於提出一個用來表示對象、對象間的關系通用名稱。例如，策略模式（用來表示可以實現多種不同策略的設計模式）、工廠模式（用來表示可以按需“生產”出所需類得設計模式）等。
- 創新的武器：有的時候，可以借助其他東西來找到解決問題的新途徑。例如：“我們可以將工作流看做一個生產線”。
- 描述體系結構：體系結構是比較抽象的，引入隱喻能夠大大減輕理解的復雜度。例如管道體系結構就是指兩個構件之間通過一條傳遞消息的“管道”進行通信。
當然，如果能夠找到合適的隱喻是十分快樂的，但並不是每種情況都可以找到恰當的隱喻，你也沒有必要強求
代碼編程
簡單設計
- 簡單的設計呢？XP 實踐者們總結的具體、可操作的思考方法。
- 首先寫測試代碼：具體將在后面詳細描述。
- 保持每個類只負責一件事：SRP（單一職責原則）是面向對象設計的基礎原則之一。
- 使用 Demeter（迪米特）法則：迪米特法則，也稱為 LoD 法則、最少知識原則。也就是指一個對象應當對其他對象盡可能少地了解。用隱喻的方法來解釋的話就是“只與你直接的朋友通信”、“不要和陌生人說話”。
- 使用 CRC 卡片進行探索。
測試先行／測試驅動開發
當我第一次看到“測試先行”這個概念的時候，我的第一感覺就是不解，陷入了“程序都還沒有寫出來，測試什么呀？”的迷思。我開始天馬行空地尋求相關的隱喻，終於找到了能夠啟發我的工匠，首先，我們來看看兩個不同的工匠是如何工作的吧。
- 工匠一：先拉上一根水平線，砌每一塊磚時，都與這跟水平線進行比較，使得每一塊磚都保持水平。
- 工匠二：先將一排磚都砌完，然后再拉上一根水平線，看看哪些磚有問題，對有問題的磚進行適當的調整。
你會選擇哪種工作方法呢？你一定會罵工匠二笨吧！這樣多浪費時間呀！然而你自己想想，你平時在編寫程序的時候又是怎么做的呢？我們就是按工匠二的方法在工作呀！甚至有時候比工匠二還笨，是整面牆都砌完了，直接進行“集成測試”，經常讓整面的牆倒塌。看到這里，你還會覺得自己的方法高明嗎？這個連工匠都明白的道理，自己卻畫地為牢呀。
不僅我們沒有采用工匠一的工作方法，甚至有的時候程序員會以“開發工作太緊張”為理由，而忽略測試工作。但這樣卻導致了一個惡性循環，越是沒有空編寫測試程序，代碼的效率與質量越差，花在找 Bug、解決 Bug 的時間也越來越多，實際產能大打降低。由於產能降低了，因此時間更緊張，壓力更大。你想想，為什么不拉上一根水平線呢？難道，我們不能夠將后面浪費的時間花在單元測試上，使得我們的程序一開始就更健壯，更加易於修改嗎？不過，編寫測試程序當然要比拉一條水平線難道多，所以我們需要引入“自動化測試工具”，免費的 xUnit 測試框架就是你最佳的選擇。
重構
重構時一種對代碼進行改進而不影響功能實現的技術，XP 需要開發人員在聞到代碼的壞味道時，有重構代碼的勇氣。重構的目的是降低變化引發的風險，使得代碼優化更加容易。通常重構發生在兩種情況之下。
- 實現某個特性之前：嘗試改變現有的代碼結構，以使得實現新的特性更加容易。
- 實現某個特性之后：檢查剛剛寫完的代碼后，認真檢查一下，看是否能夠進行簡化。
在《重構》一書中，作者 Martin Fowler 提示我們：在考慮重構時，應該要養成編寫並經常運行測試代碼的習慣；要先編寫代碼，再進行重構；把每一次增加功能都當做一次重構的好時機；將每一個糾正錯誤當做一次重構的重要時機。同時，該書中也列出大量需要重構的情況和重構方法。
最后類似地，給還沒有足夠勇氣進行重構的程序員打幾劑強心針：
- XP 提倡集體代碼所有制，因此你可以大膽地在任何需要修改的地方做改動。
- 由於在 XP 項目組中有完整的編碼標准，因此在重構前無須重新定義格式。
- 在重構中遇到困難，和你結對編程的伙伴能夠為你提供有效的幫助。
- 簡單的設計，會給重構帶來很大的幫助。
- 測試先行讓你擁有了一個有效的檢驗器，隨時運行一下就知道你重構的工作是否帶來了影響。
- 由於 XP 在持續集成，因此你重構所帶來的破壞很快就能夠暴露，並且得以解決。
重構技術是對簡單性設計的一個良好的補充，也是 XP 中重視“優質工作”的體現，這也是優秀的程序員必備的一項技能。
參考文章:
1.淺談極限編程 https://blog.csdn.net/qq_32867467/article/details/91348723
2.軟件工程導論(第6版) 張海藩、牟永敏 著 / 清華大學出版社