最近，一直在看robert martin的《敏捷軟體開發—原則、模式和實踐》，該文中以極限程式設計（
xp）來講述敏捷的實踐。看完有關於
xp實踐的部分，對
xp基本的主張和如何去實踐有了乙個大概的了解。但是，一直有個問題在我腦海中，那就是這種開發實踐方式為什麼會被稱為「極限程式設計」？看完這部分之後，對這個問題只有一些模模糊糊的理解，並沒有明確的答案。於是，又找到
kent beck
的《解析極限程式設計—擁抱變化》。對過對這兩本書的閱讀，上述的那個問題的答案似乎逐漸清晰。所以在這裡，談一下自己對極限程式設計的極限的理解。
極限程式設計之所以被稱為極限，我認為是源自於它的設計哲學，那就是將大家公認的好的東西做到極致。它所倡導的實踐就是將大家公認為好的實踐努力做到最好。我們可以從它所主張的實踐來分析它的「極限」意義。首先，極限程式設計的具體實踐包括：完整團隊、計畫遊戲、客戶測試、簡單設計、結對程式設計、測試驅動開發、重構、持續整合、集體**所有權、編碼標準、隱喻和可持續的速度。
敏捷宣言裡有一條：客戶合作勝過合同談判，所以對敏捷來說，客戶合作是好的。既然客戶合作是好的，極限程式設計就要把這種合作做到最緊密，主張將客戶作為團隊的成員來決定業務優先順序。這就是所謂的「完整團隊」。
由於人的思維慣性和程式設計師的樂觀主義，任何開發方法都強調要進行**評審。所以，**評審是好的。極限程式設計就把**評審做到極致，每一行**產生的時候就進行了評審。這就是結對程式設計，兩個開發人員對著一台電腦開發。
測試時保證系統質量的強大**，所以測試是好的。極限程式設計就把測試的作用發揮到極限，於是就要求始終測試，包括單元測試和功能測試。而且測試先行，測試先行，當實現某個功能時，先寫乙個原有程式不能通過的測試，然後實現該功能，使之能通過該測試。這就是客戶測試和測試驅動開發。
軟體開發中，設計的重要性是不言而喻的。既然設計這麼重要，極限程式設計就要求把設計當做每個人日常事務的一部分，當做最重要的工作。所以主張不停地重構，去調整**結構、去除冗餘**，使設計結構清晰、**簡潔。
敏捷主張簡單設計。既簡單是好的，極限程式設計就保證系統設計永遠是最簡單的，於是始終把系統保持為支援其當前功能的最簡單設計。極限程式設計只關注於對當前的需求來進行設計、編碼，而不去理會明天、下週或者下個月會出現的需求。
系統的體系結構是系統的骨架，對整個系統起決定性作用。所以體系結構是非常重要的，極限程式設計就要求所有人不斷地進行定義和完善體系結構的工作，並提供系統組成的元素的詞彙表，這個詞彙表就是系統的隱喻。
單元測試只是針對某個功能，但乙個系統不是簡單的功能疊加，其中涉及到很多通訊與協作，這就需要整合測試。所以整合測試是好的。極限程式設計就增加整合測試的密度，那在一天內多次整合測試，並針對每乙個功能做整合。這就是要持續整合。
敏捷認為，交付越頻繁，最後交付的軟體質量就越高。要提高交付密度，就需要縮短迭代週期。所以迭代周期短是好的。極限程式設計主張將迭代時間放到盡可能的短。一般而言，兩周乙個迭代是比較合適的。
從上述實踐，我們不難得知，極限程式設計就是在挑戰極限！
極限程式設計下的極限測試
極限測試主要由兩部分測試組成 單元測試和驗收測試。單元測試是極限測試中主要採用的測試方法，它具有兩條簡單規則 所有 模組在編碼開始之前必須設計好單元測試用例。在產品發布之前需要通過單元測試。極限測試中的單元測試和普通的單元測試之間最大的區別是 極限測試中的單元測試必須在模組編碼之前就完成設計和生成。...
關於極限挑戰五
追了下極限挑戰五，作為這個節目的忠實觀眾，我只想說 迪麗熱巴挺好看的 沒辦法，一大早給我說系統又出現大面積掉線，來都來了，就掙點積分吧 周一再調休。至少乙個企業級專案從感官上專案結構得是這個樣子吧 不然還是繼續停留在 觀察黑洞都要分布式望遠鏡，你還不學springboot？配置項說明server.p...
XP極限程式設計
結隊程式設計是xp極限程式設計的乙個關鍵實踐，如果把結隊程式設計放到整個xp裡面會更容易體現出它的價值，所以我覺得分析結隊程式設計的乙個整體思路是 1 適用場景 xp的適用性在 什麼樣的專案中適合採用xp，在這樣的專案中xp可以起到什麼作用。如果離開了適用場景，xp的適用性都要重新考慮，所以就更不用...