2023年9月26日
極限程式設計的一般思想
索引：1. 應用領域
2. 開發流程圖標
3. 開發原則
4. 設計原則
5. 程式設計原則
6. 團隊成員角色
宣告([email protected])：
正文：extreme programming（xp，極限程式設計） 是一種輕量級的軟體開發方法，它使用快速的反饋，大量而迅速的交流，經過保證的測試來最大限度的滿足使用者的需求。
1. 應用領域：
xp特別適用於需求經常改變的領域：客戶可能對系統的功能並沒有清晰的認識，或者系統的需求經常需要變動。xp也適用於風險比較高的專案，當開發人員面對乙個新的領域或技術時，xp可以幫助減低風險。
xp適用於中小專案，人員在2-12人之間；特別地，在需求經常變化或風險比較高的專案中，少量而有效的xp開發人員效率要遠遠高於大量的開發人員。
2. xp的開發流程圖標：
152.3.176.116
3. xp的開發原則
(1) 使用者需求（user stories）
user stories描述使用者所見的系統功能，但避免使用大量的文件，user stories由使用者編寫（不僅限於描述使用者介面）。user stories使用使用者的語言編寫，不使用技術性的語言，每個user stories限於幾句話。user stories用於在release plan會議上對開發時間進行評估，也用於產生功能測試（acceptance test），必須使用可以自動進行的功能測試保證軟體的正確性。user stories與傳統的使用者需求的區別在於詳細的程度，user stories並不會確定需求的每個細節，它只是用來簡單的描述系統功能，供開發人員進行估計開發進度，在開發過程中，開發人員和使用者會不斷的交流以討論細節問題。user story應該專注於功能，不應該過分注重使用者介面等細節。乙個user story在1-3周的時間完成，如果估計超過3周，說明user story太大了，需要細分。
(2) 產品計畫（release plan）
release plan用於規劃開發周期。開發人員對每個user story估計開發時間（在不被打斷，無其他工作情況下的開發時間，包括單元測試與功能測試），使用者對user stories給出優先順序。注意，release plan會議並不制訂每個開發周期的詳細計畫。它的目的是使得使用者、開發人員和管理者，在功能、資源、工期以及工程質量上達成一致。
(3) 階段性產品（small release）
經常性地發布階段性產品是xp的乙個原則，每乙個階段性產品都必須實現部分功能的整合，盡快地提交給使用者以獲得反饋，並及時調整。團隊在開發過程中收集資料，以便於對自己的開發速度進行評估。
(4) 迭代開發周期 (iteration)
迭代開發周期，即為每個階段性產品的開發周期，約為1-3周。每個迭代開發的計畫，應於上乙個階段性產品發布後，根據使用者反饋而制定，以靈活地適應變化。要注重每個迭代週期的時間限制：當團隊覺得不能按時完成時，宜重新評估，減少一些user stories。
(5) 迭代開發計畫 (iteration plan)
在每個迭代開發周期開始的時候召開會議，從產品計畫(release plan)中選擇還沒有實現的使用者最迫切需要的user stories。上乙個迭代開發中沒有通過功能測試的功能也要在本次迭代中實現。user stories和失敗的測試被分解成程式設計任務，使用技術語言編寫，作為迭代開發計畫的詳細描述。程式設計師主動領取任務並估計完成時間，每個task應該在1-3天內完成，超過3天的task應該被細分。如果整個團隊需要的時間多於或少於規定的iteration時間，則調整user stories。
(6) 站立會議
工作開始之前，開5-10分鐘的站立會議。站立的目的是為了強迫節省時間。會議的目的是交流，提出存在的問題，但不要在會議上解決問題。開乙個所有人員參加的短會比多個個別人員參加的會議要高效。在會議上提出的問題可以由少數人討論解決，這個少數人參加的會議如果涉及到**，可以在計算機前討論。
(7) 人員流動
不要使每個開發人員侷限於一項工作，不要使某項工作依賴於乙個開發人員，增加知識共享，減少資訊孤島，多進行交流和培訓。當專案中的所有人對所有模組都了解並可以進行開發時是效率最高的。
(8) 隨機應變
xp並不是一成不變的，當團隊覺得需要修改的時候，可以根據自己的情況進行修改，任何修改都要經過整個團隊的討論和達成一致
4. xp的產品設計原則
(1) 簡潔；
(2) 盡量避免術語，使用使用者可以理解的比喻；
(3) 採用crc card，鼓勵多人參與同乙個物件的設計；
(4) 杜絕過早的功能設計；
(5) 及時進行**重構（refactoring），提高質量和可讀性，保持設計簡單。重構的前提是，**已經完全通過測試。
5. xp的程式設計原則
(1) 使用者是專案組的重要組成
使用者的參加貫穿整個開發過程，使用者與開發人員之間的交流是重要的；
(2) 統一的編碼標準
這是保持**整潔和共享**的基礎，強調紀律，不鼓勵個性發揮；
(3)測試第一
在編寫某個物件的**之前先編寫單元測試
**，且由同乙個程式設計師完成，是xp的乙個特點。先編寫測試**可以使程式設計師更好的理解需求，避免直接編碼造成的理解偏差。實踐證明，它所需要的程式設計工作量要遠少於「先編碼，後寫測試**」的方式。測試**也是檢驗程式是否完成的標準。編碼工作應該是以下工作的迴圈：
a) 編寫測試**；b) 執行測試程式，確認失敗；c) 編寫且僅編寫剛好可以實現這個測試程式所要求功能的**；d) 執行測試程式，確認成功
(4)結對程式設計
結對程式設計是xp的特色，它要求兩個程式設計師在一台計算機上同時進行程式設計工作。共用滑鼠和鍵盤，通常乙個人進行戰略上的思考，程式架構和函式，類之間的關係，乙個人進行輸入和戰術上的思考，完成函式和類。兩個人可以經常交換角色。結對程式設計需要一段時間學習和適應，實踐證明，結對程式設計並不消耗更多的時間(人*小時)，但是**的質量得到很大的提高。（注：避免將兩個新手放在乙個pair中）
(5) 串聯整合
為了保證源**庫的狀態是可標識的，同一時間，只允許乙個pair的程式進行整和和測試，這樣可以縮小問題產生的範圍。只要有可能就進行**整合，週期可以在幾個小時，最好不要超過一天。經常的整合可以避免錯誤的積累，可以增加可重用的**。在乙個pair認為適當的時候並通過了所 有的單元測試，就可以進行整合，整合後的**必須通過測試。同一時間，只允許乙個pair進行整合。不同的pair可以在自己的機器上隨時進行整合和測試。
(6) 共同擁有**
鼓勵每個人對專案中的任何人提 出新的想法，任何開發人員對專案中的任何**都可以進行增加功能，改正錯誤和重構。沒有**或開發人員成為瓶頸。為了達到這個目標，任何的**都必須有相應的測試**，任何**的修改必須100%通過測試。必須加強開發人員的交流和知識共享，必須 堅持統一編碼標準。pair programming可以經常交換夥伴。
(7) 優化工作放在最後
先使系統能夠正常工作，不要猜測系統的瓶頸，要實際測量
(8) 拒絕加班
不要長時間的加班，大多數加班並不能挽回已有的延遲，連續超過兩個星期的加班說明有問題存在。向乙個已經延遲的專案填加人員也不是乙個好的選擇。
6. xp團隊中的成員角色：
(1) 使用者
在xp中，使用者是專案組的一部分，使用者負責編寫use stories，確定優先順序，和開發人員討論需求，編寫、執行功能測試，驅動每次迭代開發。
(2) 開發人員
與使用者討論user stories，估計開發時間，將user stories細化成程式設計任務；編寫單元測試；編碼；進行重構；整合及測試，保證100%通過
(3) 協調員
負責對外聯絡，組織團隊，獲取必要的資源，管理團隊
(4) 監督
跟蹤產品計畫，迭代開發計畫，以及功能測試狀況
(5) 教練
起顧問指導作用，監督進展，確保過程和規則，必要時改變過程，幫助解決問題，也可以參加結對程式設計。
XP實踐的質疑
客戶作為團隊成員 xp強調面對面的交流，強調物理空間的聚合，但事實是客戶與開發團隊在物理空間上協同工作基本是不可能的，無論這裡的客戶是指掏錢買單的還是業務人員 至於尋找可以完全替代客戶的人加入團隊更是無稽 結對程式設計 這裡又有些過於理想化，同乙個專案用兩倍的人去完成，除非老闆大腦短路，這種不計成本...
敏捷實踐之XP極限程式設計
團隊協作 whole team 規劃策略 the planning game 主要思想就是先快速地制定乙份概要的計畫，然後隨著專案細節的不斷清晰，再逐步完善這份計畫,產生的結果是一套使用者故事及後續的一兩次迭代的概要計畫。結對程式設計 pair programming 所有的產品軟體都是由兩個程式設...
實驗三 敏捷開發與XP實踐
1.在idea中使用工具 code reformate code 把下面 重新格式化，再研究一下code選單，找出一項讓自己感覺最好用的功能。public class codestandard public static void main string args stringbuffer buff...