輕鬆談軟工

往花蓮的自強號上，旁邊坐著一位五十幾歲的長者，一直反覆的看著一本旅遊書籍，看起來是歐洲旅遊的書。我好奇便問他：『剛從歐洲旅遊回來嗎？』，他嚇了一跳，我連忙向他道歉，他親切說；『沒關係』，接著很興奮的告訴我他的攝影心得，就這麼聊了起來。 他一邊翻閱書上的照片，許多的地方他都去過，他說他喜歡研究別人取景的角度為何和他不同，借此學習更好的攝影技巧。看得出他對生命充滿熱情，喜歡思考、創作與分享。聊著聊著才知道他原來是台中知名建商的董事長。 除了生活上的樂趣外，他也跟我分享他的經營理念。他對員工的要求是 『不能凡事都照著規格書、設計圖走，那是官僚』 。為什麼？他們的員工每天都在接觸房子的買賣，久了就麻痺了，以為房子的買賣很輕鬆，但是對許多買房子的人可能是畢生的積蓄，一生可能只買一次房子。 他說他接觸過很多醫生、教授或高科技產業的客戶， 他們在自己的領域上十分的專業，"但對房子的事情真的就是不懂" ，所以不能拿規格書來壓他們，應該是要幫助他們。 姑且不論這位董事長是否真的做到這樣的原則（畢竟我跟他不熟），這些道理在軟體工程產業上也是相通的。寫軟體的如果在客戶搞不清楚規格的情況下一直以規格來壓客戶，那就是以專業的傲慢來欺騙客戶的無知。 當然，蓋房子跟寫軟體畢竟不同，各位覺的呢？

軟體系統常常背上許多莫需有罪名，有時候是需求的提供者沒把需求說清楚（或根本說了錯誤的需求），有時候是使用者不會用 （沒參與教育訓練或沒看說明書）造成操作不當。當後者的情況發生時，使用者通常會怪罪『介面設計不好』。 的確多數的軟體工程師對於介面的設計不重視也不在行，但有時候使用者也太無理取鬧，把所有的錯誤都賴在介面設計上。 張大叔最近開始使用線上照片沖洗的功能，但照片卻遲遲沒有寄到，他上網查了一下，發現住址寫錯了。他打電話到客服中心發飆。 『你們的系統有問題不穩定，把我家的地址記錯了。明明是100號，怎麼會記成200號？』 客服查了一下，回應說： 『張先生，有可能是您打錯了，系統記錄的的確是200號』 『怎麼可能？我打過無數次了，怎麼可能會把自己的住址打錯？』 客服有耐心的說： 『有可能1和2相鄰，您打的時候打太快了，所以不小心打錯了』 『那你們系統要做檢查嘛，哪有那們笨的系統？要做防呆嘛』 客服楞了一下，還好他邏輯還清楚： 『張先生，我們系統不知道你住100號，怎麼知道您打錯了？沒有辦法喔...』 這下換張大叔楞了一下，但他還是很生氣。 『這照片是我送給老婆的生日禮物，照片我選了好久，沒有按時寄過來這個禮物就沒有意義了』 ，頓了一下又說： 『你們要怎麼賠償我的損失？』 『先生，這是您打字錯誤所造成的，我們沒有辦法賠償。我們會通知郵局將包裹重寄，但您要再負擔一次運輸費用』 客服說。 張大叔一聽還要多負擔就生氣： 『都是你們系統的問題為什麼要我負擔？你們介面設計的太糟，介面要儘量防呆嘛... 比如說不要讓我們用打的，讓我們用選的...』 客服有點聽不下去了： 『先生，忠孝東路門排很多，我們不可能把所有門排都列出來讓你選』 『怎麼不可以，你可以每一個位數都用一個下拉式選單，三個位數只需要三個下拉式選單，你們設計要用點腦筋嘛』 ...

