沒有標準化以前，誰用的程式碼短，誰就是高手。

現在流行標準化，你的程式別人都看得懂才是好程式，所以看不出來誰是高手。

所謂“菜鳥”級程式設計師和“大神”級程式設計師，在不同人的眼裡是有不同標準的，通常情況下我們把程式設計師劃分為應用級程式設計師和研發級程式設計師，不同級別的程式設計師裡都有非常優秀的人，下面做一個簡單的分析。

對於應用級程式設計師來說，主要的工作任務是功能模組的具體實現，往往都是在已有的技術平臺上進行程式設計，採用的也都是比較常規的開發技術。比如常見的Web開發、移動互聯開發等等。應用級程式設計師的關注點在功能的實現上，所以應用級程式設計師往往會根據不同專案採用不同的技術，力求功能實現過程快速和穩定。

對於應用級程式設計師來說，快速鑑別其能力的辦法很簡單，比如可以溝通一下，目前所採用的軟體體系結構，如果採用Java開發的話，一般初級程式設計師並不會研究OSGI這樣的結構性問題。

對於研發級程式設計師來說，主要的工作任務是不斷研發新的產品，主要工作是突破已有的技術邊界，對於這部分程式設計師來說，往往跟演算法打交道的比較多。舉個簡單的例子，如果做資料通訊方面的研發，如何降低資料通訊過程中的誤位元速率，這是一個比較現實的問題，也是研發級程式設計師需要重點解決的問題。

目前軟體行業的細分領域很多，要想知道一個程式設計師是否具有較強的研發能力，一定要同行業的人之間進行交流才會有一個比較客觀的評價。舉個例子，一個大資料專家可能並不瞭解計算機視覺方面的內容，這也是比較正常的情況。

如果有大資料方面的問題，也可以諮詢我。

看程式碼架構，是否合理運用各種模式和反射做到最少程式碼最優雅的實現所要功能，看業務邏輯寫法，是否有模組化有規範的做，看運用的技術架構是否先進和最適合使用，做到這三點已經足夠可以了

幹IT不容易

一不留神，就胖成了球

想想今年元旦前夕

我們在跨年夜立的flag

為什麼大半年過去了

我們還沒瘦下來

別擔心

理由，我已經給你們想好啦

01前臺

都說前臺是個最沒門檻的崗位

簡直是大錯特錯

不知道我們為了瘦成一道閃電

放棄了多少珍饈美味嗎

02品推

你這個文案沒有力量

這裡、那裡、這裡

感覺不太切合我的意思

不多吃點，我怕力量不夠

03公關

59分的通氣稿

客戶的“儘快給我”

老闆分分鐘奪命連環call

想挪個屁股都難

04碼農

白天都在糾結吃哪種外賣

好不容易熬到深夜回家

半路又遇到個燒烤攤

05運維

運維人每天的主旋律是什麼？

加班啊

伺服器連不上了

404了

資料不見了

客戶炸了

老闆瘋了

不吃點好的

哪來的力氣加班

06客服

售前讓我上點心

售後讓我上點心

好好伺候金主爸爸嗎？

弄得我慌成一批

於是我每天下午

都去吃點心

07研發

基本都是單身

自己解決第二份半價，真開心！

如果有另一半

指不定得跟我搶

一想到這裡，還是不要脫單了

08產品經理

一天到晚的

除了和傻逼客戶解釋

就是和豬隊友生氣

弄得我每天氣鼓鼓

連身體都開始膨脹

09投資人

投資人都很節儉

長期累積在身上的

才不是脂肪

那都是白花花的銀子啊

你說減就減

那我的投入產出比

誰來買單？！

10老闆

越到年底越是難瘦

這次飯局讓誰去都不放心

還得自己來！

11小北

身心上都承擔了太多

粉絲的期待

老闆的要求

還有同事的……嫉妒

這年頭，真的不好瘦啊

看迴圈和if的寫法，比較直觀

新手特別容易陷入多層for和if巢狀，最後程式碼難免變成這樣：

for(...){

for(...){

for(...){

//...很多個for，或很多個if

}

}

}

再比如，某函式當引數a不為0時執行一段邏輯，為零時什麼都不做。

新手：

if (a!=0){

//一段邏輯程式碼

}else {

return ;

}

老手：

if(a==0){

return;

}

//邏輯程式碼

//邏輯程式碼

//...

//...

老手的錯誤處理意識比較好，比如經常會用到try catch，新手通常沒這個意識，或運用不當。

老手用正則都比較6，新手八不得繞開正則。正則確實頭痛，這一點只能參考，畢竟有些老手也不喜歡正則～

老手通常會忍不住先做引數校驗再引用。新手很容易拿來就引用。

還有很多，懶得打了

很多公司在面試程式設計師的時候有的都不用筆試，直接談上一段時間就能給出結論這個人技術能力是不是適合做，能拿到多少工資，識別程式設計師水平高低談上幾句話就能搞定

如何鑑別一個程式設計師水平的高低？

