找出一千個錯誤

「…軟體作者僅能使用閒暇時間撰寫, 所以不能提供完整支援, 也不保證一定沒有Bug, 如因使用或不能使用本軟體所發生之其他損害，包括營業利益之損失或是造成你上廁所時跌進馬桶等意外，必須由使用者自行負責所有後果…」。

看看這個免責宣告是不是很眼熟，你幾乎可以在所有軟體的說明中找到類似字句，很顯然的軟體設計師似乎都不敢保証自己寫出來的程式是完全沒有錯誤的，零Bug的程式是所有軟體開發人員所追求的不可能達成的目標，這聽起來實在不妙但現實如此，千慮一失的情況總是在你我左右，為什麼會這樣呢？




傑森最近開始學 C# 程式設計，他寫了一隻用來計算除法的程式，這東西真是非常酷，只要在方格填上數字再按個按鈕就可以算出數字相除的結果，傑森對他的成品感到很滿意，這可是他絞盡腦汁通宵達旦的曠世鉅作，他的程式碼像是這樣。
private void button1_Click(object sender, EventArgs e) { int a = int.Parse(this.textBox1.Text); int b = int.Parse(this.textBox2.Text); this.result.Text = (a / b).ToString(); }

這麼簡單的程式應該不會有Bug在裏面了吧，真的嗎？就我所知這個除法計算機至少有兩個顯而易見的錯誤，首先，如果沒有在方格裏填上任何東西或是填入的不是正常的數字就會出現「輸入字串格式不正確」的錯誤，第二如果在分母的地方輸入 0 就會產生除以 0 的錯誤，傑森不死心又再度修改他的程式，這次他會在做除法計算前小心的檢查文字方塊是否有正確的填上數字，並且分母不能為 0 ，修改後的程式變成這樣。

private void button1_Click(object sender, EventArgs e) { if ((this.textBox1.Text.Length == 0) || (this.textBox2.Text.Length == 0)) { MessageBox.Show("數字不能為空白", "錯誤"); } else if (int.Parse(this.textBox2.Text) == 0) { MessageBox.Show("分母不能為 0", "錯誤"); } else { int a = int.Parse(this.textBox1.Text); int b = int.Parse(this.textBox2.Text); this.result.Text = (a / b).ToString(); } } private void textBox_KeyPress(object sender, KeyPressEventArgs e) { e.Handled = !char.IsNumber(e.KeyChar); }

「程式碼看起來比原來的複雜得多，不過所有的錯誤都解決了。」傑森嘴裏唸著。
但是他還沒發現其實如果輸入的數子大過 2,147,483,647  就會出現 OverflowException 的錯誤。

就是這樣，總是會有你想不到的臭蟲藏在程式碼的深處，你永遠也別想寫出一個完美的程式，當完成一個系統時你總是會很心虛的跟你的老闆說「嗯，應該是完成了」，但是對程式的品質可沒有多大的信心，面對這種情況我倒是有一個小技巧可以改善，方法很簡單，那就是盡可能的去發現所有錯誤，你可以請一個測試人員專門做這種找碴的事，也可以在系統當掉之前記錄一筆 LOG，一般而言如果是兩、三個月內完成的小案子至少要找出一千個錯誤，因為能找到的錯誤越多代表還存在的錯誤越少，如果你能修正這一千個錯誤那麼剩下的也應該會是非常難發生的錯誤，我當然不是說所有剛寫出來的程式就一定會有一千個錯誤，但是如果能在初期發現的錯誤越多將來程式的品質越經得起考驗，所以如果一開始你的測試人員回報給你超大量的錯誤清單，你應該要感到高興才對，相反的如果測試人員跟你說他發現有二十個錯誤需要修改，那麼你最好請他再從頭徹底的測試一遍，要找出淺藏的錯誤當然有技巧，只要是數值你就要去測試極大值跟極小值會不會有問題，如果是有小數點的數值你就要注意各種情況下的進位，字串就要小心處理編碼跟字串長度及空字串，然後最好要求測試人員用各種不可思議的方式去操作程式。

原則就是發現的錯試越多你的程式碼將會更穩固，不過我想先提醒你並不是所有的問題都值得花時間去修正，那又是另一個故事了，也許我會在下一次跟你聊聊這方面主題。

不要做徒勞無功的事

總是會有一些遺憾的事，公司接手一個大案子，把工作分配給你及你的夥伴們，但是很不順利的時程一延再延， Bug 多到數也數不清，所有的人每天加班到十點半，最後客戶氣的跳腳不想付錢，有人受不了跳槽去了留下一堆爛攤子，面對灰暗的辦公室你不知道這些年到底幹了些什麼好事，每天忙碌最後卻什麼也沒有得到。

先不要太擔心，你只是遇到了大部份人都會遇到的問題而已，面對工作我有一些建議你不妨看看，確實遵循以下幾個要點決對可以讓你過的快樂一點。

