Ten-Minute Build

March 10 21:06~22:45

和 Teddy 差不多年紀的鄉民們應該還記得當年 SOS （大，小 S）紅遍大江南北的『十分鐘的戀愛 』這首歌：


（下課）十分鐘的戀愛　雖然有一點短暫
你的笑填滿我 心中所有的遺憾
（下課）十分鐘的感情　我將全部屬於你
多希望能夠永遠不分離

可惜做軟體的人沒那麼好命，平平是 10 分鐘，人家可以拿來談戀愛，咱們只能拿來 build 軟體...XD

***

話說當年 Teddy 在讀 Extreme Programming Explained: Embrace Change 這本書的時後，看到第 49 頁寫著某一個 XP 的 primary practices：


Ten-Minute Build
Automatically build the whole system and run all of the tests in ten minutes. A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback. A shorter build doesn't give you time to drink your coffee.


當時 Teddy 看到這裡其實沒什麼特別的感覺，喔，10 分鐘將整個軟體 build 完畢並跑完全部的測試...了解，收到....轉身後繼續過自己的日子....

好幾個月前聽指導教授說起某開發『倒航 導航軟體』的公司，因為 build 一次軟體要花很久（幾個小時吧）的時間，而且全公司就只有『一個人』知道要如何 build  這個軟體，所以經常會發生 programmers 應觀眾要求『私底下』先把軟體拿給客戶使用（這個客戶是公司內部的員工，需要用這個軟體來建地圖景點資料）。但是曾經發生過員工已經用『私底下版本』的軟體花了幾百個『人/時』來建地圖資料，但是就在『那個人』心血來潮去 build 一下軟體的時候，發現 build 失敗，軟體需要修改，因此導致之前所建立的地圖料要全部重新輸入的情形。

由於這是發生在別人身上的慘劇，聽的人哈哈一笑，總覺的『哪有那麼扯的事』也就沒放在心上，一直到最近 Teddy 聽學弟們提起 build 某個軟體所發生的問題，才慢慢體會到 Ten-Minute Build 這件事情的重要。實驗室有一個軟體全部重新 build 一次需要 15 分鐘左右。鄉民們可能會想『15 分鐘和 10 分鐘差不多啊，已經很不錯了』。錯，因為這 15 分鐘只是去 build 這個軟體並產生安裝程式所需的時間，並沒有跑『test cases』。要是真的去跑 test cases（用 JUnit 寫的 unit tests），可能會超過 2 小時以上。

其實這裡面有很多可以『改善』的地方：

• 花錢：沒錯，最快的方法就是花錢升級 build server。實驗室的的 build server 的記憶體只有 1 G ，CPU 2.4 GHZ，把記憶體升級到 2G 速度馬上提昇....... 30 秒......有點少...沒關係，如果可以把 build server 升級成新的 i7 電腦應該會快很多。
• 調整 Build Script：把 build script 寫得聰明一點，例如如果某個 sub-project 以及它所相依的其他 sub-project 如果都沒有異動就不需要重新 build ，或是只測試有異動的程式碼。
• 調整要執行的 test cases：雖然大家都說『用 JUnit 寫自動化單元測試』，但是嚴格講起來大部分的人所寫的『自動化單元測試』其實都不是『單元測試』，而是大小不一的『整合測試』。因為真正的單元測試要達到『test in Isolation 』，這樣才不會因為『別人帶賽』而導致 test 失敗；而且這樣的單元測試也才能跑得快。所以，在每次 build 的時候，可以先把那些『真正的單元測試』挑出來跑，看看能不能把整個時間控制在 10 分鐘。
• 電腦上晚班：在人腦下班之後，設定時間自動將整個軟體全部 build 一次並且將那些需要耗時執行的測試案例拿出來跑，這樣可以確定至少每天都有完整 build 一次整個軟體且將全部的測試案例執行完畢。

再想想之前上 Certified ScrumMaster 時 Bas 所說的話：『很多專案都因為測試設備不足而導致開發速度無法提昇』，這是一個很簡單的道理，但是否每個老闆都有這樣的認知，願意投入資源在改善『建構』與『測試』的環境就很難講了。

***

友藏內心獨白：該是換電腦的時候了。