1.程式設計基本功，直接用筆試題目或者面試的時候說幾個在專案中遇到的常見語法細節，這種屬於比較原始的考察方式，一般這種方式適用於剛畢業或者工作經驗不是很長的程式設計師，很多老程式設計師面試時候見到有單位出筆試題目，一般會直接選擇走人，筆試能夠測試基本功，有些老程式設計師由於常年在一個專職的崗位上知識有些固化了，可能導致以前的知識的遺忘，基本上做東西的時候都會先在網路上搜索下，然後才能做東西，坦白而言這種程式設計師距離優秀程式設計師還是存在很大差距，但現實中這樣程式設計師大有人在。

2.直接上機器寫程式碼，這種國內很多公司都會這麼幹，直接上機實現一個功能，谷歌這種公司倒是經常採用這種方式，由於這種方式在現實中操作起來還是比較麻煩，所以大部分公司還是以筆試或者面試為主，直接上機寫程式碼可以很直觀的看到程式碼邏輯思維，程式碼風格，程式設計功底一目瞭然，這是最直接測試程式設計師基本能力的方法。

3.直接面試中透過實際的專案案例來考察，基本上按照簡歷上做的專案問幾個在實際用到的細節就能大致判斷一個人水平高低，記得有個同事說起如何面試，直接會說專業的知識一直問到底，知道的多的直接錄取，雖然有點誇張但是有一定道理的，畢竟公司要的是對口的直接能夠上手幹活的人。

透過上面的三條，其實如何鑑別菜鳥還是大神都已經一目瞭然了。

菜鳥和高手幾點區別

1.菜鳥程式設計師拿到新的需求就急忙忙的上陣打仗了，把自己搞的忙呼呼的，由於考慮不全面做的東西基本上經常被打回來重新寫，經常的加班加點。高手拿到需求會在大腦之中，不停的尋找最佳的解決方案，可能在寫程式碼之前已經有很多方案被否定了，所以寫出來的程式碼成品率非常高，真正的高手寫程式碼的時間很短，大部分時間都在思考梳理思維。

2.菜鳥程式設計師基本上寫完程式碼之後，不太習慣對程式碼後續最佳化，甚至有些程式碼過了一段時間自己都不能識別出來，寫程式碼的時候基本上沒有指導思路，後續很容易忘掉。高手寫的程式碼時間長了回來基本上瞅一眼就能明白，主要高手在程式碼上不斷精益求精，不停更新自己程式碼思維。

3.抗壓能力也是菜鳥程式設計師和高手一個很大的差異，菜鳥遇到大的需求會覺得暗無天日，還會懷疑是不是自己不適合做程式設計師，高手來再大的需求都會很沉穩，任何一個程式設計師都會遇到專案緊急狀態，抗壓能力沒有很難在這個行業呆下去。

程式設計師高手也是從小菜鳥一步步學習起來的，要做到技術高階層次，先把基本功弄紮實，然後堅持下去，早晚會從小鳥變成老鳥。

這裡有一個問題，如何定義“菜鳥”級別和“大神”級別。如果沒有一個量化的定義，根本無法鑑別。如果你是產品經理，這明顯不是一個好的產品經理，這就叫做需求不明確！！！就好比我要掙很多錢，我要上清華。。。。。。全部是空洞的東西。若你是成功人士，這種空洞的東西叫做戰略，若你是無名小卒，就叫做眼高手低！！

有價值的免費資訊越來越少。現在全民娛樂至上，而“生於憂患死於安樂”早就拋於腦後。網上免費的資訊絕大部分是垃圾，在垃圾堆裡尋找有用的資訊，簡直是浪費巨大的時間。建議像這種沒有多大意義的提問少一些推薦！！！

程式設計師解決問題的能力是區別程式設計師水平的最主要依據，而不僅僅是會多少演算法，程式碼多規範。優秀程式設計師能夠快速解決各種問題，包括遇到過的問題和沒遇到過的問題，而菜鳥程式設計師會被各種問題卡住不知所措。

1，看毛髮，是否頂著地中海或者毛髮稀疏

2，看衣著，格子衫的通常是菜，穿著out的一般是老鳥

3，看系統

談不上鑑別大神鑑別的程式設計師，畢竟我也不是大神，怎敢輕易的評價大神。

如果是我的組員，並且我對他不瞭解，那麼我會給他分配一些查詢BUG的任務，最多協助他完成本地環境的搭建，告訴他如何重現問題，看看他是否可以找到BUG並修復。

如果他可以獨立面對大量的陌生的程式碼，抽絲剝繭找到BUG並修復，那麼我認為他是個很出色的程式設計師，加以時日，很大機率會成長為大神。

如果他有自己解決問題的思路，知道如何閱讀程式碼、查詢問題，雖然最終結果不盡如人意，但也算不錯的程式設計師，如果後期努力，應該也有機會成為高手。

沒有思路，也沒有方法，不過態度良好，在點撥之下，教一步學一步，最終也能達到效果，只能說是合格的程式設計師吧，技術差點兒，勝在態度。