搞清楚你是為了什麼工作
不要太妄想年輕時的美夢，什麼成為最偉大的計設師之類的，或是經手的專案一定負責到底甚至已經沒有人在乎能不完成，請把這些想法丟棄吧，工作就真的只是一份工作，是為了要賺大錢，不能賺錢的事就不要做，當你的經理要求你加班，你可以好好評估值不值得，是否有加班費及是否加班就真的可以解決問題，如果加班後接下來還是繼續加班，我勸你把時間留著顧好生活跟家庭，再次提醒你，不要因為工作耗掉你大量的私人時間，你僅僅只需要踏實的學習工作所該具備的技能，做好份內的事然後回家去。

隨時準備好你的履歷表
工作既然是為了賺錢，只要有機會可以賺更多錢或讓自己更愉快，那就換吧。而且依這樣的原則換工作收入越換越多將會是很正常的事。請隨時準備好你的履歷表並且適當的更新你最新的經歷，有好的機會就向對方推薦自己，只要確保能有稱職的表現那又有何不可，我第一個比較正式的工作是可憐又喪志的 MIS，每天盡是在Windows update網頁上按來按去，整整做了四年薪水半毛都沒漲，最後我認真的填寫履歷尋找新的出路，接下來的一年內我連換三個工作，現在則成為一個軟體工程師薪水是當初的兩倍多。

遠離辦公室政治
你可以在辦公室裏交朋友但是千萬不要花心思在辦公室政治上，我前面有提到工作的目的是賺錢，而不是追求虛名與權位，當你的經理邀你過年去他家打麻將或是下班上酒店時請委婉的拒絕吧，交幾個知心的工作夥伴會比明爭暗鬥搶先坐上管理階層還要有趣得多，直到你已經為新職位做好準備了，再去自我推薦，免得到時只會輪為不稱職的鳥龍領導人。

看完以上的建議你可能會覺得沒道理，只為錢而工作應該會很痛苦而且想法似乎太自私了一點。錯了，比起來沒有意義的忙碌才是真正痛苦的地獄，尤其是當你做到暴肝，卻聽到有人說「因為東西還沒做完所以客戶不付錢，今年也不會有年終」。是的，你只是單純的很辛苦但是什麼都沒有，所以我拒絕去做沒有用的虛工。

我就真的參與過這麼一個案子，起初估計的開發時程需要九個月，但是客戶一直不斷修改需求，最後剩下 27 天讓我們寫程式，專案經理企圖說服我們利用這 27 天不眠不休能做多少算多少，他會拿最後的成果去再去跟客戶談是否要把剩下來不及做的部份做完。我當然就只好請專案經理先去跟客戶重談新的時程表，等談定了合理的時程再說，然後我就利用這 27 天的空擋放年假去了。

另一個例子是最近的事，這個案子已經接近尾聲，但是還是有些麻煩事沒解決，於是我包含六、日連續加班兩週，好家在最後順利完成結案。

所以了，有意義的辛苦忙碌可以接受但千萬別去做徒勞無功的事，當然如果你有意虐待自已的話我也管不著。

愚蠢的績效考核

起先在這個世界剛剛開始運轉的時後，一切都是那麼單純，人們只需要躲在家裏睡懶覺偶爾出來曬曬太陽就可以過完一生，真是美好啊。但是總是會有些邪惡的傢伙會組織另外一些同樣邪惡的傢伙佔領土地組成國家，從此每個人就必需工作然後繳稅 (該死!這就是我現在這麼忙的真正原因)，最後其中有人變成大律師，有人卻是整天開著漆成黃色的車子在路上猛按喇叭，無論如何每個人都會在互相爭下產生不同的價值然後被分配在不同的位置上。如果你夠注意的話應該會發現無論是在多幽暗的角落都會有評鑑每個人價值的古怪方法，這真的是無所不在，來聽聽一個真實的案例。

在我所待的公司裏有一個令人討厭的績效考核制度，目地就是要找出整天在公司只是上上網收收信並且當有人跟經理對嗆時大開賭盤的人，然後把這些人的年終獎金一部分沒收，好用來打平當年的營運虧損。

每到年末我的經理就會一個個找我們評定績效，他會先跟我解釋公司的績效考核制度好讓我認同這決對是非常公正的，他把所有的員工用常態分布的方式分成三類。

1. 好員工 - 程式寫超快，隨便弄弄就讓公司的產品大賣。
2. 普通員工 - 程式寫的普通爛不過至少可以讓客戶的印像不會太糟。
3. 爛員工 - 常常睡到中午才想到今天要上班而且整天無所事事。

用圖表看起來就像這樣…

嗯，好員工不多爛員工也很少，大家都是普通爛的員工，看起來還不錯，必竟第一名只會有一個。



如果公司賺大錢的話就會變成這樣…

好像也對，好員工變多了所以公司賺錢。



如果公司不賺錢就會變這樣…

噢! 大家都在混所以不賺錢，慘啊。



解釋完了績效制度的規則後經理就會宣佈你是屬於三種員工的哪一種，通常你會得到這種答案。

「嗯，雖然你不是最好的，但也不算太差，所以你是普通爛的員工。」

