他發現從事程式設計二十年來有許多困難與容易的課題,也
許同樣身為程式設計師的你沒有經歷過,接下來將要分享他
的經歷與心得(以下的我,如無特別註記,代表 Jonathan
Danylko 先生):
我會隨著時間修改內容,也許以後會想到更多的事,但目前
我會隨著時間修改內容,也許以後會想到更多的事,但目前
這二十條心得已經足以包含所有的程式設計大小事。以下就
是記憶最深的部份:
一、設定你認為解決這個問題要花的時間。不管設定半小時
一、設定你認為解決這個問題要花的時間。不管設定半小時
或一小時都好,當你在自己設定的時間內無法解決某個問題
,就找人問吧,不然趕快上網查資料也好。
二、一個程式語言就只是個語言。當你對單一個程式語言
二、一個程式語言就只是個語言。當你對單一個程式語言
夠熟,就很容易對其他程式語言觸類旁通,學習效果越來
越好。你用來解決問題的程式語言要讓自己有相當的"
舒適"感,不影響邏輯思緒,可以產生有效率而且簡潔的程
式碼,最重要的是挑一個最適合解決這個問題的程式語言。
三、不要過度強迫自己使用設計模式。有時候一個簡單的演
三、不要過度強迫自己使用設計模式。有時候一個簡單的演
算法就足夠,不需要再去勉強套上 singleton, facade 設計
模式。對大部份的情況來說,簡潔的寫法最容易懂。
四、永遠要記得備份程式碼。我記得當發生硬碟全毀,資料
四、永遠要記得備份程式碼。我記得當發生硬碟全毀,資料
完全救不回來的情景,並對曾經發生的慘劇永保警惕之心。
當你忘記備份時,可能就在要交程式的前夕發生悲劇,不管
某一版本程式碼(snapshot)或版本控管紀錄都需要備份。
五、面對現實吧!你不是最強的程式設計師。我以前常認為
五、面對現實吧!你不是最強的程式設計師。我以前常認為
自己很瞭解程式設計,但事實上你總是會遇到比你強的程式
設計師。請向他們學習。
六、增進你的學習能力。因為第五項的緣故,我總是手邊帶
六、增進你的學習能力。因為第五項的緣故,我總是手邊帶
著一份電腦書籍或雜誌(我的朋友可以幫我作證),的確目
前電子科技日新月異,要真的完全趕流行可是一份全職工作
才做得來的。當你有足夠聰明的學習媒介與方法,就可能一
直乘著浪頭走。
七、變化是常態。你的科技知識跟程式設計能力應該像投資
七、變化是常態。你的科技知識跟程式設計能力應該像投資
股票一樣:分散風險。不要一直專注在單一項目自我感覺
良好。
如果某個程式語言與科技的支援不足,你也可能需要更新
如果某個程式語言與科技的支援不足,你也可能需要更新
履歷,開始重新練功。讓我保持一直向前的原則:至少要會
兩到三種不同類別的程式語言,當其中一項開始被取代,失
去應用場合,至少你還有可以撐場面的第二專長,並開始繼
續學習新專長,隨時保持熟悉兩、三種程式語言的程度。
八、支援新進人員。幫助並訓練新進開發人員,教導程式設
八、支援新進人員。幫助並訓練新進開發人員,教導程式設
計原則與技巧。你永遠無法預測下一步...你可能陞官,此時
你會慶幸自己有對新進人員傾囊相授,因為你陞官空缺的位
子將有人幫你抬轎。
十二、慶祝每次成功。我看到很多程式設計師解決令人頭痛
跟
九、簡化演算法。撰寫程式時可以窮盡你的能力寫出複雜的
程式,當完成後記得回去檢視你的程式碼進行改善。一點一
滴的程式改進讓你日後可以愉快的維護這份程式碼。
十、為程式碼撰寫文件。不管是網站服務的 API 或是單一類
十、為程式碼撰寫文件。不管是網站服務的 API 或是單一類
別的文件,凡寫過的程式必留下文件。我常被批評寫太多
註解,但這卻是我引以為傲之處,為兩三行程式碼註解可能
只要幾秒鐘,如果是用了非常規的解決辦法,則更需要註解
清楚你在寫什麼。
如果文件寫得好,將可以嘉惠設計架構、接手的程式設計師
如果文件寫得好,將可以嘉惠設計架構、接手的程式設計師
、技術支援部門的人。
十一、測試、測試、測試。我是黑箱測試的擁護者。當你完
十一、測試、測試、測試。我是黑箱測試的擁護者。當你完
成程式後,就開始要對這段程式負責了,如果你們有品保
部門,你將需要跟品保部門解釋更多程式錯誤。如果你不完
整的測試程式,除了需要改善程式碼以外,還會得到壞名聲。
十二、慶祝每次成功。我看到很多程式設計師解決令人頭痛
的問題,他們會跟同事慶祝,不論是簡單的搖擺、擊掌或是
一段舞動。每個人在生命中遇到美好的事物,寫程式時也可
能因為寫出得意的程式碼想分享喜樂,也許你已經看過類似
的解決方法上百次,還是要記得跟你的同事同慶第一百零一
次的歡樂。
十三、不論是專案或個人的程式,頻繁檢視程式碼。在公司
十三、不論是專案或個人的程式,頻繁檢視程式碼。在公司
中你總是有機會檢視程式碼,讓人評鑑你的程式碼品質。不
要認為別人故意惹惱你,把建議當作建設性批評。就個人
而言,永遠都要重新檢視程式碼,並總是自問:
我要如何寫得更好?這將加速你的學習,讓你成為更好的程
式設計師。
十四、回憶自己的程式碼。有兩種看以前程式碼的方式:
十四、回憶自己的程式碼。有兩種看以前程式碼的方式:
我不敢相信以前寫這麼差。
跟
我不敢相信以前寫這麼好。
第一種是覺得以前寫得很差,想知道如何改進。你將知道舊
第一種是覺得以前寫得很差,想知道如何改進。你將知道舊
的程式碼可以如何重構成更好的函式,或甚至改善整個專案
的程式碼。
第二種是驚訝於自己以前的成就,開發者會有一兩個完成的
第二種是驚訝於自己以前的成就,開發者會有一兩個完成的
專案,讓同事對你肅然起敬。當然這是來自你的絕佳的程式
設計能力,你可以拿出以前的函式庫或專案計劃,並改進成
為更好的產品或創意。
十五、培養幽默感。在二十年的開發經驗中,所有同事都抱
十五、培養幽默感。在二十年的開發經驗中,所有同事都抱
著一定的幽默感,事實上幽默感是你在這行業生存的必備
技能。
十六、小心自稱全知、最懂的同事,佔有慾強,與沒經驗的
十六、小心自稱全知、最懂的同事,佔有慾強,與沒經驗的
程式設計師。遇到這些人你反而要表現謙虛。自稱全知、最
懂的人只是想吸引你的注意力,無法成為團隊成員。佔有慾
強的同事完成工作後,不會跟任何人分享。沒經驗的同事每
十分鐘就會問你一個問題,到最後他的程式都是你幫他完
成的,而非他自己寫的。
十七、沒有簡單的專案。我常遇到朋友、家人、夥伴說:幫
十七、沒有簡單的專案。我常遇到朋友、家人、夥伴說:幫
我寫個簡單的程式。要寫個簡單的程式或網站,實際上需要
雙方共同規劃,才可能完成一個雙方都滿意的產品。如果有
人說需要使用微軟 Access 寫三頁網頁,實際上他要的可能
需要十五個網頁才能完成的功能,並且需要使用 SQL server
、還有討論區、客製化的內容管理系統。
十八、沒有理所當然的事。當你接下簡易的專案,可能會發
十八、沒有理所當然的事。當你接下簡易的專案,可能會發
現有些部份很容易解決。別這樣想。在你沒有一份已經完成
的類別、元件、或一段函式,並且經過完整測試,在成功加
入現有專案的產品之後,你再這樣想吧。
十九、軟體沒有完成的一天。曾經有同事告訴我軟體沒有完
十九、軟體沒有完成的一天。曾經有同事告訴我軟體沒有完
成的一天,只有暫時結案。非常棒的建議。只要客戶還在使
用你寫的程式,在經過一段時日的驗證後,大部份情況是你
還在繼續維護同一份程式碼。當然這並非壞事,這樣我們才
有工作。
;-)
二十、耐心是一項美德。當客戶、朋友、家人使用電腦遇到
二十、耐心是一項美德。當客戶、朋友、家人使用電腦遇到
挫折,最後對電腦元件莫可奈何時。我總是告訴他們:是人
在控制電腦,不要讓電腦反客為主。寫電腦程式時也同樣需
要足夠的耐心,當程式設計師知道自己犯錯,並從電腦的角
度理解之後,就會知道錯誤在哪裡。
希望以上的心得能夠啟發你,或讓你會心一笑。
希望以上的心得能夠啟發你,或讓你會心一笑。
;-)