古時候，中國有一則寓言是說：有四個人走到一面高牆前面，高牆的通門用鐵鍊與鎖鎖住，其中三人試圖用盡各種方法要打開門鎖，用石頭打、火燒、以及用木棒挖鎖等方法，但最後仍然無功，這時候，忽然看到那第四人從森林走出，手握一把長竹竿，走到牆面前以撐竿跳的方式跳過那一面牆。 第四人並沒解決門鎖的問題，而是避開重新定義問題，創造新的而可解決的問題 ，因此基本上問題不在門鎖，而目的是人要到達牆的另一面。 這則故事顯示，"what"與"how"的問題，前面三個人只想『我如何打開那道門』(how)，至於另外一個人則避開那三個人的困境，只是想『我要做甚麼』(what)，答案是『我要過那面牆』，一旦他將問題放在"what"上面，他就可以設計如何執行而獲得成功，他解決問題不只是解決，而是問題要合理解決。 發展軟體就應如這則寓言中第四人的作法，要如何達到有許多方法，其中CRC cards (Class-Responsibility-Collaborator cards)技術，可能是最佳方法之一，但似乎未在國內引起廣泛注意，我們另文討論。

今天上課前突然想到一個故事，稍作改變後用來跟學生講解流程改善。 某公司聘用一個員工上種樹，他需要鋤頭挖洞，將樹植下，最後再用鏟子把地鏟平。以他的速度一天只能種十顆樹，比老闆預期的進度差太多，於是老闆又聘了兩個人來幫忙，速度提昇了兩倍。 [from work harder to work smarter] 但是這樣的速度還是不夠快，而成本又太高已經沒有經費在聘用員工，只好想辦法進行流程改善。他仔細觀察三個員工的工作方式，發現花在工具的抽換花了太多的時間。於是他重新更換了三個人的工作：A 只做挖洞的動作，B 隨後將樹植下, C 隨後在將地鏟平。這樣的工作模式可以省去更換工具的時間，更棒的是，每個人更能夠把自己的工作做的專精，效率又提高了兩成。 [但，小心成為官僚流程] 這樣的流程跑了很久，員工來來去去換了許多次，但都保持一定的高效率。一天，老闆去看工地，發現A 挖玩洞後，C 緊接著把洞補起來填平，老闆生氣的說：『你們在做什麼？B君呢？』 『喔，他今天請假了』A 說。 最後這個笑點看似誇張，但在企業流程卻常見。許多人習慣了只知道follow 流程去做，卻不之所以然，所以很容易鬧出笑話。另一方面企業也常常不重視流程的教育訓練，所以常常空有好流程卻無法發揮最大的效用。

Continuous Integration 在討論版本控管時，我們曾經提到WiMAX計畫使用一個輔助工具「 JCIS 」進行持續整合(Continuous Integration)的工作。那麼，為什麼要做持續整合呢？維基百科中對於 持續整合 的理論有些初步的介紹，包含下列十個重要的Practices： 維護一個程式庫(Maintain a code repository) 將建置自動化 (Automate the build) 使建置能進行自我測試(Make the build self-testing) 每人每天送交程式碼(Everyone commits every day) 每次送交都應該被建置(Every commit should be built) 維持快速的建置時間(Keep the build fast) 在實際運行的環境下進行測試(Test in a clone of the production environment) 簡化取得最新可交付版本的方法(Make it easy to get the latest deliverables) 每個人都能看到最新版建置的測試結果(Everyone can see the results of the latest build) 將佈署自動化 (Automate deployment) 上述許多Practices都要求自動化，自動化又可以分為半自動和全自動，以半自動為例，可能是有人每天固定手動執行make指令，將所有要建置的檔案編譯與連結，接著有人將結果複製到實際運行的環境，再下指令讓電腦執行所有的測試，這個過程雖然必須由人來操作，但只要下少許指令就可以完成了。那麼全自動呢？就是在專案開始的時候進行若干設定，之後由電腦自動處理一切編譯、連結、測試等工作，這就需要一套輔助工具了。 要確實完成這麼多的Practices，其實門檻是很高的。即使是在企業界，也難免會有不遵守遊戲規則的軟體工程師，更何況我們的開發主力是學校裡沒什麼專案成敗壓力的學生。舉例說，要做到「每人每天送交程式碼」幾乎是不可能的，基本上學生開發程式是有一天沒一天的，最多只能要求到「有修改就必須送交程式碼」。另外像是「每次送交都應該被建置」，在我們第一年的WiMAX計畫中可以說是完全失敗。在開發環境未能統一的