Knowledge Gained by Daily Builds Are Your Friend

在讀完無痛軟體時程之後，ㄚ琪要繼續讀每日編譯(Daily Build)是你的好朋友，『1982年我家人帶了一台很早期的IBM-PC到以色列…』，咦，以色列？約耳是猶太人，這下我可有興趣看他的生平了，他15歲的時候回以色列，看起來是很忠信的以色列人，那麼每日編譯是你的好朋友，不就跟每日讀經文是你的好朋友有關聯！

『REP循環的概念。REP代表「Read, Eval, Print」，是敘述lisp直譯器一直在做的事：它會讀取你的輸入，把它求出來，然後印出結果。』約耳進一步解釋成『寫程式的動作其實是一種放大版的REP循環，是一種名為編輯-編譯-測試的循環。』像ㄚ琪在寫程式的時候，就會從很小的程式開始寫，寫個幾行，就編譯看看有沒有錯，然後執行看看結果對不對，然後再接下來繼續寫，我承認這個方法有點笨，因為看到有些人他可以一氣呵成把整篇的程式都寫完後再編譯執行，就很佩服，不過我的方法我覺得是很小心的一種，萬一功力沒有那種火候，寫一大篇程式有編譯錯誤可能還好，萬一執行錯誤時那偵錯可能就代誌大條了！

所以個人在寫程式可能不需要每日編譯吧，可能吧！因為約耳提到的案例是團隊的開發，那麼我會覺得每日編譯看起來會很需要，所以『每日編譯是一個自動、每天、完整的編譯動作，把全部原始程式重新編譯一遍。

自動 – 因為你會用cron(在UNIX上)或是Tash Scheduler服務(在Windows上)安排每天在固定的時間編譯程式。

每天 – 更密集也可以。連續編譯更吸引人，不過由於版本管理的問題(待會就會提到)可能做不到。

完整 – 你的程式可能有很多版本。』

每日編譯的好處：

1. 1. 『當某個問題修好之後，測試人員可以很快就拿到新版本重測，看看問題是否真的修好了。
   2. 開發人員可以比較放心自己的修改不會破壞到要出貨的1024種版本，不必真的自己準備一套OS/2來測。
   3. 在每日編譯開始前把程式存入版本管理系統的開發人員會比較安心，因為知道自己不會因為放入某些會「破壞(break)」編譯的東西而干擾到別人。所謂破壞編譯就是讓編譯無法進行。這對整個程式團隊來說就等於Windows的藍色當機畫面，當某個程式師忘記把新增的檔案放入版本管理系統時常常出現。在他們的機器上都正常，不過等別人由版本管理系統拿程式出來編譯時，就會遇到連結錯誤，然後什麼事都不能繼續做。
   4. 行銷部門及beta測試者之類的外部人員都必須用到尚未完成的產品，這時候就可以選一個已知相當穩定的版本暫時用一陣子。
   5. 如果有維護一個存放所有每日編譯結果的檔案庫，當你發現很奇怪的新問題又搞不懂原因時，可以利用二分法搜尋過去的檔案，找出問題問題第一次出現的時間。再配合良好的版本管理，或許就能找出哪一些更動造成這個問題。
   6. 當某個測試人員回報一個程式師認為已修正的問題時，測試人員可以說在哪一版看到這個問題。然後程式師可以回頭查查自己什麼時候把修正存入，就知道是否真的修好了。 』
   7. 實施的方法：
   8. 『建立最終編譯結果的所有動作都必須由每日編譯腳本完成，這一點非常重要。
   9. 以下是絕不能容許的行為：在準備發行程式時發現一隻小蟲，於是你就在每日編譯伺服器上直接把它修好然後發行。每日編譯有條黃金定律：只有從完整取出程式碼開始，並經過完全重新的每日編譯所製作的程式才可以發行。
   10. 把你的編譯器的警告等級開到最高(在微軟的世界裡就是-W4，用gcc的話就是-Wall)，並且設定成即使遇到最小的警告都要停止編譯。
   11. 把你的編譯器的警告等級開到最高(在微軟的世界裡就是-W4，用gcc的話就是-Wall)，並且設定成即使遇到最小的警告都要停止編譯。
   12. 如果每日編譯失敗，就要冒險停止整個團體的作業。全部動作都停下來重新編譯，直到問題修正為止。有時候一天之內會做很多次每日編譯動作。
   13. 你的每日編譯腳本應該用電子郵件把失敗狀況回報給整個開發團隊。用grep把”error”或”warning”記錄抓出來再放入電郵裡也不是難事。腳本也要能把狀態報告附加到大家都能看到的HTML網頁上，這樣程式師和測試人員就能很快地知道哪個編譯結果是成功的。
   14. 在微軟的Excel團隊有一個很有效的規則：破壞編譯的人必須開始負責照顧每日編譯，直到有其他新的人破壞才換手。這樣做能讓大家有強烈動機維持編譯正常運作，而且幾乎每個人都會輪流照顧編譯動作，所以大家都會知道編譯結果是怎麼產生的。
   15. 如果你的團體成員都在同一個時區工作，午餐時間會是個進行編譯的好時間。這樣子大家都在午餐前把最新的程式放入版本管理，大家吃飯時就進行編譯。等人吃完午餐回來，如果編譯失敗大家就來解決問題。只要編譯正常完成，大家就可以取出最新的版本繼續作業，不必擔心會被編譯錯誤卡住。
   16. 如果你的團體分散在兩個時間，每日編譯的時間得適當安排，以確保第一個時區的人不會卡到另一個時區。在Juno的團體中，紐約的開發人員會在下午7點把程式放入版本管理然後回家。如果他們破壞了編譯，在印度海得拉巴的團隊正要工作(大約是紐約時間下午8點)卻因此卡住一整天。於是我們開始實施兩次每日編譯，分別在兩邊下班前一小時進行，就完全解掉這個問題了。』
       • 1. 有些針對每日編譯工具的討論
         2. 實施每日編譯非常重要，所以列入邁向高品質的12個步驟。
         3. 在G. Pascal Zachary的書Showstopper裡有很多關於Windows NT團體編譯製作(每週一次)的趣事。
         4. Steve McConnell在這裡談每日編譯。
         5. ㄚ琪在這裡幾乎快引用了全部文章的內容了，這其實不足為怪，因為ㄚ琪根本沒有每日編譯的習慣，所以這篇文章看起來就很覺陌生，既然陌生就無法將文章再摘錄一些重點出來，直覺所有內容都恨有重要，其實就是因為不熟了關係嘛，希望這一篇研讀後可以化為行動力來執行，願與ㄚ琪的朋友共勉之！

   進階閱讀：

感謝你看到這裡，很快就可以離開了，但最好的獎勵行動就是按一下幫我分享或留言，感恩喔～