l

2009年7月30日 星期四

攏是錢

今天看到一則新聞報導,國際泳會規定從明年開始,游泳選手將不可以穿俗稱「鯊魚裝」的高科技泳衣參加比賽。為什麼要有這種規定呢,為了公平。

首先,鯊魚裝價值不斐,Teddy如果沒記錯的話,一件好像要兩萬台幣起跳。這還不打緊,如果一件鯊魚裝可以穿個十年、八年的,這也就罷了,平均起來一天只要 5.4794520… NTD。問題就出在於一件鯊魚裝只能用10次左右,下水一次要2000 NTD,真是太超過了。所以,好野人就可以穿鯊魚裝訓練、比賽、獲獎,沒錢的就只能泡泡水一邊涼快。

這種用錢堆出來的成績,Teddy也曾經嘗試過。2005年某月某日,Teddy收到一份天上掉下來的禮物-免費參加Introduction to CMMI和Intermediate Concepts of CMMI課程(其實不是免費,而是Teddy的老闆出錢)。這兩個課程,加起來沒多少天,收費卻要六、七萬(詳細金額忘了),課後拿到兩張證書,很真貴珍貴。

想一想,老美真是厲害。聯邦政府沒錢就狂印美鈔。搞軟體的,可以開一大堆認證的課程,一樣都是用紙換摳摳,真是太棒了。

今天收到一封廣告信,希望Teddy報名十月22-23在台北舉辦的Certified Scrum Master培訓課程。Teddy已經應用Scrum有一年多的時間了,收到這封信,知道Certified Scrum Master課程居然在台北舉辦(之前曾經查過資料,好像都辦在歐、美比較多),覺得有點心動。看了一下費用…. 兩天,四萬…這件鯊魚裝有點貴,可惜Teddy已經畢業了,不然可以ㄠ老闆出錢…無緣的Certified Scrum Master。

2009年7月26日 星期日

我真是猜不透你啊:甘蔗汁篇

看過食神的人都應該還記得唐牛對著史提芬周大喊「我真是猜不透你呀」這個橋段。別以為這只是電影裡的情節,在日常生活中,心中經常會浮現小小的吶喊:「我真是猜不透你呀」。

今天晚上到南機場夜市買沙威瑪當晚餐,順便買了兩杯不加糖、不加冰的甘蔗汁。果汁店貼著大大的價目表,上面寫著:

甘蔗汁一杯30,兩杯50。

Teddy點了兩杯,幾分鐘後,店員卻只送來一杯。喔,原來是他沒聽清楚,沒關係,再加一杯就是了。此時,店員卻用刀子切開已經做好的那一杯甘蔗汁的封口。這是什麼情況,有必要倒掉重做兩杯新的給我嗎?想太多,繼續看下去。

此時,店員拿出兩個稍為小一點的杯子,把原先做好的那一杯甘蔗汁倒進這兩個小杯子裏面,裝滿了一杯,另一杯只有三分之ㄧ滿。接著,再現榨了一點甘蔗汁,把第二杯補滿。拿到兩小杯甘蔗汁的Teddy,乖乖的奉上50大洋。離開之前,忍不住問了店員:「買兩杯比較少嗎?」

是滴,店員往價目表一指,「上面有寫」,此時Teddy靠近一看,才發現,在原本大大的,兩杯50旁邊,後來用很細的筆加上了 360 cc 這幾個小字。(原本一杯應該是500 cc)

友藏內心獨白:「甘蔗汁,我真是猜不透你啊!」

2009年7月24日 星期五

持續整合樣式: Project (專案)

在開發軟體的過程中會產生各種不同的檔案,包含原始碼、編譯後的二進制程式碼、建構檔(build files)、測試程式、測試資料、資源檔、設定檔、函式庫、工具程式、API說明文件、軟體安裝程式、使用手冊等等。這些眾多的檔案,如果不妥善加以管理,將會使得整個開發流程變得一團亂,拖延軟體開發的進度,並造成軟體錯誤。

