互聯網 - 大數據

前幾天，與

有學生問寫多少代碼量，會達到什么水平呢？這個有人這樣描述：代碼量是評判程序員水平高下的方法之一。微軟要求應聘程序員在大學四年間至少要寫10萬行代碼。李開復也建議計算機類的學生爭取在大學四年中積累編寫十萬行代碼的經驗。由此可見代碼量積累的重要性。

當你編寫過100行代碼的時候，應該對編程有了一個朦朧、感性的認識。

當你編寫過1,000行代碼的時候，應該已經掌握編程的基本結構了（順序、分支、循環）。

當你編寫過10,000行代碼的時候，可以用自己喜歡的編輯器做自己喜歡的小玩意兒了。

當你編寫過100,000行代碼的時候，你會對自己編碼能力充滿自信，并且發現公司中至少70%的人水平在你之下。

當你編寫過1,000,000行代碼的時候，恭喜你，終于成為老皮了，哦，我是說程序高手、高手、高高手，請給我一張你的名片。

首先，在這所描述的“寫”不是Ctrl+c 與Ctrl+V。是真正手打出來的，并且是調試完成無bug的可用代碼。其次，寫代碼與不是抄代碼，將書上或老師寫過的再重新打一遍，而是按自己業務邏輯編寫的代碼，編寫代碼的過程也是一個學習與思考地過程。還有，在寫代碼時，要不斷優化，不斷重構，這個過程對學習來講更重要，如果嘗試各種方法對比，再找出最優的方法，完成，盡管此時完成代碼量不多，但進步更快。優秀的成長過程，會不斷發現此前所寫代碼是多么“爛”，多么不完善，此時，如有時間一定要實驗一下新的思路是否正確。

如果你在不停的重構代碼，不停的思考更好方式，也不停的接觸面向對象，學習設計模式，研究各種開源的架構。那去做開發時，可能更多得是思考，去分析，寫代碼時間會少，完成項目的代量可能也會不多，但此時才是登堂入室了。大部分程序員只會使用語言編寫程序，但不知道這個源程序究竟是如何變成可執行代碼、變成什么可執行代碼，這些可執行代碼的執行時間是長是短。因此，要從根本上提高程序的效率，需要程序員深懂源程序到可執行程序的過程，深懂編譯原理、深懂匯編語言、深懂匯編中的系統調用。對于數據庫而言，程序員要深懂數據庫原理、深懂數據存放方式和數據查詢方式，深懂數據庫操作與I/O操作與內存的關系。而這些深懂是需要長時間編程積累的。

寫代碼更要講質量，前面所說不停的改，不停的思考，實際也是提高編寫代碼質量的過程。代碼的質量包括代碼結構，清晰性，可讀性，對于性能要求高的軟件，還包括算法的復雜性等是衡量一個優秀程序員的標準。要達到這個標準，是需要一個量變到質變的過程的，而質變的目的也是為了達到高質量代碼。所以，有時，寫過很多行代碼，未必就是優秀程序員。我曾經面視過，幾個不求上進的老碼農，從他們做過的項目看，代碼是寫了不少，可比優秀程序員差得很遠。原因，第一次寫過代碼，完成了功能，第二次再用，就考過去，稍加改動就可，至于代碼性能如何，是否可維護，是否可讀，性能怎么樣，根本不去多想。這樣下來，水平一直不會長進，自然會被社會淘汰，去努力得找工作！

下面談一下，作為技術總監從代碼怎樣去確認程序員。好的程序員寫的代碼，整潔而規范，視覺上自然有一種美感。空白錯落有致，注釋恰到好處，命名和排版遵守統一的規范,有一種精心雕琢而成的一致性。程序的好壞幾乎總是取決于它們是否“漂亮”，不“漂亮”而好的程序，除了C++ STL源碼,而又好又“漂亮”的代碼則隨處可見，如Linux Kernel，InnoDB，JDK，JUnit等等。

差的程序員寫的代碼則經常出現過長的函數，前后不一致的命名方式和排版，過深的嵌套結構，非常復雜的表達式，隨處可見的數字等毛病。

從代碼也可以看出一個程序員的團隊協作精神。注意團隊合作的程序員，會嚴格按照團隊規范寫代碼，而風格與團隊規范不一致的程序員則很可能欠缺團隊精神。注意團隊合作的程序員會注意給模塊的對外接口加以重要的說明，如前置條件、后置條件、參數能否是NULL等等，不注意團隊合作的程序員懶于處理這些細節。在此要重點說一下注釋，因為發現學生基本上不寫注釋。注釋并不是越多越好，但多的注釋總比沒有強。優秀程序員，不僅將必要參數，調用說明寫上，將改動過程注明，也將業務邏輯做簡單說明，還可能在必要地方寫上思路與思考過程，可能引發問題。

好了，先寫到這，拋磚引玉了。