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

2010年9月24日 星期五

出差照片 (2):蠟像館

Sept. 23 23:36~ Sept. 24 00:16

接續昨天沒貼完的照片(上載圖片有點慢)。

去參觀中國戲院旁邊的蠟像館,一進門就是 歐買尬 歐巴馬總統在白宮前歡迎您。



蠟像館中的人物實在太多了,在裡面待了快 2.5 小時,以下隨便挑幾張鄉民們任意瞧一下。

有總統,當然也要有州長。



追殺比爾 蓋茲 (想必是常常看到藍底白字的畫面... XD)。


金痞子凱瑞先生


企業號前後任艦長(怎麼沒有航海家號的 seven of nine?)


人生就像一盒巧克力之阿甘等公車


亂世佳人男主角



亂世佳人女主角


常常傻傻講錯話的大鼻子成龍



最後以鋼鐵人結尾 (這不是蠟像啊!)

***

友藏內心獨白:沒想到在蠟像館拍照能有這麼好玩。


2010年9月23日 星期四

出差照片 (1)

Sept. 22 23:31~ Sept. 23 00:11

今天中秋節,貼幾張 Teddy 出差時所拍攝,覺的有趣的照片。

Teddy 出差的最後一個禮拜剛好遇到美國勞動節,包含六日一有三天連假,Teddy 和幾位美國同事到 LA 玩了一趟。下面這張照片是在某地下停車場所拍攝,注意每個停車位上方都有一個小燈,綠燈表示車位是空的,紅燈表示車位有人使用。這樣在找停車位的時候,遠遠就可以看到哪裡有車位,還滿方便的說。



Apple 專賣店所展示的超大 iPad,橫的擺都可以當作電視機使用了。



在飯店不小心轉到海綿寶寶的節目,這一集 Teddy 在台灣已經看過了。



飯店房間有一台有趣的泡咖啡機器,之前沒見過長這樣子的。


這是咖啡粉,有不同『口味』。什麼,你問 Teddy 泡出來的咖啡好不好喝... 這... 因為不是免費的,所以 Teddy 無福享用。



這是『星光 大道 人行道』



好長的車子,上面還有辣妹(這不是電視影集才有的畫面嗎,居然活生生出現在 Teddy眼前)。



路邊有超人和蝙蝠俠跟遊客拍照賺小費。



夜深了,明天還要上班,先這樣。

友藏內心獨白:親愛的鄰居,怎麼還在烤肉?

2010年9月22日 星期三

需求分析書中最重要的資訊是什麼?

Sept. 21 23:04~ Sept. 22 00:14

Teddy 這次到美國出差,利用 Amazon 在美國國內買書不用運費的優惠,一不小心買了 10 本書(標準的貪小便宜心態),等要回台灣打包行李時才發現,這還真有點快放不下(要不是幫剛做完月子沒多久的同事帶了六個奶瓶回來,可能會買更多書... XD)。不過這不是重點,今天的主題是 Teddy 要介紹一本此行出差所買的書:Bridging the Communication Cap: Specification by example and agile acceptance testing

當初會買這本書是因為被書名副標題『Specification by example and agile acceptance testing』所吸引。記得當年 Teddy 還在念博速班的時候,看過 Phillip G. Armour 所寫的一篇 paper,叫做 The Case for a New Business Model: Is software a product or a medium?, Communications of the ACM, pp. 19-22, August. 2000。這篇  paper 提到有五種儲存知識的媒介:

  • DNA
  • Brains
  • Hardware
  • Books
  • Software
Paper 細節就容 Teddy 偷個懶,請鄉民們自行發掘。當年 Teddy 看完的感想是,一般的軟體需求都是以『文件』形式存在,屬於上述第四種知識儲存媒介(book)。但是軟體開發的最終產品卻是以第五種知識儲存媒介(software)存在(這算是所謂的『阻抗不匹配嗎?』)。所以,問題來了,軟體開發人員就需要確保這兩種不同的知識儲存媒介(想表達相同的事情---軟體功能或需求)是否同步(軟體工程裡面所謂的  traceability)。相信大家都知道軟體開發人員都很忙,沒有那個美國時間去更新需求文件,因此需求文件所記載的內容與程式碼實際完成的功能經常有所出入也是很『正常』的現象。所以,到底要相信文件還是要相信程式碼,便成為許多軟體開發人員心中的痛(鄉民甲:其實... 兩者都不可信...XD)。

