健康檢查與持續整合

內湖捷運剛營運沒多久，上演了素人乘客高空走鋼軌的精采表演。據事後諸葛亮表示，內湖捷運的問題出在沒有拜乖乖「測試時間不足」。

前幾天看到一則新聞，一名二十多歲的青年，罹患了大腸癌末期。要篩檢大腸癌，最有效的方法莫過於照大腸鏡，就是用一根前端有攝影鏡頭的管子通到你的屁屁裡面拍照。在民風如此純樸的台灣，願意自動受此特殊待遇的人只存在於特定族群，因此很多大腸癌被發現的時候都已經是末期。

阿邊最近因為生病戒護就醫，才發現膽固醇指數破表（A太多 吃太好），血管隨時有爆管的危險。阿邊心裡非常疑惑，耶，我上次健康檢查都很正常啊，怎麼會搞到破病住院？一定是台灣的人權不彰。阿邊今年已經五十好幾了，上次健康檢查已是N年前。

上面這三個故事說明了「測試」或是「檢驗」這件事情的三個困難點：

(1) 沒時間，我沒時間（用唱的）…
(2) 不方便
(3) 太昂貴

如果有人發明一種全身健康檢查的技術，做一次只要十分鐘，費用不到一百元，這樣健保就可以補助全台灣兩千x百萬國民每個月每半年做一次全身健康檢查，相信可真正達到早期發現，早期治療的效果。

很遺憾，這種應用在人體的技術尚未發明。但是，Teddy卻可以在軟體開發領域觀察到類似的效果，為自己開發軟體的健康把關。這種傳說中神奇的技術，就叫做「持續整合」（continuous integration）。

用白話文來說，持續整合就是不斷的「操」你所開發的軟體。操的方法千奇百怪，從最簡單的編譯、單元測試，到稍為複雜一點的靜態程式碼分析、系統測試等，只要你想的出來，都可以加進去。在37度C大太陽底下按表操課之後，品質不良的軟體，很快的就像成功嶺上的草莓兵一樣，不支倒地，被偶一偶一送到醫院，住院觀察。品質優良的軟體，則順利通過所有嚴酷的考驗，等待下一次出操訓練。

為了證明Teddy有受過正統軟體工程教育，以下以UML class diagrams 來說明持續整合裡面的重要概念。先以健康檢查例子說明。請看圖1，一個「人」，有很多個「器官」，某些器官與其他器官有很高的「相依性」，例如，胃潰瘍通常會造成食道灼傷或是十二指腸潰瘍。有錢的大爺們可以幫每一個器官做很多次的「健康檢查」，每次健康檢查會使用一種以上的「檢查儀器」。例如，檢查胃潰瘍可以照X光（事先要吞下噁心的白色顯影液）或是照胃鏡。檢查儀器會產生一種以上的「檢查報告」。每一個檢查儀器所產生的檢查報告，都必須要在特定的「檢查環境」之下，才有意義。例如，飯前、飯後測量血糖含量其結果就大不相同。換句話說，相同儀器，不同環境，會產生不同的檢查報告。





軟體和人很像，現在看到圖2。一個軟體產品（Product），由一個以上的軟體專案（Project）組成。例如，一個會計系統產品，可能包含處裡資料庫的（子）專案、處裡會計邏輯的專案、處裡畫面的專案、以及產生報表的專案。這些專案，彼此之間可能會有關係，例如，報表專案需要參考到資料庫專案。每一個專案，可以被建構（Build）很多次（被操很多次），每一次的建構，都可以指定要怎麼操這個專案。一個建構活動（Builder）就是一種操的方法，例如，編譯程式、單元測試、產生JavaDoc文件、產生JAR檔、產生安裝程式，都是一種建構活動。每一個建構活動，會依據不同的執行環境（Environment），產生不同的產物（Artifact）。例如，Java編譯活動（JavaCompileBuilder），在32位元作業系統與62位元作業系統下（不同的Environment），會產生不同的.class檔案以及每一隻Java程式編譯成功或失敗的結果報表。




持續整合的觀念很簡單，效益很大，但是就像大多數的best practices，都具有「知易行難」的共通點。小蔣名言：「有些事情，現在不做，明天就會後悔」準確地預言程式設計師必須過著「debug 的人生」。

什麼，講到嘴角都是沫，你還是不懂持續整合是什麼碗糕？挖哩勒…別氣、別氣，洪蘭有云：每個人開竅的時間都不同。好把，這裡還有一個大易輸入法的例子：持續整合之於軟體，就好比試紙之於金色拱門的那一鍋油。要不是有這小傢伙，可以在短短的時間內驗出這一鍋油是否會讓客人們提早上天堂，各位勇敢的台灣人還不知道要繼續勇敢多久呢。