怎麼樣才是好的程式員

來源:互聯網
上載者:User

要判斷一個程式員是不是好的程式員,主要看他寫的代碼,因為程式員最重要的事是寫代碼。

即便不去理解代碼的意圖,只要看一眼,好的程式員寫的代碼與差的程式員寫的代碼基本上就可以看出來。好的程式員寫的代碼,整潔而規範,視覺上自然有一種美感。空白錯落有致,注釋恰到好處,命名和排版遵守統一的規範。差的程式員寫的代碼則經常出現過長的函數,前後不一致的命名方式和排版,過深的嵌套結構,非常複雜的運算式,隨處可見的數字等毛病。

再去粗粗閱讀,對好的程式員還是差的程式員就會更有把握。好的程式員寫的代碼,有一種精心雕琢而成的一致性。好的程式員一致會遵守統一的命名方式,如camelCase,而差的程式員的變數命名時不時的就會偏離統一規範。好的程式員的代碼中拼字錯誤幾乎不可見,而差的程式員的拼字錯誤要多得多。好的程式員對於同一類動作,不會忽而用這個動詞,忽而又用那個同義字,如add/insert混用。好的程式員採用一致的簡寫規則,差的程式員則時而不簡寫,時而簡寫。好的程式員會很注意名稱中形容詞與名詞誰在前誰在後,而差的程式員沒有規則,時而在前時而在後。好的程式員很少會寫出大段大段的重複代碼,差的程式員卻經常搞不定重複代碼,他們難以將重複的代碼抽取出一個統一的概念進行重用。好的程式員對於對外的API會注重注釋與代碼的一致性,差的程式員經常注釋中的參數名稱與函數定義都不一致。好的程式員很少會留下被注釋掉的或用#if 0括起的垃圾代碼,他們意志堅決,代碼有用就要,沒用就不要,差的程式員則不一樣,他們經常不確信一段代碼是否真的需要,他們缺乏保持代碼整潔的習慣,因此他們讓垃圾代碼留著。

如上,即便你不懂他所用的語言,不卻關心程式的邏輯,對好的程式員還是差的程式員就能做到八九不離十的判斷。程式的好壞幾乎總是取決於它們是否“漂亮”,不“漂亮”而好的程式,除了C++ STL源碼,我再也沒見過(如果你稍仔細看,STL的源碼雖然不夠“漂亮”,但仍然滿足這裡提出的一致性原則)。而又好又“漂亮”的代碼則隨處可見,如Linux Kernel,InnoDB,JDK,JUnit等等。

如果再仔細閱讀,就能更準確。好的程式員寫的代碼,好似渾然天成,簡單而直白。函數通常較短小,函數的名稱準確的反映函數要完成的工作。邏輯簡單而自然,讓你讀的時候由衷的發出“啊,就應該是這樣”的感歎,而差的程式員的代碼經常讓你發出“怎麼是這樣?這是再幹什麼呀?”的疑問。好的程式員會在緊要關頭加以畫龍點睛般的注釋,差的程式員要麼沒注釋,要麼注釋只是代碼的重複,純粹是廢話,更差的是注釋是錯的,是誤導。

好的程式員未必是“語言律師”,即那種非常清楚的瞭解語言的各個細節,在編程時到處使用的傢伙。好的程式員也不常“炫技”,在代碼中精心構造一些獨具匠心的片斷,他們偶而會,但大多數時候總是用直白的語言來表述。

從代碼也可以看出一個程式員的團隊協作精神。注意團隊合作的程式員,會嚴格按照團隊規範寫代碼,而風格與團隊規範不一致的程式員則很可能欠缺團隊精神。注意團隊合作的程式員會注意給模組的對外介面加以重要的說明,如前置條件、後置條件、參數能否是NULL等等,不注意團隊合作的程式員懶於處理這些細節。

好的程式員與差的程式員的生產力差別巨大,項目的周期越長,項目越複雜,項目對品質的要求越高,好的程式員的價值就越大。好的程式員與差的程式員,管理成本也差別巨大,好的程式員只需要與他共同確定設計,代碼可以不看,差的程式員的代碼經常需要經過多次review,且仍有可能達不到理想的品質。

要成為好的程式員,首先要樹立要成為好的程式員的志向,再勤加練習,天長日久,就會越來越好,這些人不怕老。沒有志向永遠成不了好的程式員,這些人若不在老去之前成為經理就會變成廢人。

通過兩個小時的筆試和半個小時的面試對於判斷程式員來說是不夠的。通過筆試與面試,你可以判斷一個程式員是否具備演算法與資料結構等基礎知識,可以判斷他對程式設計語言的特性是否掌握,可以判斷他對技術是否關注,然而要知道他能否真的能很好的完成工作,不寫代碼是不夠的。

那些顯得對技術充滿熱情的,未必是好的程式員。這些人可能非常樂意從事有新意的工作,但後續的編碼、測試、調試、文案工作則可能讓他們感到厭煩。他們可能會提出好的創意,但卻經常不能夠有始有終的將其完成。公司不需要多少這樣的人。

因此招聘的方式需要改善。招聘是最重要的,因為進來後就難以出去,即便是試用。轉正條件白紙黑字寫的很清楚,只要合格就可以轉正,要達到合格並不是很困難。今年部門裡進了很多新人,並不是人人都很優秀,但確實也都合格,自然也應該轉正。

改善招聘的方法,就是讓他寫程式,可以出兩道題,一道讓他寫程式,一道讓他重構一個已有的較長的程式,一天之內完成。假使可以考他半個月,那麼重構是不太需要的,但一天的時間太短,通過重構可以考察閱讀並理解代碼,並通過重構“化腐朽為神奇”的能力。那些不願意寫別人的代碼,不願意接受別人的代碼,經常要重來一遍的人是不理想的。

今年有兩個人採用了類似的方法。有一位簡曆很優秀的人,做了兩道編程題被拒了,有一位簡曆及面試一般的人,通過編程測試,錄用了。我感覺比單純的筆試與面試要準確。

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.