tech-sjh

2011年6月10日 星期五

Jonathan Danylko 二十年來的程式設計心得

Jonathan Danylko 寫了一篇 Top 20 Programming Lessons I've learned in 20 years
摘譯如下:

Jonathan Danylko 自十一歲起就已經愛上科技與程式設計。他發現從事程式設計二十年
來有許多困難與容易的課題,也許同樣身為程式設計師的你沒有經歷過,接下來將要
分享他的經歷與心得(以下的我,如無特別註記,代表 Jonathan Danylko 先生):

我會隨著時間修改內容,也許以後會想到更多的事,但目前這二十條心得已經足以
包含所有的程式設計大小事。以下就是記憶最深的部份:

一、設定你認為解決這個問題要花的時間。不管設定半小時或一小時都好,當你在
自己設定的時間內無法解決某個問題,就找人問吧,不然趕快上網查資料也好。

二、一個程式語言就只是個語言。當你對單一個程式語言夠熟,就很容易對其他程
式語言觸類旁通,學習效果越來越好。你用來解決問題的程式語言要讓自己有相
當的"舒適"感,不影響邏輯思緒,可以產生有效率而且簡潔的程式碼,最重要的是
挑一個最適合解決這個問題的程式語言。

三、不要過度強迫自己使用設計模式。有時候一個簡單的演算法就足夠,不需要再去
勉強套上 singleton, facade 設計模式。對大部份的情況來說,簡潔的寫法最容易懂。

四、永遠要記得備份程式碼。我記得當發生硬碟全毀,資料完全救不回來的情景,並
對曾經發生的慘劇永保警惕之心。當你忘記備份時,可能就在要交程式的前夕發生
悲劇,不管單一份程式碼(snapshot)或版本控管紀錄都需要備份。

五、面對現實吧!你不是最強的程式設計師。我以前常認為自己很瞭解程式設計,但
    事實上你總是會遇到比你強的程式設計師。請向他們學習。

六、增進你的學習能力。因為第五項的緣故,我總是手邊帶著一份電腦書籍或雜誌,
    (我的朋友可以幫我作證),的確目前電子科技日新月異,要真的完全趕流行可是一份
全職工作才做得來的。當你有足夠聰明的學習媒介與方法,就可能一直乘著浪頭走。

七、變化是常態。你的科技知識跟程式設計能力應該像投資股票一樣:分散風險。不
要一直專注在單一項目自我感覺良好。如果某個程式語言與科技的支援不足,你也
可能需要更新履歷,開始重新練功。讓我保持一直向前的原則:至少要會兩到三種
不同類別的程式語言,當其中一項開始被取代,失去應用場合,至少你還有可以撐
場面的第二專長,並開始繼續學習新專長,隨時保持熟悉兩、三種程式語言的程度。

八、支援新進人員。幫助並訓練新進開發人員,教導程式設計原則與技巧。你永遠無法
預測下一步...你可能陞官,此時你會慶幸自己有對新進人員傾囊相授,因為你陞官空
缺的位子將有人幫你抬轎。

九、簡化演算法。撰寫程式時可以窮盡你的能力寫出複雜的程式,但當完成後記得回去
檢視你的程式碼進行改善。一點一滴的程式改進讓你日後可以愉快的維護這份程式碼。

十、為程式碼撰寫文件。不管是網站服務的 API 或是單一類別的文件,凡寫過的程式必
留下文件。我常被批評寫太多註解,但這卻是我引以為傲之處,為兩三行程式碼註解
可能只要幾秒鐘,如果是用了非常規的解決辦法,則更需要註解清楚你在寫什麼。
    如果文件寫得好,將可以佳惠設計架構、接手的程式設計師、技術支援部門的人。

十一、測試、測試、測試。我是黑箱測試的擁護者。當你完成程式後,就開始要對這段
    程式負責了,如果你們有品保部門,你將需要跟品保部門解釋更多程式錯誤。如果你
