如何從優秀的程式員成為偉大的程式員【轉】

 本文給出了十五個評定軟體開發人員的标準，可以幫助程式員朋友從一個好的程式員成為一個優秀的程式員，和大家共飨！

怎樣評定一名軟體開發人員？這是一個頗為奇怪的問題。現在已經有了很多的理論和形式來做這件事，人力資源部門也試着幫你管理和檢討自己的行為。然而，怎樣才是一個偉大的軟體開發人員，在今天，你該怎樣發展你的職業生涯？以下是我評定團隊中軟體開發人員的“軍規”。按照這些技巧和規則，你可以改善你的現狀，由一個優秀的程式員，成為一名偉大的程式員。

1、時間花在寫精彩的代碼上

這裡說的不是數量，而是品質。對此，一種歪曲是：要數量，也要品質。你也許會很多次的遇到以下的兩種情境：

情境A：你有一個發瘋似的能寫代碼的程式員，事情似乎在進展中……然後，Bug開始不斷出現，你們也不知道為什麼，好像永遠補不完。補完十個，又出來五個，現在你手裡的，就是一大堆代碼……

情境B：你現在有一個看起來很聰明的程式員，你面試他的時候，他似乎無所不知，能把理論說的頭頭是道。然而，你留給他三個任務，三個星期以後，他還在做一些三天就該幹完的事。這下該你困惑了，他這麼聰明，他知道generics（詳見備注），多線程的一切事情，甚至還能給祖母級的人講解什麼是指針，讓老太太興奮的想去程式設計。可是——怎麼什麼都沒完成？

于是，在夢境中——你寫出了堪稱偉大的代碼，——偉大的代碼是偉大的程式員寫出來的，他睿智，明白代碼的真正品質所在。寫代碼就像托尼•霍克在玩滑闆一樣自然優美，看上去就令人愉快。這些程式員以讓你眼花的速度搞定一切，他們知道每個問題應該處理多長時間，也不會追捧尋覓所謂的世界最好解決方案，弄很多線程很多層來寫一個簡單的遊戲。他們寫的程式沒有Bug，因為寫的時候自己測試過了，在睡覺時也在寫代碼說的就是這樣的人。這些程式員太寶貴了。

2、闡明問題

可以明确的是：即使有問題暫時處理不了，還有成百上千的方法去解決。有些人反應很迅速，很快就能提出多種解決方案。然而，一個偉大的程式員應該在做出行動以前清晰闡明問題——建立文檔或用白闆表達出來。他們寫郵件給項目的管理者，這樣表述：“我想和你說說我是怎麼了解這個問題的，我們能這樣處理嗎？”然後他們就會動手給你多種方案。

對，這些人明白自己看問題和闡明立場的方式，而這了解方式大概不會是問題建立者所想要被了解的。請牢記這就是關鍵所在。一名偉大的程式員在嘗試解決問題以前，一定要完全的了解它。你百分百搞明白了嗎？沒有？百分之九十九？——回去再多問些問題，確定百分之百了解清楚了。

3、怎樣着手解決問題

那一搞明白了問題，就開始動手寫代碼？錯！一個偉大的程式員應該按照規劃，開始思考面臨的多種選擇，基于問題開始考慮最好的解決方案。我覺的這像一場國際象棋比賽。你知道每個棋可以怎麼走，知道所有的遊戲規則。但是你會馬上走棋嗎？不，你要審時度勢，制訂計劃，緊盯對手，分析其通常的做法。和這一樣，在你coding解決問題以前，你也要這麼做。

看看問題，計算出需要怎樣的結果，你的時間能怎麼安排，預期的品質，你必須用的工具，……好了，開工吧！

4、對代碼的信任

作為項目管理者，你怎麼相信他們的代碼。有些程式員，你可以對他們說：“我星期五就要結果”。——星期五到了，你收到了這樣的Email：“代碼我都已經檢查過了，現在就等着測試了。”你很放心，隻會有很少的瑕疵在品質確定的團隊被查到。當然，還有些輕率的例子，一些程式員在郵件裡是這樣說的：“我還沒弄完，星期一上午我會最先完成它”。你不太确信這東西，發現很多Bug，很長時間基本上不能用。又得花上幾個星期清理代碼中的Bug。

關鍵：你對一個開發人員越有信心，他離成為一個偉大的程式員的距離就越近。想象你是你的管理者，如果他并不擔心你的代碼，會給你多少信心和勇氣！

5、對方案的信任

和對代碼的信任是一回事——如果你手上有偉大的程式員，你就會對解決方案有信心。這些程式員同時也是偉大的建築師。他們剖析整個問題，指出問題需要怎樣去解決。這就不隻是用偉大的代碼程式設計的問題了，很大程度取決于你怎樣構築解決方案。這是關鍵，而且會讓你在軟體世界裡出類拔萃。

