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