談談XP（3e）：Primary Practice

Mar. 10 12:03~13:35

 

介紹完Sit Together、Whole Team、Informative Workspace、Energized Work、Pair Programming、Story、Weekly Cycle、Quarterly Cycle，今天繼續介紹三個XP Primary Practice：

• Slack（鬆弛）：如果你用「積極時程（aggressive schedule）」來管理專案與分配工作，很可能會適得其反，不但沒有提升產出，反而打擊員工士氣並且產生更多的問題。這個實務做法Teddy在〈鬆弛讓你更敏捷（1）〉、〈鬆弛讓你更敏捷（2）：每日工時〉、〈鬆弛讓你更敏捷（3）：不好的進度表〉曾經介紹過，也推薦鄉民們讀《別讓員工瞎忙（Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency）》這本書，讀完之後對於這一條實務做法會有更深的了解。
• Ten-Minute Build（十分鐘建構）：這條實務做法建議開發團隊要將建構工作自動化，並且在十分鐘之內完成建構整個系統以及跑完所有的測試案例的工作。太長的建構時間會導致開發團隊比較不願意去執行建構，因此很有可能經過比較長的間隔才發現系統有問題，此時就必須花費更多的時間才能夠找出發生問題的原因。請參考〈Ten-Minute Build〉。

「十分鐘建構」是一個理想值，如果鄉民們的軟體建構工作無法在十分鐘之內完成，可以思考一下如何達到這個理想值。如果是因為建構工作沒有自動化，每次都要交給團隊中的特定成員以手動或半自動的方式來完成，那麼就請先自動化建構工作。如果是因為系統太大（例如要建構整個Android OS）導致建構時間太長，則可以考慮要如何只建構系統異動的部分。如果跑完全部的測試案例需要花太多的時間，則可以考慮如何讓建構程式自動挑選出與本次異動相關的測試案例來執行，以縮短建構時間。

Teddy自己的經驗，以前在開發系統的時候，一開始也是無法達到「十分鐘建構」，後來將建構腳本改成兩種：第一種方式只建構本次修改到的專案，然後使用事先建構好的其他相依專案模組的二進制檔案，直接打包產生一個新的安裝程式，這樣便可在兩分鐘之內（不包含執行測試程式）同時產生出Windows平台與Linux平台的安裝程式（每一個安裝程式約200 MB）。剩下來的八分多鐘，就可以挑選團隊認為比較重要的測試案例來執行，這樣子就可以確保每次建構都在十分鐘左右完成。

第二種方式則是建構整個系統並且執行全部的測試案例（單元測試、整合測試、驗收測試）。隨著測試案例增多，執行一次完整建構的時間會長達7~8小時（因為是跨平台系統，所以需要測試的平台很多）。這種建構專案則安排在下班之後每天執行一次。

實際上建構腳本還可以分成更多不同的設定，例如，編譯某個專案並執行單元測試、由事先編譯好的的函式庫快速產生安裝程式（不執行任何測試案例）、產生安裝程式外加執行核心驗收測試案例、全部建構並執行單元測試….。總之，團隊可以依據情況，在「建構時間」與「建構完整性」這兩者之前取得一個平衡點。

• Continuous Integration（持續整合）：每隔幾個小時就整合與測試一次。很多開發人員都知道採用「divide and conquer（分而治之）」技巧來解決問題，但Kent Beck提到軟體開發不僅是「divide and conquer」的問題，而是「divide, conquer, and integrate」（分而治之加上整合）。整合時間有時難以預估或是被忽略，當開發人員做完成了「divide and conquer」之後，以為「剩下來的事情只要把東西拼起來之後就好了」，而沒有發現其實很多問題都出在「整合」上面。只要看看最近綠營的台北市長提名過程，就知道「整合」有多麼困難了。所以，只要系統有異動（新增或修改程式、調整設定檔、升級軟體或元件），就應該要經常、持續地整合與測試一次整個系統（執行一次建構工作），以便早期發生問題，早期修正。

持續整合有兩種模式：同步與非同步。在同步持續整合中，開發人員會等待產生整合結果之後才繼續開發工作。反之，在非同步續整合中，一旦啟動持續整合之後，開發人員可以繼續開發工作，待整合完畢之後會收到整合結果通知。

感覺起來非同步持續整合好像比較酷，比較厲害，因為開發人員可以不用等待整合結果，繼續手邊的開發工作。但Kent Beck說他比較傾向採用同步持續整合，因為在等待整合結果的時間，可以稍作休息思考剛剛所開發的內容。而且如果在整合結果出現之前就急著繼續開發，萬一整合發生失敗（這是非常有可能的情況），要再回頭去追問題，就比較麻煩（因為剛剛出問題的程式已經被改變了）。最後，因為人都很沒耐心，不想等太久，所以採用同步持續整合會讓開發人員想辦法讓自己的建構可以維持在十分鐘以內。而因為每次建構時間不會太久，所以開發人員也更願意頻繁地執行整合。

Teddy在部落格中已經提過好幾次持續整合，例如〈健康檢查與持續整合〉、〈開發人員應遵循的七項持續整合要領〉、〈持續整合工程師應遵循的十項要領（上）〉、〈持續整合工程師應遵循的十項要領（下）〉。

***

友藏內心獨白：橡皮筋拉得太緊可是會斷掉的。