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、還有討論區、客製化的內容管理系統。

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

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

;-)

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

希望以上的心得能夠啟發你，或讓你會心一笑。

;-)