過勞死之軟工無用論

Sept. 28 22:20~ Sept. 29 00:08

這幾天有一則新聞，某 29 歲任職於『南邊來了個 亞 啞巴』之高科技公司員工『疑似』加班過度而過勞死，公司的反應卻是極力想撇清關係。據水果日報報導：『南邊來了個啞巴科技副總白培霖說，公司對較有能力工程師及主管採責任制，上班時間由員工自己判定，也積極宣導員工盡量休假、上下班時間正常。 』

這種說法是不是說：

• 『公司對較有能力工程師及主管採責任制』，這麼說起來責任制是一種光榮耶。不用懷疑，當年日本『神風特攻隊』一定也是採取『責任制』。
• 不屬於責任制的員工們，立正站好，好好反省一下，這表示你們『比較沒有能力』。不過別難過，老子云：柔弱生之徒。恭禧各位沒能力的非責任制員工得以僥倖存活下來（Teddy 內心獨白：學生算不算責任制？）。
• 『上班時間由員工自己判定』，這種說法好比說『釣魚台是日本 故有 固有領土』一樣唬爛。

Teddy 內心有種感覺，台灣公司老闆普遍存著『加班就是好員工，不加班就是 不孝 不認真』的心態。反正：『別人的孩子死不了』，離職再找人就好。反正老子有錢，叫你作你就做，做不完，反正『上班時間由員工自己判定』，你就好好地『自己判定』一下。

***

Teddy 從事軟體業（ㄟ... 在硬體公司寫程式算軟體業嗎？），常常聽到其他人說：『啊，軟體工程在業界行不通啦』，『兩天的訓練課程要一萬塊，這麼貴（Teddy 內心獨白：那請問多少錢您老大才覺的合理？）』。這種打從心底認為『開發軟體沒什麼學問』的心態，當然會做出『沒什麼學問的軟體』出來。偏偏這些老闆們又認為這些開發軟體的員工屬於『有能力工程師』（這不是自相矛盾嗎？沒學問的事情應該不需要有能力的人來處理吧。），反正只要員工們好好的『自己判定一下上班時間』，任何問題都可以搞定，Yes，you can。

軟體工程到底有沒有用，Teddy 舉的例子。軟體工程裡面有一種軟體設計的方法，稱作 Design By Contract （DBC），DBC 的原則十分簡單，但威力卻很強大。基本上寫程式就是『我 call 你的 code (API or method)，你  call 我的 code』。在這種 『彼此互相 call 來 call 去』，的互動當中，程式可以區分為兩種不同的角色：『caller』和『callee』。

• Caller：呼叫別人以獲得服務的人（有點繞口），在 DBC 中稱為 client。例如，我去銀行請行員幫我開戶，我就是 client。
• Callee ：被別人呼叫並提供服務的人，在 DBC 中稱為 supplier。例如，我去銀行請行員幫我開戶，行員就是 supplier。

有了這個觀念之後，接下來的規則就很簡單了。每個程式（姑且就先想成一個 method 好了）都應該有它自己的 precondition 與 postcondition。

• Precondition：想要執行這個 method，那麼這個 method 的 precondition 必須要成立才可以。 這就好比日劇『大和拜金女』裡面松島菜菜子對於擇偶條件一定要是『好野人』一樣，這就是『要跟大和拜金女交往的 precondition』。
• Postcondition：執行這個  method 之後，該 method 保證一定會成立的條件。例如『大和拜金女』為了吸引『好野人』跟她交往，可能訂出『聯誼一次可獲得香吻一枚』這種 postcondition。

鄉民甲：這和程式設計有何關係？

問的好，今天先談一下 precondition 的好處。 在開發軟體的時候，其實 programmers 經常做了很多『大膽的假設』與『小心的檢查』：

• 這個傳進來的參數會不會是 null 呢...ㄟ，不知道，那就 if (str != null) {do something}。
• 讀取一個由其他程式所產生的檔案，萬一檔案格式不對怎麼辦？

很多人直覺的反應就是『既然不知道別人傳進來的資料是否正確，那就自己再多檢查一遍啊，反正多檢查一次也不會怎樣』，這種作法就叫做『defensive programming』，看起來很不錯啊，但這卻很可能是一種造成加班的原因。為什麼？想像一下，如果你是銀行行員，有人拿『黃金』來『存錢』，你需要先幫顧客把黃金換算成現金，然後再把這些現金存到顧客的戶頭嗎？。大部分的銀行應該沒有提供這麼感恩的服務吧，所以，關於存款這個服務，應該會有類似的  preconditions：

• 必須是（新台幣）現金（其他貨幣或是有價物品一概不收）
• 必須是真鈔（否則報警）
• 必須是現行流通的版本（拿舊版的新台幣就可以不用處理）
• 貨幣本身必須完整可辨識（被火燒過或是被蟲蛀的紙鈔請先找調查局鑑定）

有了這些 preconditions 之後，這個 supplier 的實做 (行員的服務內容) 就變得很明確，講成白話文就是，如果需要寫一隻支援行員的程式，那麼這隻程式的『輸入』就很明確，也就不需在程式裡面做一些有的沒的檢查，需要寫的 code 自然也變少了 (大體上是這個味道，想了解細節還是要看一下 Object-Oriented Software Construction 這本書)。

***

扯了這麼一大段，回到主題。記得 Teddy 曾經看過某本書，書中提到有效率跟沒效率的 programmers 其生產力好壞可以差到 10 倍。如果企業文化就是『開發軟體沒什麼學問』，『軟工無用』，『加班萬歲』，在這種環境的 programmers 那可能去管什麼『DBC，Exception Handling，Refactoring，Agile，SCRUM，Design Pattern，Unit Testing...』(就算 Teddy 雞婆想要去教免錢可能還被對方嫌沒空)。反正，這一堆『沒什麼學問的東西』老闆，主管也不懂啊，只有『程式能動才是王道』，其他的任何事都不要來煩我，因為我是『較有能力』的工程師，我只需要『上班時間自己判定』這個萬能的武器就夠了。

感覺好像現代版的『神風特攻隊』。

***

友藏內心獨白：DBC 之前不是已經介紹過了嗎？！