|
要判斷一個程式設計師是不是好的程式設計師，主要看他寫的程式碼，因為程式設計師最重要的事是寫程式碼。
即便不去理解程式碼的意圖，只要看一眼，好的程式設計師寫的程式碼與差的php程式設計師寫的程式碼基本上就可以看出來。好的程式設計師寫的程式碼，整齊而規範，視覺上自然有一種美感。空白錯落有致，註釋恰到好處，命名和排版遵守統一的規範。差的程式設計師寫的程式碼則經常出現過長的函數，前後不一致的命名方式和排版，過深的嵌套結構，非常複雜的表達式，隨處可見的數字等毛病。
再去粗粗閱讀，對好的程式設計師還是差的程式設計師就會更有把握。好的程式設計師寫的程式碼，有一種精心雕琢而成的一致性。好的程式設計師一致會遵守統一的命名方式，如camelCase，而差的程式設計師的變數命名時不時的就會偏離統一規範。好的程式設計師的程式碼中拼字錯誤幾乎不可見，而差的程式設計師的拼字錯誤要多得多。好的程式設計師對於同一類動作，不會忽而用這個動詞，忽而又用那個同義詞，如add/insert混用。好的程式設計師採用一致的簡寫規則，差的程式設計師則時而不簡寫，時而簡寫。好的程式設計師會很注意名稱中形容詞與名詞誰在前誰在後，而差的程式設計師沒有規則，時而在前時而在後。好的程式設計師很少會寫出大段大段的重複程式碼，差的程式設計師卻常常搞不定重複程式碼，他們難以將重複的程式碼抽取出一個統一的概念進行重用。好的程式設計師對於對外的API會注重註解與程式碼的一致性，差的程式設計師經常註解中的參數名稱與函數定義都不一致。好的程式設計師很少會留下被註解掉的或用#if 0括起的垃圾程式碼，他們意志堅決，程式碼有用就要，沒用就不要，差的程式設計師則不一樣，他們常常不確信一段程式碼是否真的需要，他們缺乏保持程式碼整潔的習慣，因此他們讓垃圾程式碼留著。
如上，即便你不懂他所用的語言，不關心程式的邏輯，對好的程式設計師還是差的程式設計師就能做到八九不離十的判斷。程序的好壞幾乎總是取決於它們是否漂亮，不漂亮而好的程序，除了C STL源碼，我再也沒見過(如果你稍仔細看，STL的源碼雖然不夠漂亮，但仍然滿足這裡提出的一致性原則)。而好又漂亮的程式碼則隨處可見，如Linux Kernel，InnoDB，JDK，JUnit等等。
如果再仔細閱讀，就能更準確。好的程式設計師寫的程式碼，好像渾然天成，簡單又直白。函數通常較短小，函數的名稱準確的反映函數要完成的工作。邏輯簡單自然，讓你讀的時候由衷的發出啊，就應該是這樣的感嘆，而差的程式設計師的程式碼常常讓你發出怎麼是這樣？這是再做什麼呀？的疑問。好的程式設計師會在緊要關頭加以畫龍點睛般的註釋，差的程式設計師要不是沒註釋，就是註解只是程式碼的重複，純粹是廢話，更差的是註解是錯的，是誤導。
好的程式設計師未必是語言律師，即那種非常清楚的了解語言的各個細節，在程式設計時到處使用的傢伙。好的程式設計師也不常炫技，在程式碼中精心構造一些獨具匠心的片斷，他們偶而會，但大多時候總是用直白的語言來表述。
從程式碼也可以看出一個程式設計師的團隊協作精神。注意團隊合作的程式設計師，會嚴格依照團隊規範寫程式碼，而風格與團隊規範不一致的程式設計師則很可能欠缺團隊精神。注意團隊合作的程式設計師會注意給模組的對外介面加以重要的說明，如前置條件、後置條件、參數能否是NULL等等，不注意團隊合作的程式設計師懶於處理這些細節。
好的程式設計師與差的程式設計師的生產力差異巨大，專案的週期越長，專案越複雜，專案對品質的要求越高，好的程式設計師的價值就越大。好的程式設計師與差的程式設計師，管理成本也差別巨大，好的程式設計師只需要與他共同決定設計，程式碼可以不看，差的程式設計師的程式碼經常需要經過多次review，且仍有可能達不到理想的品質。
要成為好的程式設計師，首先要樹立要成為好的程式設計師的志向，再勤加練習，天長日久，就會越來越好，這些人不怕老。沒有志向永遠成不了好的程式設計師，這些人若不在老去之前成為經理就會變成廢人。
通過兩個小時的筆試和半小時的面試對於判斷程式設計師來說是不夠的。透過筆試與面試，你可以判斷一個程式設計師是否具備演算法與資料結構等基礎知識，可以判斷他對程式語言的特性是否掌握，可以判斷他對技術是否關注，然而要知道他能否真的能很好的完成工作，不寫程式碼是不夠的。
那些顯得對科技充滿熱情的，未必是好的程式設計師。這些人可能非常樂意從事有新意的工作，但後續的編碼、測試、調試、文案工作可能會讓他們感到厭煩。他們可能會提出好的創意，但卻常常不能夠有始有終的將其完成。公司不需要多少這樣的人。
因此招募的方式需要改善。招募是最重要的，因為進來後就難以出去，即便是試用。轉正條件白紙黑字寫的很清楚，只要合格就可以轉正，要達到合格並不是很困難。今年部門裡進了很多新人，不是人人都很優秀，但確實也都合格，自然也應該轉正。
改善招募的方法，就是讓他寫程序，可以出兩道題，一道讓他寫程序，一道讓他重構一個已有的較長的程序，一天之內完成。假使可以考他半個月，那麼重構是不太需要的，但一天的時間太短，透過重構可以考察閱讀並理解程式碼，並透過重構化腐朽為神奇的能力。那些不願意寫別人的程式碼，不願意接受別人的程式碼，經常要重來一遍的人是不理想的。
今年有兩個人採用了類似的方法。有一位履歷很優秀的人，做了兩道程式設計題被拒了，有一位履歷及面試一般的人，通過程式設計測試，錄用了。我感覺比單純的筆試與面試準確。
免費領取LAMP兄弟連原創php教學光碟/《細說PHP》精要版，詳情諮詢官網客服：http://www.lampbrother.net
PHPCMS二次開發 http://yun.itxdl.cn/online/phpcms/index.php?u=5
微信開發 http://yun.itxdl.cn/online/weixin/index.php?u=5 🎜>行動互聯網伺服器端開發
http://yun.itxdl.cn/online/server/index.php?u=5Javascript
課程 http://yun.itxdl.cn/online/js/index.php?u=5CTO
訓練營 http://yun..xdl.
|
