首頁 / 文章導讀 / 約耳趣談軟體 / Knowledge Gained by Daily Builds Are Your Friend

Knowledge Gained by Daily Builds Are Your Friend

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

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

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

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

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

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

每日編譯的好處:

    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. ㄚ琪在這裡幾乎快引用了全部文章的內容了,這其實不足為怪,因為ㄚ琪根本沒有每日編譯的習慣,所以這篇文章看起來就很覺陌生,既然陌生就無法將文章再摘錄一些重點出來,直覺所有內容都恨有重要,其實就是因為不熟了關係嘛,希望這一篇研讀後可以化為行動力來執行,願與ㄚ琪的朋友共勉之!
    17. 進階閱讀:

Print Friendly, PDF & Email
馬上成為工作達人的Fans

About ㄚ琪

工作達人Fun Taiwan的創辦者及總編,可以在這裡更認識他。

發表迴響

你的電子郵件位址並不會被公開。 Required fields are marked *

*

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料

Scroll To Top