因此,為每一個軟體開發計畫建立一個軟體專案,妥善規劃專案結構以存放不同種類的檔案。專案結構主要受到下列幾項因素所影響:軟體開發團隊所使用的程式語言、整合開發環境(IDE, integrated development environment)、專案種類(桌面程式、網頁程式、外掛程式、J2EE程式、Web Services程式、嵌入式系統程式、驅動程式)、專案數量與大小、建構工具。

圖1為Eclipse新增專案精靈畫面,依據使用者所選擇的專案類型來建立基本的專案結構。圖2為一個典型的Java桌面程式專案。其中主要的目錄有:

(1) src:存放程式原始碼(production code)。
(2) test:存放測試程式原始碼(test code)。
(3) bin:存放編譯後的Java bytecode(.class檔案)。
(4) lib:存放專案所參考的函式庫(.jar 檔案)。
(5) dist:存放可散佈給使用者的所有檔案。
(6) testdata:存放開發時所使用的測試資料


圖1:Eclipse新增專案精靈可為不同類型的專案建立不同的結構



圖2:一個典型的Java應用程式專案結構

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 的人生

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

2009年7月16日 星期四

JNA (1): 在Java程式中直接呼叫Native Code

由於Java是一個跨平台的語言,因此許多與平台(作業系統)相依的功能,在Java語言中支援的並不多,此時如果你所負責的專案又一定要用到這些平台相依的功能(例如,讀寫實體記體體、IO Port),這時就只好請現場來賓幫忙,或是call out 求助於朋友。

Java設計者當然也很貼心地幫我們考量到這一點,提供了JNI(Java Native Interface)這個機制,讓Java程式可以三不五時的和外面的朋友串串門子。這些「外國朋友」為了不讓狗仔隊認出來,因此將自己偽裝成動態函式庫(Windows裡面的.dll檔或是Linux裡面的.lib檔)。由於這些外國朋友和Java講的語言不同,無法直接溝通,為了避免雞同鴨講,白忙一場,因此如果要透過JNI呼叫這些「外國朋友」(native code),還需要找一個翻譯(wrapper),讓Java透過這個wrapper來呼叫外國朋友。

看到這裡,你應該已經「ㄇㄨˇ煞煞」了。是滴,Teddy雖然寫了10多年的Java程式,但對於JNI的認識卻也只停留在紙上談兵的階段。像JNI這種麻煩的事,就交給年輕人去嘗試。Teddy今天要介紹一個「大易輸入法版本」的JNI,叫做JNA(Java Native Access)。透過JNA,就可以直接在Java裡面宣告你想要和哪些外國朋友溝通,然後直接呼叫他們。這種作法,很像在VB裡面呼叫Win32 API,或是在C#裡面呼叫dll。蝦米,這兩種都沒用過…沒關係,繼續看下去。

未滿十八歲的觀眾請注意,以下節目將在Eclipse環境中演出,若遇到看不懂而Teddy又懶的解釋的內容,請自動轉台。

(1) 建立一個新的Java專案,就叫它JNATest。



