接續上一篇文章的標題，本文主要分享一下XP模型的相關知識。
XP模型
1.XP模型簡介
Extreme Programming（極限編程，簡稱XP）是由KentBeck在1996年基於增量模型發展而提出的。是一種近螺旋式的開發方法，將復雜的開發過程分解為一個個相對比較簡單的小周期，將系統細分為多個可以在較短周期解決的子模塊，且強調測試、代碼質量和及早的發現問題。通過積極的交流、反饋以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際情況及時地調整開發過程。【來自https://baike.baidu.com/item/%E6%9E%81%E9%99%90%E7%BC%96%E7%A8%8B/4690591?fr=aladdin】
2.核心實踐
所謂極限，就是所有環節都做到極致，花最短的時間，用最簡單的方法做最好的軟件。查詢大量資料后，XP讓我感覺它讓軟件開發變得輕松愉快並富有有活力。從它“溝通、簡單、反饋、勇氣和謙遜”的核心價值就可以看出。並且XP是基於敏捷開發的核心價值和目標的，而敏捷開發是以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發的。基於這樣的思想，XP也對開發團隊作了13個核心實踐的要求（如圖所示，圖片來源百度百科），挑選其中幾條來做分享。
首先是團隊合作。每種軟件開發過程模型都強調團隊合作，但XP與眾多模型不同的是，只要是對項目作出貢獻的人，都是團隊中的一員，其中包括用戶。因為從項目的計划到最后驗收，用戶才是最清楚自己需求的人。並且不是每個成員的工作別人不能插手，而是互相交流協作的。
結對編程。在XP中，所有的代碼都是由兩個程序員在同一台機器上一起寫的。或許這一點很難理解，雖然我們常說人多力量大。但是在開發軟件項目這件事情上，我們從來都不希望和別人一起編寫同一段代碼。因為每個人的想法和編程習慣都不一樣。但使用XP模型確強行要求執行這一點，而后來事實也證明，這樣極大地提高了工作強度和工作效率。畢竟這樣做保證了所有的代碼、設計和單元測試都至少被另一個人檢查復核過。並且在項目開發過程中，對人員流動較大的項目，這是一條很好的策略。
集體擁有代碼。在許多模型中，項目開發之初都會對開發人員進行功能模塊的分工，對應功能模塊的開發人員只負責維護自己功能，並且他們也不喜歡別人隨意修改自己的代碼。這就導致開發團隊人員互相之間都不了解彼此的功能，也不熟悉彼此的代碼。這就使得代碼維護具有很大的局限性（因為可能由於負責某一功能的程序員技術的局限性導致維護困難）。但XP中卻是大家共同擁有代碼，在前面也已經提到，每個成員都可以閱讀別人的代碼，並發現和糾正其中的錯誤。這樣所有代碼都是整個團隊共同開發完成的，而不是只是一兩個技術較牛的人寫的。並且由整個團隊所有人開發出來的系統，代碼質量都非常好。當然，這樣做的基礎是每個成員都嚴格遵循項目開發的代碼規范。
3.過程
· 計划項目（PlanningGame）
主要預測交付日期前可以完成多少工作，現在和下一步的工作內容有哪些。針對這兩個問題，XP中又提出了軟件發布計划和周期開發計划兩個過程。軟件發布計划主要是分析用戶需求，制定一個大致的計划。而周期開發計划則是前面提到的，XP把復雜的系統划分為多個
· 驗收測試
與瀑布模型不同的時，XP模型的驗收測試不是在所有軟件功能都完成之后再進行測試，而是用戶對每個周期完成時所發布的系統進行評估，這樣軟件開發對用戶來說更具有實際意義，也體現了XP作為一種近螺旋式開發方式的特點。同時，驗收測試和測試驅動的開發也保證了各個周期所發布的產品的一致性和可靠性。
· 小規模發布
即前面提到的，XP模型把復雜的軟件開發過程分解為多個周期，將系統分解為多個簡單的活動或者任務。因此每個周期開發的需求都是用戶需要的東西，XP模型就要求頻繁地發布軟件，可能的話，應該每天都發布一個新的版本，在對系統某一部分做了修改或者完善之后，也應該立刻發布新版本。
總的來說，XP模型就是為滿足用戶需求而存在的。不僅讓用戶參與到開發中來，並且其小規模發布和驗收測試也讓用戶切實感受軟件的存在。個人比較喜歡XP模型的核心實踐，讓人感覺軟件開發的過程不那么枯燥和痛苦，而是積極向上。