l

2010年9月29日 星期三

過勞死之軟工無用論

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 之前不是已經介紹過了嗎?!

3 則留言:

  1. 問題是上班時間有沒有好好工作呢?

    回覆刪除
  2. 聽說一本Peopleware還不錯可以參考看看,in the zone(專注)是很難的,但是很容易打斷,比如說email、電話、同事、老闆、The Onion...又要再回去那個zone就很難了,不過VC(買單的老闆們)通常都覺得office是overkill,太貴了,這也是Teddy說的老闆認為開發軟體沒什麼學問的理由之一吧

    回覆刪除
  3. To 匿名:

    ㄟ,看不懂您的留言:『問題是上班時間有沒有好好工作呢?』...所以跳過...

    To Don:

    開發軟體沒什麼學問的想法是因為 Teddy 看了『創意海豚的部落格』的某篇文章裡面提到『寫程式有什麼學問,不過就是一堆 printf() 而已』。不過該篇文章好像被刪除了,無緣介紹給鄉民們拜讀。

    不過說真的,很多老闆的確都有『寫程式有什麼學問』這種看法,難怪做不出好軟體。

    回覆刪除