還有一種就是要技術沒技術，要態度沒態度的，這種的“菜鳥”，堅決要清除出隊伍。

當然，很多時候要鑑別程式設計師的水平，是在面試的時候，這時可沒有太多的時間去分辨。我一般是看這個人業務理解能力、邏輯思維能力，最後才是技術能力。

說白了，就是聊專案，你做的專案是什麼，業務流程是怎樣的，你在專案裡面主要負責什麼，你對專案的貢獻有哪些。在聊專案的過程中，順便問問技術方面的問題，也僅限於你們專案把哪些資料放到Redis中，更新或超時策略是什麼，而不是你們透過什麼命令把資料放到Redis中，用Java的話怎麼寫。

程式設計師也是有一個成長的過程，希望現在的“菜鳥”，都能透過自己的努力變成“大神”！

初級寫程式碼，高階設計程式碼；初級只會接需求，高階會砍需求；初級解決自己的問題，高階解決公司的問題；初級考慮技術問題，高階還要考慮業務問題；初級做完專案就完事了，高階做完專案還會封裝元件，整理個手腳架出來；

最好量化的也許是【髮量】（開玩笑），初級與高階的差距不僅僅是程式碼好看不好看，擁有什麼樣的技術棧，而是比如解決問題的能力等等。

一、程式碼方面的區別

很多程式設計師拿到需求基本是沒有什麼思考的，直接開始寫程式碼了。寫著寫著頁面功能越來越多，程式碼越來越複雜，自己都會感覺難以維護。

還有一些開發，程式碼總是一片一片的，導致錯誤頻繁。當領導問起來之後還覺得程式碼是自己的個人風格問題。

而且也有的引起bug的主要原因就是計算返回結果出現問題，但是沒有極端值也沒有邊界條件為什麼還出錯了？—這就說明，壓根沒有自己單元測試，就是等著別人測試。

如果大家可以將一個頁面有哪些模組，有哪些事件，每個事件應該diapatch哪些action，整個模組有哪些資料放在state裡，在程式碼之前就思考好一定會有很多提升。

怎麼可以提升自己的程式碼設計能力？

試著採用TDD測試驅動開發。

在寫程式碼之前就要寫測試用例，在測試用例的時候思考每個函式每個模組，每個元件如何去設計，易於測試的程式碼都比較好維護。

二、思考業務上的需求

所以不光要考慮技術問題，還要考慮的是為什麼之前的人要這麼寫。難道就是因為沒有新的東西，之前的哪些元老就會比別人差麼？

很有可能是因為他們考慮了業務的需求，比如相容IE瀏覽器，或者是考慮了IOS使用者，或者是一些什麼特性的問題。

三、需求問題

你們身邊有沒有這樣的開發，不管是產品還是運營，提什麼需求都能接。然後忙不完要加班，但實際上做了很多沒有什麼價值的東西。甚至還有很多重複工作，把自己弄得特辛苦。

一個高階開發大機率不會讓自己或者團隊出現不能按時上線的情況：

給自己留出來相對處理問題的時間，考慮突發情況在需求分析的時候就會直接想到某一個需求是否有必要，要麼砍需求，要麼排好優先順序對需求進行準確評估

對需求的處理，主要是思考背後的價值。為什麼要做這個，能達到什麼效果是否可以達到這樣的效果，而不是聽運營和開發的一言堂。

四、解決問題的能力

初級開發解決一個問題，高階開發解決一類問題。初級開發解決自己的問題，高階開發解決公司層面的問題。

是否會在實際工作黨徽有一些公共的工具，是創造者還是使用者？在團隊完成一個專案的時候是增益的還是拖後腿的。

沒有專案的時候，是摸魚還是在看原始碼？

五、對業務的理解能力

一些優秀的程式設計師，拿到任務之後會非常重視業務，和運營、產品建立溝通。確保合理性再說執行問題。

但是也會有人—和各個部門去對接說明原因，想辦法解決。

六、初級程式設計師常見問題

1 命名不規範2 日誌不規範3 拒絕寫介面和假資料4 不寫單元測試5 盲目整合6 邏輯不清7 不做方案8 不關注效能9 害怕重構10 做出來就好，不考慮優雅的方案11 不考慮未來需求的變化12 遇到問題的時候不會試錯13 不會寫虛擬碼14 不做資料量的預估15 提交程式碼不規範16 不喜歡打Tag17 不遵守釋出流程18 不知道Bug修復的優先順序19 總喜歡手動修改線上程式碼20 不做資料備份21 不做自測22 不盡力模模擬實資料，測試資料很隨意23 不抽取公共程式碼24 不認真聽需求講解25 不看驗收標準26 不主動推進專案進度27 遇到難題不主動反饋

打個總結

初級開發容易缺乏思考，做的東西很多，也許沒有什麼價值。

高階開發不僅程式碼寫的好，更多的是思考相關的，做東西做有用的更有價值的。