6、滿足客戶需求

一天下來，你寫出了最棒的代碼、用了最好的架構和最好的解決方案，但這真的能迎合使用者的需求嗎？恐怕根本不是那麼回事兒。你搞砸了。盡管現在多次失手，一個偉大的程式員還是會正中靶心，找出客戶需要的，給使用者逐漸展示他們所需要的無bug的最終版本。需求正中靶心的同時，使用者滿意了。

7、不斷更新

偉大的程式員會積極主動地把自己的技術更新。他們對知識的态度就像餓貓見着了牛奶，他們從不用上級催促給自己設定目标、不用經理要求他們完成任務，因為他們自己就已經安排OK了。

他們發現自己想要參加的大會就會給公司寫Email“本人非常想參加今年的Tech-Ed大會。我将用心研習，并對作出貢獻。我預計這可節省 <金錢/其他原因>。如果可行，不知公司是否幫我支付此行？”如果我收到這樣的郵件，我不僅會幫他支付參會費用，他的路費我也會全程買單。

偉大的程式員們永遠會關注例如.net使用者組或Java使用者組的所有使用者群體。他們參加本地的技術會議，并從中汲取知識。你會看所有最新部落格和最新的雜志嗎？現在列出你最喜歡的前5個開發部落格。你能做到嗎？你應該像參加基督教青年會那樣輕松做到。做到這些，可以很好的幫助你延伸你的思路！你将會不斷獲得更好的點子！你會得到更好的回報！

8、團隊奉獻

你可以是團隊中最棒的那個人，可是如果你不是最好的程式員、不是建築師、不是團隊裡最有活力的人，那麼對我來說，如果你不能分享或對你的團隊有幫助，你的價值就會大打折扣。一個好的程式員會使自己周圍的人同樣強大起來。試想一下，好程式員會不斷完善自己的知識和能力，如果他們不和周圍的人分享他們的知識，他們從哪兒能獲得更多呢？

他們不斷學習新東西，發掘新技術，但是不會讓其他人知道他們這麼做了。一個好的程式員會準時完成方案，但是那是在催促和團隊得不到休息的前提下。然而一個偉大的程式員則會與團隊中所有的項目保持聯系，在需要的時候還可以出手幫忙。他們會如是說：“我注意到A團隊的項目進行到xx進度了，如果不介意的話，我想我可以幫忙？”

9、做好會議記錄

做好會議記錄絕對至關重要！開會期間，大家花大量時間來說明了新觀點、新主張、集體讨論還有提出了新設計方案，可是會議結束後卻沒有人可以拿得出會議記錄，簡直沒什麼比這更糟糕的事情了。即使你有會議大綱，我還是期望見到參會的每一個人員都可以帶着紙和筆（當然對于程式員來說筆記本則堪稱完美）。一個偉大的程式員會注意到這點。他們會記下所有的會議記錄，并且在會議結束的的時候說：“就剛才的會議，我着重記錄了幾點：XX…… 我是否記錄全了呢？”

接下來，偉大的程式員就會把他做好的會議記錄分發給項目管理者，列出會議時間、會議主題和參會者。接下來，是會議項目的标題和重要條目。在這之後，就是這些議題的詳細記錄。一個好的程式員沒有做會議記錄，并在會議上對提出的每項事宜都點頭稱是，那隻能寄希望于他的記憶力足夠好了。随後，他會給你發郵件讓你看看他的改動，你得回頭提醒他忘記的不多，百分之九十的都沒錯。——這不是浪費時間嘛！根本不是這麼回事！是以，做好你的會議記錄。

10、孺子可教和接受批評

如果你讀到這兒了，就表明你有希望接受這些建議，并在以後的開發行動中嘗試執行。對，程式員的另一項重要能力就是向他人學習并且能夠接受批評。通過把自己變為一個虛心受教的人，像海綿一樣快速吸收大量知識，畢竟在程式設計的路上你還有很多前輩。當然，也許他們在寫代碼的歲月裡慢慢生了鏽，甚至傷痕累累，但是他們畢竟曾披荊斬棘跨過無數的坎兒。對于做出正确決定，他們又着瞬間的本能，讓你不得不服。處于他們這個位置，很樂于見到你的成長和成功。

是以，隻要你是個偉大的程式員，就會理所當然的擁有理想的工作環境。如果你不斷改善技能、虛心好學、在别人給出的意見和批評中總結錯誤并得以改善，我向你保證你将會成為一個偉大的程式員而不隻是想象自己變得偉大而已。如果你總把自己想象成為“精英”而不進步，那你隻是自欺欺人。如果你不成長，你甚至不能停留到原地，等待你的隻有滅亡！

11、公司需要的時候總能出現

