程式設計師不可不注意的五件事

程式設計師不可不注意的五件事

Mr. Monday寫了一篇你在大學裡應該學會的三件事，這篇以此類推，就叫做「程式設計師不可不注意的五件事」吧！這篇文章小小的匯集了Mr. Friday從大學以來參與程式設計開發的心得，雖然不敢說自己程式功力多麼高深，不過拋磚引玉，希望這篇文章可以引來更多有益的討論，對於新接觸程式設計這塊領域的新鮮人來說，應該可以避掉很多前人走錯、不應再重蹈覆轍的錯誤路子。

1. 文件標示不明，註解不清：這大概是所有程式設計師在看其他人所寫的程式時, 最痛苦的一件事了。在一間公司裡，不管你有多麼資深，有時候總免不了得先看懂別人在寫什麼程式，好接手寫下去（或合作開發應用程式）。曾經聽學長說過, 在大型專案裡, 自己重新寫永遠都比改別人程式還快――因為有的人寫得實在是太亂啦！！！看不懂！這就好比今天有個人用火星文寫了一串密密麻麻的文字，又沒留下小抄著明說哪一段文字是在寫什麼，之後老闆要你接手繼續寫下去，天呀，光是搞懂他標題在寫什麼就已經花去大部分的時間了，要準時交出程式？怎麼可能！有的人還誇張到連自己以前寫什麼都看不懂呢！

解決之道：在寫程式時，每個人記得要順手留下註解，不見得要長篇大論，但至少要註明大概的用途，能說明演算法內容者更佳。有的人可能在撰寫時可能會留下一些測試用程式碼，寫完以後就刪得乾乾淨淨。如果你沒有寫doc的習慣，至少把這些測試碼註解起來就好了，千萬別刪！要知道你的隨手小筆記，可能是未來接手者的救命丹呢。

2. Coding Style不統一：如果你曾參與過程式整合測試的流程，你可能會發現，同樣是寫程式，不同的教育背景與習慣竟會導致這麼程式設計style上的不同，有的人習慣javascript 這種直敘式的語言，有的人則習慣Java這種以物件導向（Object Oriented Programming：簡稱OOP）為架構，而且你很可能會在他桌上找到一本厚厚的Design Patterns原文書。這些語言以及相對應的設計習慣，並沒有誰對誰錯，就像鋼筋混凝土與木材都一樣可以用來蓋房子，只要在對的環境用對材料，就可以撐上個幾十年。但是對同一個開發團隊而言，不同的設計習慣可能會帶來災難，就好像一棟房子上面是用鋼筋水泥，可是地基卻是用木頭做的，想也知道會出現問題 ――Mr. Friday曾經從教科書上看來一個例子，因年代久遠，Mr. Friday記憶中的可能跟事實有點出入，不過大意是這樣：有間歐洲銀行花大錢委託國外軟體商開發一套金融交易系統。這個國外軟體商開發好幾個月後，把成品交給義大利銀行總部使用，結果總部人員一打開程式，竟然發生大當機。銀行總部與軟體商花了好大一番功夫，才找到問題癥結點――日期格式不一樣！比如說 2004年7月1日，有的地方會寫成04/07/01，有的地方是寫07/01/04，當然更有的地方是寫01/07/04……而正好軟體開發商與銀行用的日期格式是完全不同的，造成系統日期判定錯誤，最後結果竟然是得重新開發一次！不同的日期格式就能夠造成如此災難了，同一個開發團隊裡面、不同的 coding style造成的災情亦可想而知。

解決之道：團隊裡面難免會遇到不同背景的程式設計師，除非你很確定所有的參與者都有一致的開發習慣，否則這時最好能先由一個領導者確立程式的整體結構，並參與API介面的制定，甚至是變數的取名與傳遞方式。一些常見的公用變數與程式的使用方法最好記載在一份公開文件或wiki中，讓工程師共同參考。如果只有少數幾個人的程式設計習慣與其他人不同，建議是先讓他們從修改一些簡單的程式碼著手，先讓他們逐步習慣其他人的設計方式，過一段時間後再投入主力程式的開發。

