轉自：http://blog.sina.com.cn/s/blog_682dc7810100kytu.html
對我來說，一個好的程序員的定義應該是渴望更少錯誤的代碼。 一些人也許認為好的程序員是那些懂得多門編程語言，懂得很牛技術的程序員，是的，這在某些情況下是對的。但歸根到底，無論你用什么樣的技術，什么樣的語 言，所有的程序被寫出來，其功能都要盡可能地沒有錯誤。 如果一個能力普通的程序員有足夠多的時間來做測試和發布程序，那么，其所有的代碼都會是沒有錯誤的。
但是，很明顯，所有的已經開發出來項目都是在不完美的條件下開發出來的，一般來說，幾乎所有的項目都是在壓榨程序員去盡可能地達到最大化軟件產品成 果。而且，軟件工業界對于深度測試和壓力測試并不關心，所以，我們總是期望那些趕工出來的代碼可以正常工作。 下面是是五個程序員可以在這種不完美的情況下做得更好的觀點（它們都和語言和技術沒什么關系，只不過是一種你的工作行為，能夠和所有的行業相通）
- 尋找不同觀點：程 序員好像并不喜歡技術上有異見的人，他們特別喜歡爭論各自的技術觀點。但是，他們忽略了不同觀點的價值。任何事情都有好有壞，我們應該學會在不同觀點中學 習和平衡。這樣才會更多的了解編程和技術。要經常在做事之前問自己和別人，這么做對不對？做完事后問自己，還可不可以改進？努力去尋找別一個觀點。程序員 應該經常上網，經常和同事討論不同的實現方法，不同的技術觀點，這樣才能取長補短。然而，在實際工作中，我發現程序員們并不喜歡互相請教，因為請教的人怕 別人看不起他，而被請教的人總是先貶低對方的能力，哎……（參看《十個讓你變成糟糕的程序員的行為》）， 如果有這樣的文化氛圍的話，那也沒有關系。上網吧，網上的人誰也不認識誰，可以盡情地問一些愚蠢的問題。呵呵。總之，一定要明白，如果某些事情只有一個觀 點，那么你一定要懷疑一下了，沒有觀點和技術方案的比較，沒有百花齊放的情況，你就無法知道是否還有更好的東西。真正的和諧不是只有一種聲音，真正的和諧 而是在不同的觀點聲音下取長補短，百家爭鳴（參看《十條不錯的編程觀點》）。否則，你永遠都不會接受到新的觀點，也就無法進步和成長了。
- 千萬別信自己的代碼: 在任何時候，一定要高度懷疑自己的代碼。很多時候，錯誤總是自己造成的。所以，當出現問題的時候，要學會review代碼中所有的可疑點，千萬別覺得某段 代碼很簡單，可以略過。事實證明，很多疏忽大意都是在陰溝里翻的船，都是那些很低級的錯誤。在查錯的過程中，切忌過早下結論，切忌四處亂改（參看《各種流行的編程風格》）， 停下來，想一想，會是哪兒的代碼有重大嫌疑，然后查看一下代碼，捋一捋程序的邏輯，調試并驗證一下程序的邏輯和變量在運行時是否是正確的。很多時候，對于 那些難纏的問題，最后解決了總是因為我們開始認真回頭審視所有的代碼。只有對自己的代碼保持著高度的懷疑，這樣我們才會想著如何讓其運行得更好更穩定，也 會讓我們在單元測試中下更多的功夫，這樣才能更能在那忙碌的環境中節省時間。相信我，在集成測試中fix bug的成本要比在單元測試Fix bug的成本大得多的多。一個簡單的例子就是memory leak。程序員對自己的程序需要有憂患意識，這樣才會越來越成熟，而自己的能力也會越來越強。
- 思考和放松: 做事前多想一想，這樣做事的時候就不會不顧此失彼，手忙腳亂，一旦事情一亂，你的心情也會更亂，于是，事情也就會更亂。最后，你只得重寫，這種事情太多 了。而且，在工作中要學會享受，要學會放松心情，我并不是讓你工作的時候聊QQ，我只是說，有時候，心態過于緊張，壓力過大，你的工作成果反而更不好，從 而又反過來造成新一輪的焦慮和緊張。我個人認為，思考和放松是可以完美統一的，思考其實就是一種放松，停下來，休息一 下，回頭看看走過的路，喝口水，登個高，看看過去走的對不對？總體是個什么樣？總結一下，然后看看前路怎么樣好走，這會你才會越走越好，越走越快。好的程 序員都不是那種埋頭苦干的人，好的程序員總是那些善于總結成敗得失，善于思考，善于調整，善于放松的人（參看《優秀程序員的十個習慣》）。不然，我能看到的情形是，你很快地把事干完，回到家剛坐下來，老板或是客戶就打電話來告訴你你的程序出問題了。總之，深思熟慮，動作會很慢，但是你可以保證你工作成果的質量，反而能讓你更多的節約時間。
- 學習歷史，跟上時代: 如果你是從十年前開始編程的，那么，今天的這門語言或是技術會有很多很多的改進和改善。你以前開發一個功能或函數，今天早已被集成時了語言中，而且做得比 你的版本要好得多。以前你需要100行代碼完成的事情，今天只需要1行代碼。這樣的事情在未來還會發生，所以，今天的你一定要學會如何跟上時代。但是，你 也不要放棄歷史，我現在看到很多程序員對一些現代的語言和技術使用的非常好，他們可以很容易地跟上時代。但不要忘了，計算機世界的技術更新和技術淘汰也是 非常猛的。所以，你一定要學習歷史，這些歷史不是產商的歷史，而是整個計算機文化的歷史（參見《Unix傳奇》）。只有通過歷史，你才能明白歷史上出現的問題，新技術出來的原因，這樣才能夠對今天的這些新的技術更了解，也才能明白明天的方向在哪里。學習歷史和跟上時代都是相當重要的。使用新型的技術，停下來接受培訓，可以讓你工作得更快，更高效（參看《未來五年程序員需要掌握的10項技能》）。而學習和總結歷史，才會讓你在紛亂的世界中找到方向。
- 積極推動測試活動: 只有測試才能保證軟件可以正常工作，只有測試才能保證軟件的質量。無論什么產品，都需要經過或多或少的測試。測試地充分的產品，你會發現其質理總是那么 好，測試的不充的產品，質量總是那么次。德系汽車，日系汽車質量怎么樣，關鍵還是在于怎么去測試的，測試的是否充分。所以，在你開發軟件的過程中，如果你 說你的程序寫地好，質量高，那么請你拿出實實在在的測試報告。在整個軟件開發過程中，做為一個好的程序員，你應該積極地在各個環節推動項目組進行測試活 動。不要以為技術需求階段和設計階段不需要測試，一樣的，只要你要release什么，release的這個東西都需要進行測試。技術需求怎么做測試？用 戶案例就是測試案例。在軟件開發的整個過程中，保證產品質量有時候比實現需求更重要，尤其是那些非常重要甚至人命關天的產品。
十個讓你變成糟糕的程序員的行為
1) 情緒化的思維
如果你開始使用不同顏色的眼光來看待這個世界的話，那么你可能會成為一個很糟糕的程序員。情緒化的思維或態度很有可能會把自己變成一個怪物。相信你經常可以看到很多很糟糕的程序會使用下面的這些語句：
- 我的程序不可能有這種問題。
- Java就是shit。
- 我最恨的就是使用UML做設計。
- 需求怎么老在變，沒辦干了。
- 受不了這些人，他們到底懂不懂啊。
- …… ……
這些帶著情緒化的思維和態度，不但可以讓你成為一個很糟糕的程序員，甚至可以影響你的前途。因為，情緒化通常都是魔鬼，會讓你做出錯誤的判斷和決定，錯誤碼率的判斷和決定直接決定了你的人生。
2) 懷疑別人
糟糕的程序總是說：“我的代碼一定是正確的，我懷疑編譯器有問題”，“我這應該沒有問題吧，STL庫怎么這么難用啊”。我曾經見過有程序員這樣使用 STL類：map<char*, char*>，當他發現這樣放入字符串后卻取不出來，覺得那是STL庫的BUG，然后自己寫了一個map！我的天啊！
某些時候，過早的下結論是一個很不好的習慣，任何事情都有其原因，只有知道了原因，你才能知道是誰的問題。一般來說，總是自己出的問題。
3) 過多關注實現，陷入問題細節
有些時候，當我們面對一個問題或是一個需求的時候，糟糕的程序員總是會馬上去找一個解決方案或是實現，這是一個很不好的習慣。設計模式告訴我們，“喜歡接口，而不是實現”就是告訴我們，認清問題的本質和特性要比如何實現更重要。
- 對于一個客戶的問題來說，首先應該想到的是如何先讓用戶正常工作，如何恢復正在“流血”的系統，而不是把用戶放在一邊而去分析問題的原因和解決方案。
- 對于解決一個bug來說，重現bug，了解原來程序的意圖是首先重要的事，而不是馬上去修改代碼，否則必然會引入更多的BUG。
- 對于一個需求來說，我們需要了解的需求后面的商業背景，use case和真實意圖，而不是去討論如何實現。只有了解了用戶的真實意圖，實際使用的方式和案例，你才能真正如果去做設計。
糟糕的程序總是容易陷入細節，爭論于如何實現和實現難題，以及問題的根本原因，而忽略了比這些更重要的東西。只有看懂了整個地圖，我們才知道要怎么去走。
4) 使用并不熟悉的代碼
糟糕的程序員最好的朋友是 Ctrl-C 和 Ctrl-V ，有些時候，他們并不知道代碼的確切含義，就開始使用它，有證據表明，由拷貝粘貼引發的bug占了絕大多數。因為，代碼總是只能在特定的環境下才能正常地 工作，如果代碼的上下文改變了，很有可能使得代碼產生很多你不知道的行為，當你連代碼都控制不住了，你還能編出什么好的程序呢？
5) 拼命工作而不是聰明的工作
對于糟糕的程序員，我們總是能看到他們拼命地修正他們的bug，總是花非常多時間并重復地完成某一工作。而好的程序可能會花雙倍的時間來準備一個有 效的開發環境，工具，以及在開發的時候花雙倍甚至10倍的時間來避免一些錯誤。好的程序員總是會利用一切工具或手段來讓自己的工作變得更有效率，總是為在 開發的時候盡可能得不出錯。后期出錯的成本將會是巨大的，而且那時改正錯誤的壓力也是巨大的。所以，糟糕的程序通常會讓自己進入一種惡性循環，他們看上去 總是疲憊的，總是很辛苦的，所以更沒有時間來改善，越沒有時間來改善，就有越多的問題。所以，拼命工作有些時候可能表明你不是一個好的程序員。
6) 總是在等待、找借口以及抱怨
當需求不明確的時候，當環境不是很滿意的時候，他們總是在等待別人的改善。出現問題的時候，總是在找借口，或是抱怨這也不好，那也不好，所以自己當 然就沒有做好。糟糕的程序員總是希望自己的所處的環境是最好的，有明確的需求，有非常不錯的開發環境，有足夠的時間，有不錯的QA，還有很強的team leader，以及體貼自己的經理，有足夠的培訓，有良好的討論，有別人強有力的支持……，這是一種“飯來張口，衣來伸手”的態度，這個世界本來就不完 美，一個團隊需要所有人去奮斗，況且，如果什么都變得完美了，那么，你的價值何在嗎？driving instead of waiting, leading instead of following.
7) 滋生辦公室政治
有句話叫“丑女多作怪”，意思是說如果一個自己沒有真實的能力的話，那么他一定會在其它方面作文章。糟糕的程序員也是這樣，如果他們程序編不好的 話，比不過別人的話，他們通常會去靠指責別人，推脫責任，或是排擠有能力的人，等等不正常的手段來保全自己。所以，糟糕的程序通常伴隨著辦公室政治。
8 ) 說得多做得少
糟糕的程序員總是覺得自己什么都懂，他們并不會覺得自己的認識和知識都是有限的。這就是所謂的夸夸其談，是的，什么都做不好的程序員能靠什么混日子呢？就是吹啊吹啊。
另一個表現方式是他們在評論起別人的程序或是設計，總是能挑出一堆毛病，但自己的程序寫得也很爛。總是批評抱怨，而沒有任何有建設性的意見，或是提出可行的解決方案。
這些糟糕的程序員，總是喜歡以批評別人的程序而達到顯示自己的優秀。
9) 頑固
當你給出一打證據說明那里有一個更好的方案，那里有一個更好的方向的時候，他們總是會倔強的認為他們自己的做法才是最好的。一個我親身經歷的事例就 是，當我看到一個新來的程序員在解決一個問題的時候走到了錯誤的方向上時，我提醒他，你可能走錯了，應該是另外那邊，并且我證明了給他看還有一個更為簡單 的方法，有。然而，這位程序員卻告訴我，“那是我的方法，我一定要把之走下去，不然我會非常難受”，于是，在三天后的代碼評審中，在經過頑固地解釋以及一 片質疑聲中，他不得不采用了我最先告訴他的那個方法。
這些程序員，從來不會去想，也不會去找人討論還有沒有更好的方法，而是堅持自己的想法，那怕是條死路都一往直前，不撞南墻永不回頭。
10) 寫“聰明”的代碼
他們寫出來的代碼需要別的同事查看程序語言參考手冊，或是其程序的邏輯或是風格看上去相當時髦，但卻非常難讀。代碼本應該簡潔和易讀，而他們喜歡在代碼中表現自己，并嘗試另類的東西，以顯示自己的才氣。是的，只有能力有問題的程序員才需要借助這樣的顯示。
記得以前的一個經歷，一位英語很不錯的程序員加入公司，本來對我們這些英語二把刀來說，我們喜歡看到的是簡單和易讀的英文文檔，然后，那位老兄為了 展示他的英語如何牛，使用了很多GRE中比較生僻的短語和詞匯。讓大家閱讀得很艱苦。最有諷刺意味的是，有一位native的美國人后來在其郵件中詢問他 某個單詞的意思。呵呵。
你是一個糟糕的程序員嗎？歡迎你分享你的經歷。