所以,Teddy 當時就在想,如果能夠將軟體需以 software 的形式表達,那麼需求與產品都是以第五種知識儲存媒介(software)來紀錄,是不是就可以減少『阻抗不匹配』的問題?此外,由於軟體具有『可執行』的這個特性,因此就有可能自動驗證『需求』與『軟體系統』是否『同步』。

講了這麼多,還沒轉台的鄉民們,再看一次這本書的副標題:『Specification by example and agile acceptance testing』,其實是有類似的味道。許多做 agile testing 的人都知道所謂的 agile acceptance testing,在開發一個 story 的時候,先幫這個 story 寫一個 acceptance test case (當然此時這個 test case 一定會失敗,因為程式碼都還沒出生啊),中間經過一連串開發過程(細節跳過),最後如果這個 acceptance test case 通過,就代表這個 story 完成。從另一個角度來看,我們可以說這個 acceptance test case 紀錄著它所代表(測試)的那個story 的知識。

***

講了這麼多,其實這全部都不是重點,回到本篇的重點:『需求分析書中最重要的資訊是什麼?

答案:寫這本需求分析書的那個人的電話號碼

來源請參考本書第 25 頁:

Ron Jeffries said, during his session on the natural laws of software development at Agile 2008, that the most important information in a requirements document are not the requirements, but the phone number of the person who wrote it.

這本書目前只看了 20% 左右,有機會看完的話再跟鄉民們報告。

*** 

友藏內心獨白:親愛的鄰居們,夜深了,烤肉用具可以收起來了。搞得空氣中都是烤肉味道,怎麼睡覺啊。

2010年9月21日 星期二

開工了

Sept. 20 22:44~ Sept. 21 00:06

快一個月沒寫部落格了,不認識 Teddy 的人可能以為 Teddy 失了蹤。話說之前到美國加州出差三個禮拜,不知怎麼的寫部落格的靈感完全消失。可能是年紀大了,剛到美國的第一個禮拜都在調時差,回台灣之後的第一個禮拜也是渾渾噩噩的,真是佩服那些全球到處跑的空中飛人。

關於『時差』這件事情,不是只有『睡覺』需要調整而已,廣義來講整個人的生活作息都需要調整。例如,加州早上9點要吃早餐的時候,正好是台北深夜12點,肚子不太餓還是要把公司發的麵包啃下去。這個還算好,如果平常早上有『大便』習慣的人,連上廁所的『時差』也需要調整,這就有點辛苦了...

***

除了出差這件事讓 Teddy 作息大亂以外,還有最近不知道走了什麼狗屎運,家中電氣用品接連壞掉。在出差之前,Teddy 的 Kyocera FS-1030D 就壞了,準備送修。靠北..方前進,維修中心居然只有週一到週五有營業。好吧,好不容易找機會送修,等了一個禮拜,拿回家之後印不到三張,又卡紙。哇哩勒,真的很想問候維修人員的家長,這麼重的印表機,又只能在非假日維修,花了 800 塊左右(詳細數字忘了)結果還是沒修好 (還沒包含來回的計程車費 320 塊)。雖然學弟好心的要 Teddy 把印表機拿到學校再幫忙送修,不過 Teddy 已經沒力了。此時很想像漫畫中,憑空拿出一把『大鐵鎚』,把這台不斷卡紙的 Kyocera FS-1030D 給砸爛,然後才有藉口再買一台新的。

