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

Posted by Mr. Friday

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

喜歡這篇文章嗎? 分享出去給作者一點鼓勵吧!
  • http://vic-lin.blogspot.com/ Victor

    我忘記在哪裡看過,有人說百分之…忘了多少的文件,到最後都會遺失,所以有人就將文件寫在code裡面,Doxygen就是為此發明的,以註解寫文件,還可以產生各種格式的文件
    http://www.stack.nl/~dimitri/doxygen/doxygen_intro_cn.html

    關於遠見
    http://vic-lin.blogspot.com/2007/02/blog-post_19.html
    這是我的一點看法

    至於Y2K的問題,我是這樣認為,對於那個年代,每個Bit可能都是很重要的,也許沒有人敢浪費任何的一個Bit,因為那些機器都是價值連城的東西,為了四十年後去花費那多出來的兩位,可能會被老闆開除,而且誰能夠誇口,我的程式能夠活著過2000年呢? 我想應該沒有,很多細節,都不是在規劃時可以想得到的,是必須等東西開始Run才會發現的問題,因為規劃常常會假設每個環節都是完美的,但是現實卻不然,那些不完美的細節,常常是你想也想不到的。

    四十年前為了Y2K的事情煩腦,我可以肯定的說,這是幻想,不是遠見….
    二十年前為了Y2K的事情煩腦,這還是太遠了些
    十年前為了Y2K的事情煩腦,哦…那的確會發生,但….你的程式十年後還存在嗎?
    五年前為了Y2K的事情煩腦,嗯…也許你真的該這麼做

    幻想和遠見如果沒有分清楚,很容易的就會陷入做太多不必要的事情的無限迴圈,所以對於將來的擔心必須拿捏得剛剛好,保持一定的彈性是必要的,但過多的彈性真的有那個需要嗎? 我認為這就得好好想一想,程式能夠在未來存活,再來做修改,以程式的存活率來看,過度的擔心通常都是多餘的。

    不過在台灣情況似乎又有點不太一樣,因為台灣幾乎沒有軟體的生產,大部份都只是零零落落的Case在進行,因此…彈性對於接Case的Team來說,幾乎沒有什麼價值….,東西寫完了交出去就完事了,當這個Case須要做修改時,通常已經不是原來的人或Team在做的工作了….,所以…在台灣程式的生存週期更是低得可憐

    這個人寫的軟體開發的相關文章我覺得很不錯
    http://local.joelonsoftware.com/mediawiki/index.php/%E9%A6%96%E9%A0%81

    關於程式重寫
    http://local.joelonsoftware.com/mediawiki/index.php/The_Joel_on_Software_Translation_Project:%E4%BD%A0%E7%B5%95%E5%B0%8D%E4%B8%8D%E6%87%89%E8%A9%B2%E5%81%9A%E7%9A%84%E4%BA%8B

  • http://vic-lin.blogspot.com/ Victor

    我忘記在哪裡看過,有人說百分之…忘了多少的文件,到最後都會遺失,所以有人就將文件寫在code裡面,Doxygen就是為此發明的,以註解寫文件,還可以產生各種格式的文件
    http://www.stack.nl/~dimitri/doxygen/doxygen_intro_cn.html

    關於遠見
    http://vic-lin.blogspot.com/2007/02/blog-post_19.html
    這是我的一點看法

    至於Y2K的問題,我是這樣認為,對於那個年代,每個Bit可能都是很重要的,也許沒有人敢浪費任何的一個Bit,因為那些機器都是價值連城的東西,為了四十年後去花費那多出來的兩位,可能會被老闆開除,而且誰能夠誇口,我的程式能夠活著過2000年呢? 我想應該沒有,很多細節,都不是在規劃時可以想得到的,是必須等東西開始Run才會發現的問題,因為規劃常常會假設每個環節都是完美的,但是現實卻不然,那些不完美的細節,常常是你想也想不到的。

    四十年前為了Y2K的事情煩腦,我可以肯定的說,這是幻想,不是遠見….
    二十年前為了Y2K的事情煩腦,這還是太遠了些
    十年前為了Y2K的事情煩腦,哦…那的確會發生,但….你的程式十年後還存在嗎?
    五年前為了Y2K的事情煩腦,嗯…也許你真的該這麼做

    幻想和遠見如果沒有分清楚,很容易的就會陷入做太多不必要的事情的無限迴圈,所以對於將來的擔心必須拿捏得剛剛好,保持一定的彈性是必要的,但過多的彈性真的有那個需要嗎? 我認為這就得好好想一想,程式能夠在未來存活,再來做修改,以程式的存活率來看,過度的擔心通常都是多餘的。

    不過在台灣情況似乎又有點不太一樣,因為台灣幾乎沒有軟體的生產,大部份都只是零零落落的Case在進行,因此…彈性對於接Case的Team來說,幾乎沒有什麼價值….,東西寫完了交出去就完事了,當這個Case須要做修改時,通常已經不是原來的人或Team在做的工作了….,所以…在台灣程式的生存週期更是低得可憐

    這個人寫的軟體開發的相關文章我覺得很不錯
    http://local.joelonsoftware.com/mediawiki/index.php/%E9%A6%96%E9%A0%81

    關於程式重寫
    http://local.joelonsoftware.com/mediawiki/index.php/The_Joel_on_Software_Translation_Project:%E4%BD%A0%E7%B5%95%E5%B0%8D%E4%B8%8D%E6%87%89%E8%A9%B2%E5%81%9A%E7%9A%84%E4%BA%8B

  • http://www.wretch.cc/blog/spart spart

    mm~

    thxs for Mr. Friday’s sharing, this is my fist time to see ur article

    You must be good in computer programimg design!^^

    The five principles are very helpful to me, I’ll base on that when I’m coding, thank you :)

  • http://www.wretch.cc/blog/spart spart

    mm~

    thxs for Mr. Friday’s sharing, this is my fist time to see ur article

    You must be good in computer programimg design!^^

    The five principles are very helpful to me, I’ll base on that when I’m coding, thank you :)

  • http://thedoublee.blogspot.com Chenhai

    關於第一點,另一個說法是:
    如果你的程式需要註解,那你可能該考慮重新整理一下自己的程式.
    其實這點我覺得與函式的命名習慣有關.以C/C++而言,
    過去函式的名稱長度有其限制,另外注重的點也不同,所以造就了像”匈牙利命名法”這種習慣.
    可是以今日的情況而言,針對每一函式,取一個清楚的名字,就可以在你的程式中,明確的表逹出演算法,用途,以及想法.
    另外,文件也有很多種(依功能分別),Reference是絕對必要的,但國內的開發環璄,缺的不是Reference,而是Turtorial–這個程式,是怎麼運作的?要如何使用?關鍵點在那裡?彈性有多大?怎麼做Customize?
    說白了就是,要時時想著自己的程式,”並不是只有自己會用到”.

  • http://thedoublee.blogspot.com Chenhai

    關於第一點,另一個說法是:
    如果你的程式需要註解,那你可能該考慮重新整理一下自己的程式.
    其實這點我覺得與函式的命名習慣有關.以C/C++而言,
    過去函式的名稱長度有其限制,另外注重的點也不同,所以造就了像”匈牙利命名法”這種習慣.
    可是以今日的情況而言,針對每一函式,取一個清楚的名字,就可以在你的程式中,明確的表逹出演算法,用途,以及想法.
    另外,文件也有很多種(依功能分別),Reference是絕對必要的,但國內的開發環璄,缺的不是Reference,而是Turtorial–這個程式,是怎麼運作的?要如何使用?關鍵點在那裡?彈性有多大?怎麼做Customize?
    說白了就是,要時時想著自己的程式,”並不是只有自己會用到”.

  • http://mmdays.wordpress.com/ Mr. Friday

    感謝各位的見解,
    針對每一個函式取一個清楚的名字當然有助於他人了解程式的”意圖”. 不過如果今天user不只是要用這個函式, 而是要overriding時, 如果能有細節變數的描述會更有幫助. 當然, 不可能每支程式每個變數都會有詳細的說明, 這樣反而矯枉過正會讓其他人看不懂. 但是適當的在重要地方留下註解或提示(比如說…//add function here, 或是 // now add code to compute value), 我想這應該是每個入門者的基本功.

  • http://mmdays.wordpress.com/ Mr. Friday

    感謝各位的見解,
    針對每一個函式取一個清楚的名字當然有助於他人了解程式的”意圖”. 不過如果今天user不只是要用這個函式, 而是要overriding時, 如果能有細節變數的描述會更有幫助. 當然, 不可能每支程式每個變數都會有詳細的說明, 這樣反而矯枉過正會讓其他人看不懂. 但是適當的在重要地方留下註解或提示(比如說…//add function here, 或是 // now add code to compute value), 我想這應該是每個入門者的基本功.

  • Pingback: 從來不吃人肉 » 今日連結 2007-03-13()