決定將持續整合、自動測試的頻率設為每天進行一次。大家還為整個過程起了一個很好聽的名字　——“AutoVerify”，意指自動進行產品的驗證。同時大家還討論了一些實現細節。

大家晚上下班之前，把自己Check　Out出來的程式碼Check　In到程式碼庫中。AutoVerify程式會在每晚8：00自動從程式碼庫中提取最新的程式碼，自動進行編譯，編譯成功後同時啟動兩項任務：一個程序進行自動UT，另外一個程序進行打包並自動部署到測試環境中。這是因為UT的時間非常長，需要兩個小時左右才能跑完全部的868個測試用例。這樣二者並行進行，可以節省兩個小時的時間，多跑一些迴歸測試用例。雖然也有可能UT測試用例失敗，但應該是不影響產品在測試環境下執行的，可以打包並安裝。安裝成功後，開始自動迴歸測試。

因為歷史遺留下來的測試用例太多，一個晚上不可能跑完所有的測試用例，應該只跑一些核心的最重要的測試用例，這個篩選工作由阿紫負責。只有在週末的時候，利用兩個整天的時間，才把所有的測試用例全部執行一遍。AutoVerify需要自動收集統計資訊，譬如執行了多少個測試用例，透過率是多少等，把這些結果匯總下來。在第二天早上　9：00，AutoVerify自動把一個晚上自動驗證的結果透過郵件發給阿朱和阿捷，由阿朱負責檢查。為了減少垃圾郵件，只有在任何一個環節出現問題的時候，AutoVerify才會把郵件發給大家。此時，阿朱負責把出錯日誌轉給相應的人，收到該郵件的人要第一時間解決。

在討論完AutoVerify後，大民利用剩餘的時間，把XP提上了議事日程。

“我們這次實際上一次性地用到了XP的兩個重要實踐：持續整合和自動測試。其實，XP還有一些其他的很好的實踐，有些已經透過Scrum這個框架體現出來，譬如小發行版（Small　Releases）等，但是XP其他一些程式設計實踐也還是值得我們嘗試的。”

“嗯，我贊同這個觀點，Scrum本身沒有規定具體的程式設計實踐，我們正好可以用XP來補充！大民你接著說一些適合我們自己團隊的XP實踐吧！”阿捷說。

“第一個應該是結對程式設計，其次是編碼標準、簡單增量設計、重構、測試驅動開發等，還有程式碼集體所有權。”

小寶插了一句：“關於程式碼集體所有權，其實咱們已經做得很不錯了！大家看，咱們因為模組多，程式碼多，一直也沒有也不太可能規定具體哪塊的程式碼歸誰擁有，而是任何一個人都有權修改任何一段程式碼。誰破壞某個模組，誰要負責進行修補。”

“嗯，這點我贊同。不過我想明確提出來，強調一下，我們應該繼續保持這個優良傳統！同時因為程式碼歸集體所有，所以大家就都要遵循統一的編碼標準才行。”　。　想看書來

第11章　你開車，我導航（2）

“沒錯，我們歷史遺留下來的程式碼太多太雜，這裡面既有老美寫的，還有印度人寫的，再加上咱們自己寫的。真夠百花齊放的！”

“是啊！短時間內，我們是不可能吧所有的程式碼都統一起來的。雖然也有一些類似aStyle等自動化程式碼美化工具，可以一次性地把所有程式碼整合成符合統一編碼標準的形式，但這樣做的風險實在太大！萬一出了問題，因為所有的程式碼都改動了，反而沒辦法跟蹤，不容易解決。”大民顯然仔細分析過這個問題。

小寶點了點頭：“我想我們可以一步一步來，只有我們需要改動哪個檔案時，才對該檔案按照編碼標準進行一次最佳化。不過話又說回來，我們現在的編碼標準有點亂，也有點過時了，需要重新整理一下才行。”

“要不這個任務就交給你？”阿捷問道。

“行啊！其實我已經整理了一半了。”小寶的積極主動性還是挺高的，“我們原來有一個基礎版本，但有些東西已經過時了，另外還要加些新的規則進來。”

大民接過話頭：“關於增量設計和重構這塊我們做得還不夠，當然這也是有歷史原因的。咱們以前一直都是瀑布式開發，非常重設計的。僅僅針對設計，咱們以前的流程會產生概要設計文件、外部介面文件、詳細設計文件、測試策略、測試計劃等，從敏捷的角度來講，我們應該做一些簡化。”

“嗯，是有必要精簡，但應該精簡到什麼程度呢？”阿朱問道。

“我覺得……”大民稍微頓了一下，似乎是故意為了強調：“