這幾天有一則新聞，某 29 歲任職於『南邊來了個
這種說法是不是說：
- 『公司對較有能力工程師及主管採責任制』，這麼說起來責任制是一種光榮耶。不用懷疑，當年日本『神風特攻隊』一定也是採取『責任制』。
- 不屬於責任制的員工們，立正站好，好好反省一下，這表示你們『比較沒有能力』。不過別難過，老子云：柔弱生之徒。恭禧各位沒能力的非責任制員工得以僥倖存活下來（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。
- Precondition：想要執行這個 method，那麼這個 method 的 precondition 必須要成立才可以。 這就好比日劇『大和拜金女』裡面松島菜菜子對於擇偶條件一定要是『好野人』一樣，這就是『要跟大和拜金女交往的 precondition』。
- Postcondition：執行這個 method 之後，該 method 保證一定會成立的條件。例如『大和拜金女』為了吸引『好野人』跟她交往，可能訂出『聯誼一次可獲得香吻一枚』這種 postcondition。
問的好，今天先談一下 precondition 的好處。 在開發軟體的時候，其實 programmers 經常做了很多『大膽的假設』與『小心的檢查』：
- 這個傳進來的參數會不會是 null 呢...ㄟ，不知道，那就 if (str != null) {do something}。
- 讀取一個由其他程式所產生的檔案，萬一檔案格式不對怎麼辦？
- 必須是（新台幣）現金（其他貨幣或是有價物品一概不收）
- 必須是真鈔（否則報警）
- 必須是現行流通的版本（拿舊版的新台幣就可以不用處理）
- 貨幣本身必須完整可辨識（被火燒過或是被蟲蛀的紙鈔請先找調查局鑑定）
***
扯了這麼一大段，回到主題。記得 Teddy 曾經看過某本書，書中提到有效率跟沒效率的 programmers 其生產力好壞可以差到 10 倍。如果企業文化就是『開發軟體沒什麼學問』，『軟工無用』，『加班萬歲』，在這種環境的 programmers 那可能去管什麼『DBC，Exception Handling，Refactoring，Agile，SCRUM，Design Pattern，Unit Testing...』(就算 Teddy 雞婆想要去教免錢可能還被對方嫌沒空)。反正，這一堆『沒什麼學問的東西』老闆，主管也不懂啊，只有『程式能動才是王道』，其他的任何事都不要來煩我，因為我是『較有能力』的工程師，我只需要『上班時間自己判定』這個萬能的武器就夠了。
感覺好像現代版的『神風特攻隊』。
***
友藏內心獨白：DBC 之前不是已經介紹過了嗎？！