3. 絕對不要輕易相信One Size Fits All：網頁程式設計師應該特別明瞭這一點，因為他們絕大多數的人都歷經過「IE正常顯示，可是在Firefox打開就亂掉了；好不容易Firefox上調到正常，結果IE上的畫面變成一團糟」的痛苦。各家瀏覽器支援的標準不同（當然很多人會告你是IE不守規矩）已經不是新聞，不過這種事在其他的程式設計領域也是常常遇到：不同OS、不同的通訊標準、甚至是如前述所說不同的日期表示方式。什麼？你說「Java不就是一個跨平台的最好標準嗎？用Java開發的程式可以在各種不同平台上順利執行啊！」噢噢，可別忘記那是指「在同一個版本的JVM上」喔！Mr. Friday就曾經遇過某個用JDK 1.4開發的程式，到了新版1.5.0（不知道為什麼Sun要稱1.5.0版為”5.0版”…）上compile後卻跳出一個錯誤：某個JDK所提供的函式已經depreciated（過期，不再支援）了！更別說有的人搞不好用的不是Sun（比如說BEA）所提供的JVM哩，誰知道會不會有什麼Bug在裡面！

解決之道：千萬不要在未經大量測試前宣稱自己是跨平台還是跨所有瀏覽器的程式，比較盡責的做法是像MySQL官方網頁那樣，列出所有程式版本與平台，並註明哪些版本在哪個平台上歷經大量測試、問題較少，哪些版本是有支援，但未經大量測試。如果你比較懶，至少也應註明自己的開發與測試平台是哪些！

4. 絕對不要把程式進度當作可以量化的指標，除非你不打算過著人類正常吃喝拉撒睡的生活：寫程式與其他工作不一樣之處在於，它永遠都是新的挑戰。科技日新月異，程式設計師面對的挑戰永遠是在新的平台、新的通訊協定、新的規格（甚至是新的程式語言）上設計新的程式。即使你以前寫過類似功能的程式，你也不可能確保以前的設計方式在新的平台上會不會出問題。如果你信心滿滿告訴老闆說明天早上程式一定會寫完，換來的代價很可能是公主徹夜未眠還寫不完！

解決之道：你可以根據你過去的紀錄推知類似的程式功能你大概會花多久完成，但是絕對要預留「如果遇到很難解決的問題…」的後路。記得在學校時代上系統設計分析方法時，教授曾說：「據統計，只有40%的專案能夠如期完成。」Mr. Friday雖然不知道教授口中的統計數字從何而來，但是根據Mr. Friday身邊所有人的經驗，絕大多數的專案都難以按時完成。對一個身負「如期完成」重任的專案經理來說，寧可在早期以加班或增加人手的方式把程式維持在一定進度，如果還是無法負荷，也可以試著修改專案目標，免得一拖再拖，到了開發後期根本是無止盡的拖延。

5. 缺乏遠見：已經有很多書告訴你Design Patterns、UML、Class Diagram還是Normal Form這些幫助規劃程式架構的工具有多重要，可是這些書卻常常忘記提醒大家「有遠見」是多麼的重要。永遠不要小看自己所寫的程式，也許這個程式未來會變成大家都流行的基本配備也說不定。60年代的程式設計師也沒想到只取後兩碼數字的習慣，會在40年後造成Y2K問題。同樣地，一個簡單但卻不夠彈性（scalability：這個字沒有恰當的中文翻譯，多數人翻成擴充性，意思為能支援的標準很多、經得起各種情境的測試）的設計，也可能會在程式完成後產生意想不到的錯誤。

解決之道：就算寫的程式再容易，也千萬不要忽略在scalability方面的考量。與其在設計時多花個幾小時思考，也勝過程式寫完後才發現「糟了！得重寫了！」

每個人心中都有一個衡量「好的程式設計師」的一把尺，也許標準人人不同，但如果缺了這五項該注意的事，這個人肯定難以成為出類拔萃的程式設計師。謹以此心得，紀念過去那些沒有睡眠的夜晚、奉獻在無用程式的心力上T__T