當了幾年的程序員了，一直都在想一個問題，什么是程序員，程序員應該做好那些事情，什么樣的程序員是有素質的程序員？什么樣的程序員算是負責的程序員呢？

工作當中我發現有不少員工是為了工作而工作，怎么回事呢？他們只是把我分配的工作分毫不差的完成，但從不問為什么？有些程序員是喜歡隨便改變需求，自己感覺不錯就得改，改了還不做報告，最后上交項目時才發現和需求不一樣？于是傻了。

我根據自己的經驗把程序員分為以下幾種

單純沒有腦子的

這種程序員是最讓經理氣的一種，因為大多是剛入門的，或是學生剛走出校門，不喜歡問，也不懂得分析，只是一味的很聽話，為什么說他們單純呢？那是因為他們從來不會問，不會說也沒有自己的想法，你讓干什么就干什么，讓自己怎么干就怎么干，聽上去感覺特好的員工，很聽話，如果只是這樣就好了，可怕的是他們沒有腦子，比如你說讓他完成一個增加的功能吧，他們很聽話的給你做出來，但只是一個增加的功能，他根本不會在增加功能之后再給你處理一下刷新數據的問題，或是做一些必要的驗證，更說不上代碼的擴展性，那都是見不著邊的事，不可能。

你說讓做一個查詢功能，他完全有可能給你做出來一個查詢所有的功能，不會管你要不要根據時間，要不要分頁，或是其它的方式的查詢，人家還可有理，會告訴你，你需求上沒說啊，只說要有一個查詢的功能？然后你無語。

有腦子先斬后湊的

這類程序員大致是工作有一年或是兩年工作經驗的人，自認為自己有些經驗了，做了幾個項目，感覺自己NB的不得了了。分配一個功能總有一些自己的想法，其實他自己不知道這些想法還不成熟，只是個人主觀意向，你說讓人家做一個導航條吧，你清楚的告訴他是在頭部用的，要直排下拉類型的。

好了得到需求了，他根本不管你為什么要這樣做，在做的過程中，他發現自己以前做一些項目里有導航條的，而且很好看，他們想，經理是怎么想的，設計的還不如我設計的好看，我給他改一下說不定還能得到他的獎勵，于是自己把直排下拉的導航改成了，直排出面板那種的，因為好看，而且還不告訴經理，想給大家一個驚喜，誰知道經理一看，說怎么改需求了，客戶不要這樣的，然后他就跟你講理，說這樣的好看，而且什么擴展性還好，技術先進，流行，然后你會很無耐的告訴他，你做的確實很好看，但是客戶不付錢怎么辦，于是沒辦法在你的“強逼”之下他不得不改，于是你對他的工作很不滿意，首先是這個人不好管，老自己做主，不把你當回事，怎么辦，好點的經理會慢慢引導一下，脾氣大的經理會直接扔出兩字“滾蛋”

我們來分析一下他的心理，第一種可能就是感覺自己做了很多項目，有一點自大，目中無人的心態，看不起別人設計的東西，總以為自己的技術和代碼很棒了，因為自己在程序界摸爬滾打一兩年了，也算是有所見識了。但他們確不明白，現在的自己正像當前的曹仁學曹操一樣，只是學得其形而為盡其神。大部分的軟件，網站，不能只看網站本身的價值，成功不成功，不是自己說了算，也不是經理說了算，還得看客戶，一句話客戶喜歡的就是好東西，客戶不懂技術啊，你寫的再好，客戶不懂哦，所以一定不要亂改需求，軟件要和市場結合才能真正體現出它的價值，做讓大家喜歡的軟件，而不是單純的技術堆積。

第二種可能就是，自己懶，因為兩年內也寫了不少代碼，手上有很多的源代碼，直接找個好點的能上就行了，為什么要自己寫啊，而且好看還快速。

第三種可能是自己實現不了，而又不想學習，感覺浪費時間，所以直接改動一下得了。感覺自己如果寫的話，寫好了還好說，寫不好，耽誤時間，一個導航幾天能不完，會很丟人的。于是要加速。

這類程序員有腦子，但是不聽話，管理是問題，一定要好好的引導，也希望在這個階段的朋友們注意了。加強學習，認真做項目，讓自己正規化。不要入魔道了。多看看資深的程序員的代碼，想一下經理為什么要這樣做，聽聽他的理由，在改需求的同時一定要寫報告，或是直接找經商量一下，不要自己做主。

有腦子，很聽話，很認真，但基礎不好，代碼有局限性