嗯，謝了，其實我很懷疑跟本不會有人會被分類到爛員工那一類，因為負面評價對士氣傷害很大，一般人只要知道自己被歸類為爛員工後要做的第一件事就是打開瀏覽器上104填履歷，另外會被歸類到好員工的人也不會太多，因為那代表公司將要付出巨額的獎金，最後這種績效考核制度只是讓幾乎全部的人都成為普通爛的員工，意思也就是說績效考核制度只不過是讓大家白忙了一場然後什麼做用也沒有。所以不用再唬我了，我不會上當的，哈哈！

如果你正巧是發明這種考核制度的管理階層可要小心了，長期在這種績效考核下薰陶的公司文化會漸漸走像不好的極端，你的客服部門可能會有意無意的掛掉客戶的來電，這樣他才有辦法一天接300通電話，不然你以為那些所謂的客服專線為啥總是接通後就莫名奇妙的斷線了，而且等早上掛完300通電話後下午就可以悠哉的泡咖啡去了，所以到了下午就沒有人會去接電話，努力工作的人因為處理客戶問題花太多時間結果變成爛員工，然後很不爽的跳槽了，最後留下來的只剩一堆偷雞摸狗的傢伙，從此以後沒有人會去在意他該做的工作只在意他的績效獎金，這裏當然是假設客服部門是以處理客戶電話的多寡來評定績效，但是套用在其它方面也是差不多意思。

最慘的是大多數人都會對評估結果感到失望，不論你的評估是如何的公正都一樣，下次有機會你可以注意看看，是否每次舉辦頒獎儀式後(我說的就是那種幾個人上台領壓克力獎牌並且跟總經理親親抱抱的遊戲)，大約會有一個星期左右大家都很消沉，只因其他領不到壓克力的人正在不爽。

所以結論就是愚蠢的績效考核可以讓五個人高興一下，同時讓一百個人不太高興好一陣子，最後這種遊戲只會是扼殺整體士氣的最佳手段。(尤其是發現自已剛好就是那一百個人之一的時後…)

簡單有效就是最好的辦法

在我參與的專案裏全都是跟著堅強高竿的組員合作，幾乎全公司裏的菁英都集中在我們這個團隊中，尤其是我們帶頭的 leader 維克大隊長更是經驗豐富的老手，不論是多緊迫的時程或是巨大的困難，他總是會指引我們做出正確的決定然後一路過關斬將完成一個又一個任務。

維克大隊長酷愛研究各種 Design pattern 的設計模式，「所有最複雜的東西應該要一開始就想清楚」他總是這麼說的。

然後他會花上三個星期埋頭鑽研那些我可能一輩子也不會了解的艱深理論，最後決定出一個巨大無比的架構來實現我們的系統，而這種創新的架構只是為了能讓系統添加了使用者完全無法查覺到的新功能 - 資料安全加密的處理模式。

哦~ 我的天!!
今天是美麗的週未，我還想能早點下班回去跟小狗狗玩呢。

我們的系統還不需要用來對抗詹姆士龐德或是湯姆克魯斯，對於資料加密直接使用 MD5 或是 SHA 就很夠了，有時後那些手段高明的人總是會有個壞毛病就是喜歡把事情搞大，即便是一個小小的功能也 非要弄得整班人馬雞飛狗跳，團隊的資源就這樣被這個巨大的小功能消耗殆盡。

這讓我想起了大學時代的一段遭遇，學校的教授要我們利用大學最後一年的時間分組製作一個專題研究，那確實是我大學四年裏最困難的作業之一，當時科系裏的萬年第一名同學倒是興致勃勃招集了各方高手打算搞個驚天地泣鬼神的專題來考驗自已的能耐，很幸運的我獲得邀請加入他們接著就開始了一連串的惡夢....。一開始我們連題目都沒辦法決定，因為萬年第一名同學總是覺得必需要是一個完全創新的新玩意才值得他花時間在上面，而且所使用的技術門檻一定要夠高才能顯示出身為專業技術科系學生身份地位，結果就這樣花啦啦六個月過去了我們什麼也沒做，這其間當然有弄出一堆奇特想法下的系統原型，但是全都被萬年第一名同學退件，他認為這些都太小兒科了沒搞頭，最後在時間壓力下他終於免強同意做一個類似GPRS行動定位系統的東西(當時行動通訊才剛開始流行)，然後我們就做啊做的又過三個月發現我們真的做不出衛星訊號接收器。
整個過程像一齣鬧劇，真不愧是集結全科系最厲害的高手的作品，那麼問題到底出在哪裏呢?

當你對一個領域的知識到達一個程度後總會想要做出一個最偉大的作品，但是別忘了，能真正實現它並實際運用才是目的，我們應該去思考的是如何用簡單有效的方法做出來而不是用最艱難最令人乍舌的方法做出來， 這個故事告訴我們只要盡可能的把事情變的更困難，複雜到沒有別的人可以搞得懂，你也可以成為大人物。( 哈 )

那... 後來呢? 我們就大吵了一架然後再分成三個小組各自做自己的小玩意去了。