本文來自風(fēng)輕揚(yáng)的博客，原文標(biāo)題為《怎么樣才是好的程序員》。

要判斷一個(gè)程序員是不是好的程序員，主要看他寫的代碼，因?yàn)槌绦騿T最重要的事是寫代碼。

即便不去理解代碼的意圖，只要看一眼，好的程序員寫的代碼與差的程序員寫的代碼基本上就可以看出來。好的程序員寫的代碼，整潔而規(guī)范，視覺上自然有一種美感。空白錯(cuò)落有致，注釋恰到好處，命名和排版遵守統(tǒng)一的規(guī)范。差的程序員寫的代碼則經(jīng)常出現(xiàn)過長的函數(shù)，前后不一致的命名方式和排版，過深的嵌套結(jié)構(gòu)，非常復(fù)雜的表達(dá)式，隨處可見的數(shù)字等毛病。

再去粗粗閱讀，對(duì)好的程序員還是差的程序員就會(huì)更有把握。好的程序員寫的代碼，有一種精心雕琢而成的一致性。好的程序員一致會(huì)遵守統(tǒng)一的命名方式，如camelCase，而差的程序員的變量命名時(shí)不時(shí)的就會(huì)偏離統(tǒng)一規(guī)范。好的程序員的代碼中拼寫錯(cuò)誤幾乎不可見，而差的程序員的拼寫錯(cuò)誤要多得多。好的程序員對(duì)于同一類動(dòng)作，不會(huì)忽而用這個(gè)動(dòng)詞，忽而又用那個(gè)同義詞，如add/insert混用。好的程序員采用一致的簡(jiǎn)寫規(guī)則，差的程序員則時(shí)而不簡(jiǎn)寫，時(shí)而簡(jiǎn)寫。好的程序員會(huì)很注意名稱中形容詞與名詞誰在前誰在后，而差的程序員沒有規(guī)則，時(shí)而在前時(shí)而在后。好的程序員很少會(huì)寫出大段大段的重復(fù)代碼，差的程序員卻經(jīng)常搞不定重復(fù)代碼，他們難以將重復(fù)的代碼抽取出一個(gè)統(tǒng)一的概念進(jìn)行重用。好的程序員對(duì)于對(duì)外的API會(huì)注重注釋與代碼的一致性，差的程序員經(jīng)常注釋中的參數(shù)名稱與函數(shù)定義都不一致。好的程序員很少會(huì)留下被注釋掉的或用#if 0括起的垃圾代碼，他們意志堅(jiān)決，代碼有用就要，沒用就不要，差的程序員則不一樣，他們經(jīng)常不確信一段代碼是否真的需要，他們?nèi)狈Ρ３执a整潔的習(xí)慣，因此他們讓垃圾代碼留著。

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

如果再仔細(xì)閱讀，就能更準(zhǔn)確。好的程序員寫的代碼，好似渾然天成，簡(jiǎn)單而直白。函數(shù)通常較短小，函數(shù)的名稱準(zhǔn)確的反映函數(shù)要完成的工作。邏輯簡(jiǎn)單而自然，讓你讀的時(shí)候由衷的發(fā)出“啊，就應(yīng)該是這樣”的感嘆，而差的程序員的代碼經(jīng)常讓你發(fā)出“怎么是這樣？這是再干什么呀？”的疑問。好的程序員會(huì)在緊要關(guān)頭加以畫龍點(diǎn)睛般的注釋，差的程序員要么沒注釋，要么注釋只是代碼的重復(fù)，純粹是廢話，更差的是注釋是錯(cuò)的，是誤導(dǎo)。

好的程序員未必是“語言律師”，即那種非常清楚的了解語言的各個(gè)細(xì)節(jié)，在編程時(shí)到處使用的家伙。好的程序員也不常“炫技”，在代碼中精心構(gòu)造一些獨(dú)具匠心的片斷，他們偶而會(huì)，但大多數(shù)時(shí)候總是用直白的語言來表述。

從代碼也可以看出一個(gè)程序員的團(tuán)隊(duì)協(xié)作精神。注意團(tuán)隊(duì)合作的程序員，會(huì)嚴(yán)格按照?qǐng)F(tuán)隊(duì)規(guī)范寫代碼，而風(fēng)格與團(tuán)隊(duì)規(guī)范不一致的程序員則很可能欠缺團(tuán)隊(duì)精神。注意團(tuán)隊(duì)合作的程序員會(huì)注意給模塊的對(duì)外接口加以重要的說明，如前置條件、后置條件、參數(shù)能否是NULL等等，不注意團(tuán)隊(duì)合作的程序員懶于處理這些細(xì)節(jié)。

好的程序員與差的程序員的生產(chǎn)力差別巨大，項(xiàng)目的周期越長，項(xiàng)目越復(fù)雜，項(xiàng)目對(duì)質(zhì)量的要求越高，好的程序員的價(jià)值就越大。好的程序員與差的程序員，管理成本也差別巨大，好的程序員只需要與他共同確定設(shè)計(jì)，代碼可以不看，差的程序員的代碼經(jīng)常需要經(jīng)過多次review，且仍有可能達(dá)不到理想的質(zhì)量。

要成為好的程序員，首先要樹立要成為好的程序員的志向，再勤加練習(xí)，天長日久，就會(huì)越來越好，這些人不怕老。沒有志向永遠(yuǎn)成不了好的程序員，這些人若不在老去之前成為經(jīng)理就會(huì)變成廢人。

通過兩個(gè)小時(shí)的筆試和半個(gè)小時(shí)的面試對(duì)于判斷程序員來說是不夠的。通過筆試與面試，你可以判斷一個(gè)程序員是否具備算法與數(shù)據(jù)結(jié)構(gòu)等基礎(chǔ)知識(shí)，可以判斷他對(duì)編程語言的特性是否掌握，可以判斷他對(duì)技術(shù)是否關(guān)注，然而要知道他能否真的能很好的完成工作，不寫代碼是不夠的。

那些顯得對(duì)技術(shù)充滿熱情的，未必是好的程序員。這些人可能非常樂意從事有新意的工作，但后續(xù)的編碼、測(cè)試、調(diào)試、文案工作則可能讓他們感到厭煩。他們可能會(huì)提出好的創(chuàng)意，但卻經(jīng)常不能夠有始有終的將其完成。公司不需要多少這樣的人。

因此招聘的方式需要改善。招聘是最重要的，因?yàn)檫M(jìn)來后就難以出去，即便是試用。轉(zhuǎn)正條件白紙黑字寫的很清楚，只要合格就可以轉(zhuǎn)正，要達(dá)到合格并不是很困難。今年部門里進(jìn)了很多新人，并不是人人都很優(yōu)秀，但確實(shí)也都合格，自然也應(yīng)該轉(zhuǎn)正。

#t#改善招聘的方法，就是讓他寫程序，可以出兩道題，一道讓他寫程序，一道讓他重構(gòu)一個(gè)已有的較長的程序，一天之內(nèi)完成。假使可以考他半個(gè)月，那么重構(gòu)是不太需要的，但一天的時(shí)間太短，通過重構(gòu)可以考察閱讀并理解代碼，并通過重構(gòu)“化腐朽為神奇”的能力。那些不愿意寫別人的代碼，不愿意接受別人的代碼，經(jīng)常要重來一遍的人是不理想的。

今年有兩個(gè)人采用了類似的方法。有一位簡(jiǎn)歷很優(yōu)秀的人，做了兩道編程題被拒了，有一位簡(jiǎn)歷及面試一般的人，通過編程測(cè)試，錄用了。我感覺比單純的筆試與面試要準(zhǔn)確。