(2) 到JNA網站(https://jna.dev.java.net/)把 jna.jar抓下來,



(3) 在JNATest專案中,建立一個lib目錄,然後把剛剛抓下來的jna.jar輕輕放到這個目錄中。




(4) 在專案上按下滑鼠右鍵,選Properties,出現如下的畫面。點選左方的Java Build Path,再點選中間的Libraries,再按下右邊的Add JARs…按鈕,此時出現JAR Selection畫面(下下圖),把剛剛放到lib的jna.jar檔案加入。完成後畫面如下所示。






(5) 新增一個JnaMain class。



(6) 把下面程式打到 JnaMain中。



(7) 執行JnaMain,看到下面輸出結果。這樣你就可以在Java裡面呼叫C的printf函數了,黑皮!




報告完畢….




Teddy,給我「休蛋一A」,都沒解釋就演完啦?死豬!大家一定常常看到很多電影,也不都是沒什麼交代就結束了。說實話,程式的內容一半是從JNA網站上的範例山寨過來的,另一半則是從http://www.cplusplus.com/reference/clibrary/cstdio/printf/ 海盜過來的,所以這個例子就像是許多OO大師寫的文章一樣,懂得人不用看就知道,不懂的人看了還是不懂。Orz… 該睡了,吃水果先,好心的Teddy改天再解釋。

2009年7月11日 星期六

美簽:快速簽證之學術面談

五年前申請的美簽即將於今年八月過期,再加上有可能需要到美國出差,所以上個禮拜上網填寫了申請美簽的資料。資料填寫完畢之後,網頁秀出一個畫面,告知「您符合快速簽證服務」(我猜所有曾經獲得美簽又無不良紀錄的人可能都符合此資格),只要將面談時間安排在AM 10:30或PM 12:45便可享有快速簽證服務。沒想到台美關係已經這麼好了(幹的好,馬總統),記得Teddy五年前申請美簽時好像沒有快速簽證服務(這次是我第三次申請美簽,第一次申請後根本沒去美國,白白讓老美賺了簽證費)。既然有快速簽證,當然要享用一下身為台灣人的驕傲。上網查了一下預約的時段,所有下個禮拜AM 10:30 的時段都沒有名額了,因此就預約了7月10日 12:45這個時段。

話說當日11:40從公司搭計程車前往信義路的AIT,12:10就到了。預約的資料上面寫明:「早到者恕難進入」,先天奉公守法的Teddy,不敢提早闖關,所以就不怕死的先去漢堡王吃個快速午餐(大概15分鐘就用吃飽了),乖乖的等到12:45分再去。說也奇怪,Teddy提早了2分鐘到AIT門口,怎麼警衛已經讓人進入,趕快尾隨其他人一起進去。Teddy進去之後才發現,裡面已經有超過三、四十個人在排隊。哇哩勒,那Teddy剛剛在漢堡王是在等假的喔,AIT的資料有點廣告不實的嫌疑。

進去AIT之後,先把手機交給門口的警衛保管(警衛說,你這手機不錯喔…是滴,很識貨,這是有GPS功能智慧型PDA手機),然後經過金屬探測門。我前面有一位先生,還自動解下皮帶才經過金屬探測門(應該是常到美國的熟客,被訓練到自動寬衣解帶,還好沒脫鞋),我心裡就在想,阿又不是要搭飛機去美國,有必要這樣嗎。還好我的皮帶是夜市買的便宜貨,金屬含量不足,順利通過金屬探測門。接下來會有台灣源訊資料處理中心的人先幫申請者把資料檢查一遍,最重要的就是要看看我們有沒有乖乖的先去劃撥簽證費和給台灣源訊資料處理中心的資料處理費。資料檢查完畢之後,先坐在椅子上等待,順便強迫觀賞AIT製作的精美節目,告訴我們接下來要如何的過五關斬六將(最主要是說明掃描指紋的流程,先放左手的四根指頭,再換右手,最後是兩根大拇指),才可以得到一張「上國」恩賜的通行證。大約等不到10分鐘,那個節目也重複看了N遍之後,有一位長的很像海角七號裡面那個「茂伯」的服務人員,把我們帶到另一個房間內,開始正式的申請流程。

正式的申請流程其實只有四關,首先,把資料交給第一個窗口的人掃描。接著,到另一個窗口掃描指紋。第三關有一位留著長髮的小姐(簡稱P小姐)負責看每個人的資料,決定要不要把你叫過去詢問一番。運氣好的人,直接跳到第四關,就是拿回快遞回條(等於美簽通過),可以到快遞櫃檯辦理護照快遞。Teddy辦好前兩關之後,心理正在想這個快速簽證服務真好,等一下就可以離開,說不定還有時間去喝個咖啡什麼的。沒想到,「事情不是笨蛋想的那麼簡單」,不幸的事即將發生。

P小姐:「A先生,請問你是做什麼的」。此時Teddy依稀偷聽到生物…中研院…什麼什麼之類的。P小姐:「你需要到4號窗口面談」。P小姐:「B先生,請問你的學歷是?」。B先生:「博士」。P小姐:「你需要到4號窗口面談」。哇哩勒,就這樣,P小姐叫了三、四個人去4號窗口面談。此時P小姐叫到Kay(PS:Kay是Teddy的同事,當日一起去辦美簽),P小姐:「Kay,請問你是做什麼的」。Kay:「開發軟體的」。P小姐:你是學歷是?」Kay:「碩士」。沒事,過關。此時P小姐叫到Teddy。某驚、某驚,Teddy心想,同一個公司的,Kay都過關了,Teddy應該也沒事。P小姐:「Teddy先生,你和剛剛那位Kay小姐一樣,也是開發軟體的?」Teddy:「死豬」。P小姐:「什麼時候畢業的?」Teddy:「去年10月」。P小姐:你是學歷是?」Teddy:「博速」。P小姐:「你也要到4號窗口面談」。天啊,難道博速也是一種錯誤…就這樣,讓我經歷了前後加起來總時間長達約2.5小時的「快速簽證」。

P小姐一共叫了七、八個人到傳說中的「4號窗口」,奇怪的是,等了好一會,4號窗口一個人也沒有。過了可能有十幾分鐘後,見鬼了,P小姐居然一人分飾二角,又出現在4號窗口,接下來一連串匪夷所思的面談即將展開。我發現被叫去4號窗口的,好像不是學校的教授,就是有博士學歷的人。看了看4號窗口,上面寫著「學術面談」,我…靠…過來一點,Teddy一不進京趕考,二不應徵教職,這個「學術面談」是做什麼東東?難道美國政府要順便看看有沒有好的研究人才,挖角要美國上班? 想太多,接著看下去。

P小姐依據剛剛被她叫到4號窗口的順序,逐一地仔細盤問一番。由於問的內容很細(如果醫院門診醫生的問診時間有P小姐的十分之一病人就要偷笑了),又有七、八個人在等待,現場又沒有提供蘋果日報,整個過程真是無聊到爆。我覺得P小姐好像博士論文的口試委員,又像是系主任正在面試菜鳥助理教授,她問的問題包含了:你的專長、博士論文研究內容、研究方法、應用領域、工作內容、到美國參加什麼研討會、有發表論文嗎、發表幾篇、有無邀請函。至於P小姐問Teddy的問題則是:

P小姐:「你是什麼領域的?」
Teddy:「軟體工程」
P小姐:「你在公司做什麼研究?」
Teddy:「沒做研究,開發軟體,寫程式而已」

(P小姐露出疑惑的表情)

P小姐:「有想要繼續做研究嗎? 」
Teddy:「沒有」
P小姐:「這樣不是很可惜嗎?」
Teddy:「不會啊,我的博士研究是屬於實務的題目,就是要寫程式」
P小姐:「你到美國做什麼?」
Teddy:「總公司在美國,所以要員工準備好美簽,可能隨時要去出差」
P小姐:「所以你們台灣是分公司,要到headquarters 出差?」
Teddy:「對,我們是美商」

(P小姐拿出一張約半張A4大小的紙給我)

P小姐:「請用兩、三個句子寫上你的博士研究內容、應用領域、在公司負責的工作。寫好後再來找我」

後來Teddy發現每個人都被P小姐要求做相同的事。寫完之後再去排隊,我前面那位X先生好像是某科大的教授,P小姐又問了一堆問題,X先生很努力的解釋,順便要展示他真的是正港的教授,不是裝的。後來,很不幸的,X先生和另一位Y先生,都被P小姐要求填寫一張黃色的表格,並且要他們提供一份自己曾經發表過的論文列表、列舉一篇論文代表作(怎麼這些資料和教授升等審查那麼像? 還好沒要求SCI點數超過幾點才可以去美國)、到美國發表論文的摘要、邀請函、行程資料等等,傳真一份給P小姐。此外,P小姐還要他們自己三不五時到某個網址去查詢自己案件處理的狀態,整的流程大概要2~4週。最後還要帶上新、舊護照再跑一趟AIT辦理簽證。X先生和Y先生聽到臉都綠了(現代版的綠面人俑)。輪到Teddy了,我把寫好的考卷交給她。

P小姐:「這是什麼字?」
Teddy:「robustness」

P小姐:「這個字是?」
Teddy:「agile」

P小姐:「你的博士研究是做什麼的?」
Teddy:「就是研究怎麼讓軟體比較不會當機,如果有一個軟體跑三天會當,我們就看看能不能讓它跑五天再當」(友藏內心獨白:結果還不是當,這是哪門子爛研究…)

P小姐:「那你的研究方法是什麼」
Teddy:「就是研究agile methods的例外處理… 就是說,在軟體開發流程裡面,什麼時間點要做什麼事(隨便虎爛一下)」(友藏內心獨白:P小姐以前是審過期刊論文嗎,還是研討會的主持人?)

P小姐:「你去美國要受什麼訓練」
Teddy:「也沒有要受什麼特別的訓練,我們公司是在做主機板的,我在公司開發server management software,公司要求不時都要有人到美國去交流一下」

P小姐:「主機板怎麼拼」
Teddy:「motherboard」

P小姐:「喔,就這樣喔。」

之後P小姐消失約20秒,跟另外一個人討論了一下,回來之後就把快遞回條交給Teddy。(Teddy後面兩個人用羨慕的眼光看著Teddy,這情景就好像金馬獎頒獎典禮中,三個入圍者排排坐,最後宣佈得獎的是…Teddy…)在Teddy前面好像有四個人都被要求要填寫黃色單子,至於Teddy後面還有兩、三個人的遭遇就不得而知了。

此行心得:

(1) 快速簽證猶如馬總統的long stay(攏似假)。
(2) 如果你是博士,又要辦美簽,去美國的目的最好說是「購物」、「要去迪斯奈樂園玩」、或是「祭拜Michael Jackson」也行,就是不要去參與學術活動。
(3) 對付學術面談最好的方法就是不學無術。古人云:「柔弱生之徒,老氏誡剛強」,這話說的一點都沒錯。各位教授、博士們如果研究作的太好,又想跑去老美家裡耀武揚威,老美就算在審論文這一關沒把咱們幹掉,也非得在美簽這一關挖個洞。像Teddy這種無三小路用的博速,既不會危害美國國土安全,也不會像紅火蟻一樣到了美國之後就賴著不走,所以耍個2.5小時也就夠了。
(4) 馬總統,就算你爭取不到訪美免美簽,至少也爭取一下免學術面談吧。

後來回公司之後,在網路上看到一則真人真事。

面試官:「你為什麼要去美國」
面試者:(用台灣國語回答)「因為美國 is very good!」

2009年7月2日 星期四

在不同的Quartz Jobs之中共享資料

Quartz 是一個開放原始碼的排程(scheduling)軟體。要讓Quartz在我們設定好的時間執行特定的工作,首先實作Job 這個介面(interface)。Job介面只有一個方法:

void execute(JobExecutionContext context)

把要作的事情寫在 execute 裡面便可,當設定的時間一到Quartz自然會呼叫你的程式。Quartz的Job是沒有狀態的(stateless),如果你設定你的工作每一分鐘要被執行一次,那麼Quartz每次都會為你的工作產生一份新的instance,執行完畢之後就砍掉。如果希望這個工作每次執行能夠記住上次的狀態,便要實作StatefulJob介面。StatefulJob和Job內容完全相同,都只有一個void execute(JobExecutionContext context) 方法,差別在於Quartz會記住StatefulJob的狀態,也就是說Quartz只會幫實作StatefulJob的物件產生一份instance。例如,你有一個每一分鐘要被執行一次的StatefulJob,Quartz只有在第一次執行這個工作的時候會幫它產生一份instance,執行完畢之後會把該instance留下來等著下次繼續用。

關於stateless與stateful 的優缺點比較到處都有,大家孤狗一下便可。Teddy要說的是,如果兩個不同的Job要互相分享資料,要怎麼辦?看了一下Quartz Job Scheduling Framework: Building Open Source Enterprise Applications這本書,作者很好心的把這個問題留給我們自己思考。經過一翻有計畫的亂試之後,答案著實也很簡單:Quartz 的Scheduler介面,有一個getContext方法,會傳回一個SchedulerContext物件(類似Java的Map),把東西往裡面塞就可以了,所有屬於同一個Scheduler的工作可以看到SchedulerContext裡面的資料。

scheduler. getContext().put(“key”, “value”)

2009年7月1日 星期三

Architect-Builder

七、八年前當 Teddy 還在念碩士班的時候,在一次專題演講的課程中系上邀請了國內某著名的物件導向大師前來開演,在此稱為 K大師。事隔多年演講的細節早已遺忘,難忘的是,Teddy 從此不需再費心閱讀K大師所出版的雜誌,因為 Teddy 無法認同 K大師的想法。

在演講中,K大師一再強調軟體開發要學習建築業,如此方可做大。在建築業中,大致可分為兩種人,一種是建築師(architect),另一種是承包商(contractor,也可以直接叫做工人)。建築師只負責規劃,不管施工的細節。如此,建築師在畫完設計圖之後就沒他的事了,可以閃人繼續接下一個案子;至於如何將藍圖變成實際的建築物,是所謂的「施工細節」,可以找一堆廉價的工人來施工即可(到哪裡找?中國大陸是當時很熱門的地點)。如果房子蓋不好是工人的問題,絕對不是建築師的問題,而高高在上的建築師也不應該插手這種屬於黑手工作的施工細節,否則將陷於施工細節而無法脫身接其他案子。

這種「按圖施工,保證成功」的想法與做法,還真的有一堆人相信(甚至到現在都還是主流想法)。Teddy 則是奉行敏捷方法(agile methods),多年之後,敏捷方法在 Teddy 心目中已成為一種信仰。不談理論,舉幾個情境說明為何「按圖施工,保證成功」在大多數的情況是行不通的。

(1) 身為一個程式設計師,曾經依據 architect 交給你的設計文件(use cases 或其他輔助的 UML diagrams)不加修改就可以直接做出系統的請舉手?
(2) 身為一個 architect,有能力寫出不需修改便可直接做出系統的設計文件(use cases或其他輔助的 UML diagrams)的請舉手?

Christopher Alexander 認為,要建造一個美麗、有生氣的建築,必須要揚棄傳統的建築流程。Alexander 建議 architects 與 contractors 應該要「金剛合體」,成為一種新的角色稱之為 architect-builder(註一)。這種精神,嗯…看過「全能住宅王」這個日本節目嗎?很像節目中 architects 扮演的角色。在「全能住宅王」中,建築師會事先到委託人的家裡去了解他們的生活背景以及對於住宅的需求,量身打造屬於這個家庭專屬的住宅。在這個過程中,建築師不是畫完設計圖就閃人,而是不時到工地視察,並且經常需要依據現場狀況動態的修改或增加設計。此外,幾乎所有「全能住宅王」的建築師都會自己下海動手設計一、兩件作品,而委託人也會因為建築師貼心的專屬設計而滿懷感謝之意。

Teddy常常聽到有人說 architects 不需要寫程式,甚至有的公司怕 architects 把手弄髒了,還貼心的明文禁止 architects 寫程式。看看 Kent Beck 怎麼說:「If you stop coding, you stop learning. 」

註一:The Production of Houses, chapter 1.