印表機壞了已經夠煩人了,在出差前幾天,一台沒買多久的 WD 1.5 TB 的硬碟出了問題,至於是什麼問題,也沒時間管了,等出差回來再說吧。結果出差回來當天打開電腦螢幕,一片『雪花』。難道是螢幕壞了?錯。還是眼鏡沒擦乾淨?錯。經過一番折騰,居然是『顯示卡壞了』。這塊 Asus EN7300GT PCI-E 8X  顯示卡,到底買了幾年 Teddy 也忘了。網路上找了一下,哇..靠...近一點,怎麼 PCI-E 8X  顯示卡已經都停產了,難道要為了沒有顯示卡而去買一台新的電腦嗎?這個藉口也太牽強了一點。

經過 Teddy 研究的結果,PCI-E 16X 顯示卡『外表』看起來跟 PCI-E 8X 顯示卡幾乎一樣啊,好吧,鼓起勇氣在  PxHome 上面挑一張最便宜的微星 R4350-MD512H (1335 NTD)卡來試看看,如果不行就算了。耶,沒想到插上去居然可以用,哇出運啦。

事情絕對不是笨蛋想像的那麼簡單,就在 Teddy 忙著處理顯示卡的同時,某一天早上上班之前,Kay 正在看電視,突然.... 電視畫面不見,電源開關不亮,從此無法開機。

Teddy 的電視買了兩年左右,是奇美的 42吋 TL-42W6000D。好吧,打電話去奇美維修中心,約了好幾次,維修師父都說晚上不行(網站上明明寫 周一~ 周六 08:30~22:00),只好約禮拜六下午兩點(電視是禮拜一早上壞掉的)。上禮拜六維修師父快三點才到,結果兩手空空,什麼東西都沒帶,問了 Teddy 一下電視狀況,隨便看一下電視,再看一看保固書,然後維修師父對 Teddy 說:『我們維修是要收費的,這個電視還在三年的保固期限,要找原廠,我們不能修』。

越聽 Teddy 火氣越大,早在電話中就跟對方講電視型號還有購買時間,等了一個禮拜才告訴我要找原廠(再度拿出心中的大鐵鎚)。今天禮拜一打電話去奇美『原廠』維修中心,電話那頭傳來:『現在是非上班時間....』。哇哩勒,真是太 lucky 了,難道奇美『原廠』維修中心是在南部,所以今天剛好停班停課,只好明天再打電話了。

 ***

如果倒楣的事就只有這樣,那就遜掉了,話說去年 Teddy 因為脖子痛到住家附近的小醫院復建(請參考 這篇),『暫時康復』至今已有將近 9 個月的時間,這次到美國出差 Teddy 怕脖子又不舒服還特地帶了平常睡覺的枕頭出國,可是到了第三個禮拜脖子又開始痛了。可能是因為公司宿舍的床墊太爛(總不能要 Teddy 從台灣搬一張床墊出國吧?還是要在宿舍附近的 Costco 買一張床墊,然後回台灣之前再拿去退?有必要玩這麼大嗎...);也有可能是 Teddy 低頭看書看的太久。總之就是不明原因,結果 Teddy 又繼續到醫院復健科報到了。一週復健六天,每天活生生的就少了一個小時。

雖然出差賺了一點點出差費,不過跟每天復健比起來還是太不划算了。希望這個禮拜能把電視修好(至少要跟『原廠』聯絡到吧,不要告訴我『原廠被水扁了...』),然後找到合適的印表機... 雖然 Kay 不讓我買新的印表機... 嘿嘿嘿,先斬後奏。

對了,唯一值得高興的一件事,就是 Teddy 在美國的時候,Kay 預約了一隻台灣大哥大的 iPhone 4 16G ,上禮拜五晚上 Kay 居然糊里糊塗的就拿到了 iPhone 4 16G (原本想換  32G,不過還要排隊,所以就作罷)。Teddy 跟 Kay 借用了一下,真是太棒了,光是看到畫面的細膩程度,就好想也買一隻。

結論:此時的 Teddy,只有花錢才能得到快樂... XD。



 ***

友藏內心獨白:這麼倒楣是否和沒有去安太歲有關係呢?還是 Teddy 天生帶賽...