高效程序員的7個共同特徵

要想成為高效的程序員，你需要具備一定的綜合素質才能夠讓你用你所掌握的技能、經驗和知識編寫出有效的代碼。

有一些開發人員在技術方面具備一定的技巧，但他們永遠無法成為高效的程序員，就是因為他們缺乏所需的其它幾項特質。

1. 主動學習新的技術和非技術兩方面的知識

不好的程序員只有在實在不行的時候才開始進行知識學習。良好的程序員會主動學習新的技術知識。

偉大的程序員不僅會自行學習新的技術知識， 而且還會學習非技術方面的知識，對各種知識來源都有一種開放的心態，而不會象有的人那樣固步自封。

具體點說，不好的程序員只有在參加了採用WPF的項目時才開始學習XAML；良好的程序員一年前就學習了XAML，因為他感覺它很有意思；而偉大的程序員還閱讀了WPF應用程序的設計指南、可用性（usability）理論或者什麼類似的學習課程，因而他能夠製作出卓爾不群的UI。

2. 務實而不教條

嚴格遵守那些不成文的「編程規則」往往是一種奢侈品，沒有多少開發人員能夠承受得起。如果你們的規格說明書不是由頂尖的開發人員編寫的，也不是在頂尖的開發人員指導下編寫的，我就可以向你保證，你可能也承受不起。

我經常能夠碰到一些程序員，他們無法或者拒絕做某個任務只是因為完成這個任務的做法通常不為最佳實踐所接受。

業務需求很少會受到實現需求所採用的技術的制約；沒有人會說，「這我們不應該把這個需求寫到規格說明書里，因為要實現這個需求，程序員就不得不寫一段很臭的代碼。」

在結束的那一天，程序員的任務是要生成一個有效的應用程序，而絕不是要求在技術方面達到十全十美。我可不是在為垃圾代碼做辯護。

我想說的是，總會在有些時候，你會寫出一些代碼，這些代碼你永遠不會作為範例向別人展示做事的正確方法。

如果只有一種寫法，那麼這種代碼就不是糟糕的代碼 ——但要保證你已窮盡了其它所有可能的方案。

3. 懂得如何通過研究找到答案

通過研究找到答案可不僅僅只是在搜索引擎中鍵入幾個關鍵字那麼簡單， 也不是到Stack Overflow或者MSDN forums這類網站發個問題帖。

我就碰到過在搜索引擎里根本搜不到答案的問題，然後我Stack Overflow 或者MSDN forums里發的所有問題貼都沒有一個像樣的答案，不過我還是解決了我所碰到的問題使得工作得以繼續。我不是魔術師 —— 我只是懂得如何找到答案，如何找出問題的根本原因。

有許問題都屬於情景式的問題，如果你依賴於搜索引擎或者論壇，就會在各種鏈接中浪費大量的時間而最終無法得到真正的答案。

要學習如何進行根本原因分析，學習底層系統方面的知識才能夠找到其它的線索和解決方案，還要學習如果在對問題有個全局性的認識後才對其進行深入分析。

4. 擁有激情

不喜歡這份工作，就無法成為這個行業中的頂尖高手。倒是也有一些僅僅把編程當作一份普通工作的程序員水平也還不錯，但如果你的三觀就是如此的話，你就不太會願意去做能夠將你引向成功的所有事情。

這個觀點會使很多傢伙不悅，因為他們會覺得這是一種人身侮辱。「我是一個很好的程序員，但我還有其它重要的事情要做，我不能讓工作成為我人生的全部。」

我完全理解；我也有別的更重要的事情。儘管我也痛恨這麼說，當我們對我的工作熱情高漲之時，我願意（雖然不是渴望）拋棄我其它更重要的事情來首先完成手頭的工作。要說你不願意全情投入就無法成為高手，不算是人身侮辱，這是事實而已。

你的激情不能僅僅只在編程一個方面 —— 你必須在你的工作、你所使用的技術、你的老闆、你的項目等等方面都有激情。 我目睹過一些非常好甚至很偉大的程序員其表現平平，只是因為有一些條件不太合適。

比如，他們不喜歡手頭的項目，或者項目中所用的技術讓他們討厭。我曾經就是一個這樣的程序員，我也同這樣的程序員一起共過事。無論從哪個角度講，我都不喜歡這樣的程序員。

如果你發現你的情況就是如此，就需要立即解決這個問題，要麼挖掘出手頭的工作或項目中有意思的地方從而能讓你調整心情，要麼就不要接著幹了。怪不值當的。

5. 將自負留在門外

許多開發人員都非常自負。僅僅是比有些人聰明、懂得多一點或者經驗更豐富一點，可不是意味著和那些人相比你才是好人。

你要尊重別人，真正聽取並考慮別人的觀點，在需要的時候向他們求助，而且還不能小瞧別人。 你還應該更加關心團隊的勝敗，而不是僅僅關心你在工作中的榮譽得失。

6. 具有企業家的精神

最優秀的開發人員不會是遊手好閒者。對他們來講，產品的成功不僅僅意味著他們的薪水有著落了。因為他們在工作中熱情飽滿，他們是為了項目有更好的發展而工作，而且會一往無前。

7. 測量兩次，下刀一次...但測量不要多於三次

開發人員可能會犯的最糟糕的錯誤之一就是還不知道要幹什麼呢，就一猛子扎到代碼里去了。（當他們把這種做法稱作敏捷開發時情況更為糟糕，好像用敏捷兩字就能讓情況好轉似的）。

當偉大的開發人員跳進代碼里去的時候，那是因為需求規格說明同他們以前實現過的某種做法十分相似。偉大的程序員在面臨新問題時，他們會進行思考、計劃和研究。

開發人員當中最最優秀的不會墮入「分析癱瘓者（analysis paralysis）」陷阱。他們懂得要對某些事情小心謹慎（比如涉及錢或個人數據時），只有這些特殊領域才適合我所說的「要測量三次」。

任何超過三次的情況發生就意味著你在浪費你的時間（除非在鮮有的特例中，比如核反應堆、宇宙飛船、對沖基金會計系統）。

在某個特定的時間點就要停止計劃，開始編碼，然後再看看你的計劃在哪些方面需要進行相應的調整，這一點非常重要。

順便說一下，這就是我為什麼成為敏捷方法擁躉的原因之一。我所知道的最優秀的開發人員在計劃不再合適或者發現計劃有缺陷時，都會願意將計劃放棄掉。

小編拉你進粉絲微信群

不是在文章評論里回

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！