今天讀了converse的文章《程序設計總結》，感觸良多，說出了很多程序員經常遇到的問題，而像作者那種時常反思自己工作過程的習慣是值得我們學習的。
（文章地址：http://www.shnenglu.com/converse/archive/2007/11/21/37107.html）
我進入這個行業也有很長一段時間了，也有一些很深的體會，希望能夠跟大家分享。
1. 在完成自己的工作之后，一定要double check自己的作品，確認自己真的完成了任務，而且采用的是最好的解決方案。
剛剛開始工作的時候，很喜歡追求所謂的effective，但是對effective的理解僅僅存留在了quick對層次上，對質量則報了一種比較放任的態度。結果，自己經常提交一些自己認為已經完成了的工作，結果往往會在被他人review的時候指出多處錯誤，顏面盡失，而因為過于追求進度，代碼質量很差，經常會寫出一些學生代碼。鑒于此，在submit你的工作之前還是務必認真check一下，確認自己真的很好的完成了工作。
2. 把一個feature當成一個完整的作品來做。
往往我們拿到的工作只是一個系統的一個feature，這樣我們會抱以一種這只是一個模塊，做得怎么樣都只是一個feature而已，在這種情況下，我們的提交往往都是災難。所以，如果大家都把一個feature當作一個完整的作品，一個真正由自己完成的作品，那么你就會真正把這個feature當作自己的孩子一樣對待，仔細揣摩，認真編碼，最終，我們完成的會是一個質量很高的作品，而你也會為此自豪。
3. 當你不了解一個系統是如何運行的時候，建議盡快進入debug，而不只是鉆進文檔的海洋。
通過debug，你會很清晰的把握住一個系統運行的詳細過程，這將對你掌握這個系統很有幫助。
4. 盡量使用基本的方法解決問題。
俗語說：簡單就是美。雖然我們現在接觸的編程手段一般都是OOP，繼承，多態在很多人心里會是編程時的第一選擇，而為了表現自己技術的全面，往往還要加入設計模式show一下。其實，最美的程序還是由基本的數據結構+算法組成，繼承，多態，設計模式只是在我們沒有其他方法可用的時候的一種妥協。
5. 考慮問題盡量從大的方面開始，先把事情的骨架勾畫出來，再fresh out。
很多人在考慮一個問題的時候往往會鉆進一個很小的角落，把所有精力集中于一個局部的問題上。其實，在我們剛剛開始考慮一個解決方案的時候，最好的辦法還是先考慮High Level Design，然后才考慮一些局部的問題。對一個系統來說，設計才是最重要的。