不完整的測試程式,除了需要改善程式碼以外,還會得到壞名聲。

十二、慶祝每次成功。我看到很多程式設計師解決令人頭痛的問題,他們會跟同事慶祝
,不論是簡單的搖擺、擊掌或是一段舞動。每個人在生命中遇到美好的事物,寫程式時
也可能因為寫出得意的程式碼想分享喜樂,也許你已經看過類似的解決方法上百次,
還是要記得跟你的同事同慶第一百零一次的歡樂。

十三、不論是專案或個人的程式,頻繁檢視程式碼。在公司中你總是有機會檢視程式碼
,讓人評鑑你的程式碼品質。不要認為別人故意惹惱你,把建議當作建設性批評。就
個人而言,永遠都要重新檢視程式碼,並總是自問:我要如何寫得更好?這將加速你
    的學習,讓你成為更好的程式設計師。

十四、回憶自己的程式碼。有兩種看以前程式碼的方式:我不敢相信以前寫這麼差。跟
我不敢相信以前寫這麼好。 第一種是覺得以前寫得很差,想知道如何改進。你將知道舊
的程式碼可以如何重構成更好的函式,或甚至改善整個專案的程式碼。第二種是驚訝於
自己以前的成就,開發者會有一兩個完成的專案,讓同事對你肅然起敬。當然這是來自
你的絕佳的程式設計能力,你可以拿出以前的函式庫或專案計劃,並改進成為更好的
產品或創意。

十五、培養幽默感。在二十年的開發經驗中,所有同事都抱著一定的幽默感,事實上幽
默感是你在這行業生存的必備技能。

十六、小心自稱全知、最懂的同事,佔有慾強,與沒經驗的程式設計師。遇到這些人你
反而要表現謙虛。自稱全知、最懂的人只是想吸引你的注意力,無法成為團隊成員。
佔有慾強的同事完成工作後,不會跟任何人分享。沒經驗的同事每十分鐘就會問你一
個問題,到最後他的程式都是你幫他完成的,而非他自己寫的。

十七、沒有簡單的專案。我常遇到朋友、家人、夥伴說:幫我寫個簡單的程式。要寫個
簡單的程式或網站,實際上需要雙方共同規劃,才可能完成一個雙方都滿意的產品。
如果有人說需要使用微軟 Access 寫三頁網頁,實際上他要的可能需要十五個網頁才
能完成的功能,並且需要使用 SQL server、還有討論區、客製化的內容管理系統。

十八、沒有理所當然的事。當你接下簡易的專案,可能會發現有些部份很容易解決。別
這樣想。在你沒有一份已經完成的類別、元件、或一段函式,並且經過完整測試,在
成功加入現有專案的產品之後,你再這樣想吧。

十九、軟體沒有完成的一天。曾經有同事告訴我軟體沒有完成的一天,只有暫時結案。
非常棒的建議。只要客戶還在使用你寫的程式,在經過一段時日的驗證後,大部份情況
是你還在繼續維護同一份程式碼。當然這並非壞事,這樣我們才有工作。;-)

二十、耐心是一項美德。當客戶、朋友、家人使用電腦遇到挫折,最後對電腦元件莫可
奈何時。我總是告訴他們:是人在控制電腦,不要讓電腦反客為主。寫電腦程式時也
同樣需要足夠的耐心,當程式設計師知道自己犯錯,並從電腦的角度理解之後,就會
    知道錯誤在哪裡。

希望以上的心得能夠啟發你,或讓你會心一笑。;-)

沒有留言:

張貼留言

版權宣告、免責聲明


姓名標示、非商業性、相同方式分享3.0台灣授權條款授權。
免責聲明: 本文所載資料僅供參考,並不構成投資建議,
讀者閱讀或使用該資料所導致結果需要自擔風險與責任,
作者概不承擔閱讀人行為之任何風險與責任。
除非有特別宣稱,作者言論並不代表所屬任何團體、公司、或其他人意見。