l

2009年7月23日 星期四

健康檢查與持續整合

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

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

阿邊最近因為生病戒護就醫,才發現膽固醇指數破表(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 的人生

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

3 則留言:

  1. 給個意見參考一下。

    您那個圖1的類別結構可能有些問題。

    「健康檢查」是一個交易事件 (transaction),檢查報告可能是細項 (line-item)。

    一般而言,抓這類結構可以先從交易事件開始,以此為核心,然後再去關聯到相關的人、地、物等。

    僅供參考。 ^^

    回覆刪除
  2. To kenming168:

    沒想到有這麼認真的鄉民還幫Teddy挑錯,謝謝啦。最近比較忙,Teddy再找時間把圖修改一下。

    回覆刪除
  3. 您可以思考~ 到底抓 Class 的目的為何?

    雖然是 "Mapping from the reality",但也不是無限上綱。

    如何抓出 "essential" 本質性的類別,是軟體設計人員修練的基礎功夫。

    回覆刪除