這如同等價交易。如果你為一家偉大的公司工作，他們會給你足夠的彈性。公司不會限制你如何工作，不限制你開始或結束的時間，也不會限制你什麼時候停下來歇歇。公司會鼓勵你在休息時間做做操，甚至會在你和團隊成員出去吃飯的時候為你們買單……在繁複大量而緊張的工作後，公司會放你幾天小假。諸如此類。

然而，毫無疑問，與前面的這些美事兒随之而來的是責任。如果趕上時間緊還得出活兒，偉大的程式員則建議你即使在周末也要加班。即使幹得再晚也得把活兒幹完。你看，偉大的程式員是要為自己的創作負責的。這雖不是必需的，但這是偉大程式員的标志之一。有些人隻想朝九晚五的上班，他們可能不錯，但是成不了偉大的程式員。偉大的程式員是團隊中幹到最後的那個，把作品視為完美的藝術，與團隊成員親如一家。

12、衣着職業化

你永遠也不知道一個客戶會什麼時候突然拜訪。你也永遠不會預知什麼時候突然要參加一個會議，不是每一件事都在計劃中的。你得随時準備好展現自己。一個好的程式員周一到周五穿着普普通通，甚至有可能穿牛仔裝和運動鞋來上班。在某些周五，他們穿着T恤，短褲和運動鞋出現。當一個客戶突然在周五出現，要談一個大項目，你沒法把衣衫不整的他一塊兒叫上。

一個偉大的程式員周一到周五都穿着職業化，衣服也能帶來成績。如果你不在意穿着，你也會因為穿的太奇怪而得不到晉升。毫無疑問，套裝和領帶還是很能提升你自己的。我向你保證，一套得體大方的西服套裝會讓你在今年就覺的物超所值。

13、溝通能力

這是另外的判定條件。這世上有太多優秀程式員，卻沒幾個偉大的程式員。為什麼呢？因為大多數程式員不善交流。交流的層次很多：從發電子郵件、參加小型SCRUM開發小組會議到大一些的主管會議，水準逐漸提升。這樣你就能在數百人參加的會議上自如地展示你的軟體。在會議上你不需要有好演技，但是至少要清晰明了地表達你的觀點。你的溝通能力越強，你的職業道路就會走得越遠！

概要：想要成為管理人員，你的溝通能力得分至少要打到9到10分。甚至你在會議上隻講了幾分鐘，或隻一個小彙報，你都需要非常好的表達能力。别隻是在你的每天的工作日志寥寥寫上“修補1371個bug”，你要做的是盡可能描述清楚如何在這麼艱難的情況下解決了問題。闡明你的方法，說明你如何保證這個bug不再出現。你就不再為你的日志發愁了。這會是你向經理展示自己的精彩演出。

14、目标設定的技巧

好的程式員日複一日的做你安排給他們做的事情，貫穿始終。他們并不往遠看，不對明年、5年甚至10年後作打算。一些好程式員雖然知道自己想要什麼，卻沒有具體計劃去實作。偉大的程式員則給自己訂立年度、未來5年的目标，而且大概預期到自己10年後的發展。

偉大的程式員有了目标不會隻是想象，他們會具體實施。他們會根據具體情況，在預期的時間做具體的事情。他們會詳細地制訂明年的計劃，包括要上的課程、要完成的項目甚至包括他們需要建立的人際關系。

15、組織技巧

把所有事情整合在一起的最關鍵要素是組織。你可能是世界上最好的程式員，但如果你不善于組織你所做的事兒，你的工作将陷入癱瘓，最終喪失優勢。偉大的程式員保持自己工作平台的整潔有序，保留所有的筆記并調理清晰。他們标出自己的會議日程表。他們有專門的收件箱給日程郵件、會議和新任務分類。他們保留文檔并能在需要時迅速找到所需。

額外要提到的：激情

偉大的程式員如果沒有熱情，那麼他的工作也并不偉大。好的程式員有了熱情來對待他的工作、方案和團隊，那麼他比偉大的程式員還要偉大。

在回顧的時候，我用這些标準來評判我的開發團隊。我給我的團隊盡可能最好的環境，作為回報，我想要他們都成為最偉大的程式員。你可以用這些标準來評判你的團隊，或者你本身就是一名程式員，請用這張清單來盡可能地改造自己來超越同侪。

備注：Generics是程式設計語言的一種技術，指将程式中資料類型進行參數化，它本質上是對程式的資料類型進行一次抽象，擴充語言的表達能力，同時支援更大粒度的代碼複用。對于一些資料類型參數化的類和方法來說，它們往往具有更好的可讀性、可複用性和可靠性。在設計集合類和它們的抽象操作時，往往需要将它們定義為與具體資料類型無關，在這種情況下，使用Generics就是非常适合的。

英文原文連結：http://www.realsoftwaredevelopment.com/2007/08/how-to-rate-a-s.html