這類型的程序員大多是工作一到兩年的程序員，但和上面的不同，他們很有腦子思路很好，而且很聽經理的話，做東西很認真，做不完了自己會加班寫，學新的東西也很快，但是有一點不好的是，他們有很多理由說自己沒時間學習基礎，這些人一般是在學校沒有學好，出來之后后悔了，學起來很認真，由于學了些新的知識，起點高，看不起基礎的東西，從不想著沒事去看看編程基礎，看看算法，看看數據結構，總是以為我都能做出這樣的項目了，還看那些小東西會很丟人的，于是在公司從不看回家更不想看，時間長了，技術會有很大的局限性，對某一塊技術很不錯，但是對其它技術不怎么好，于是在接到一個項目時，總喜歡使用自己現有的，會的技術去實現，轉了一圈又一圈總算是把東西寫出來了，而且還是加班完成了，但是代碼的性能，穩定性，和效率上差的很遠，擴展性也談不上，時間一長，項目一多起來，就會出現多次反工，因為需求是會不斷變化的，于是自己的代碼也要變化，感覺很是理所當然，一個項目沒事，接手的多了就麻煩了，新項目剛到手，老項目就出問題了，不是這里有點小毛病就是那個功能要升級，于是新項目放下，著手改老項目，手上能有三四個項目時，就會忙個不停，改的多了，沒辦法再改了就得重新設計，或是直接說這個功能實現不了。

其實在這個階段的朋友很有潛力的，只要花點心思補習一下自己的技術缺陷，多看看高手的代碼，寫之前想一下，設計一下，自然事半功倍，千萬不要有眼高手低的心態。

真正的高手Nb人物是怎么工作的------------程序員

1.不隨便改變需求

他們不會主觀的改變一些東西，不管是對還是錯，如果要改的話他們會在開會時，或是私下跟你提出來，通過后再改，否則會按需求辦事

2.不寫沒有思想的代碼

在寫功能時會加上一些人性化的功能，比果加個小圖標，加一些驗證，處理一些操作習慣，加加快捷鍵，處理好Tab順序，等這些，不用你說，他們自己會處理好。

3.不寫沒有遠見的代碼

他們在寫代碼時會想，不會是單純的實現功能，他要想，如果別人也要用這個方法怎么辦，以后要改的時候怎么辦，代碼這樣寫是不是合理，是不是會影響性能，然后才會”吝嗇“的出手。

4.不寫不負責任的代碼

我們寫代碼一是為客戶用，二是方便其他人看，不單單是自己維護，要對自己的代碼負責，從自己手上出去的代碼代表的就是自己的臉，代碼不好，人家會“打臉”的。他們不愿意挨打所以他們負責。

高手在編程效率方面可能并不比普通程序員快多少，因為他們會吝嗇自己敲下的每一行代碼。這種“吝嗇”有兩方面的含義，一是項目的架構性和整體性考量，二是從性能和優化的角度進行Coding。其實，這里所映射的是一個開發者的技術視野。

有多位技術專家強調項目執行時的全局觀。面對一個項目，即使是團隊中的普通一員，也要力求從項目整體架構的角度審視開發需求，對各個模塊、接口和通信做最優化的預想和配置。這樣可以從全局審視整個項目的技術布局，預判可能出現的問題。

在確定了整體之后，落實到具體的模塊實現，每一行代碼不但有上下文的考量與規劃，還要具備模塊間的整體布局。這是模塊內的技術視野，比如接口的定義、注釋的可讀性、代碼的執行效率等。當你寫下一行代碼前，要考慮它是否會對整個系統造成影響，是否方便其他接口進行調用，這些都是一個開發高手的“技術潛意識”。

據一些經常帶領入門級開發者的技術經理介紹，多數人只考慮自己所負責的模塊進行開發，缺乏一個全局性的技術視野和對代碼性能苛刻的態度，這樣雖然能按交付日期完成項目，卻對項目質量和開發者的自我提高有很大阻礙。

開發高手是代碼閱讀者。大多數技術專家的代碼閱讀量是普通程序員的百倍，代碼閱讀的時間比寫代碼的時間要長得多。

多數程序員只把程序開發當成一份工作，他們在乎平臺的前景、語言的優劣、報酬的高低；他們不愿為一個技術點反復鉆研，不愿為一個bug精心測試，不愿為自身技術水平的提高多花時間。而開發高手往往具有單純的技術夢想，愿意為技術付出自己全部的時間。