判定壞程序員標准

① 如何確定自己是否適合做程序員

你老婆對你說：「老公，晚上回來買一個西瓜，如果看到西紅柿，就買兩個。」

如果你晚上買了一個西瓜和兩個西紅柿回來的話，說明你不適合當程序員。
如果你晚上只買了兩個西瓜回來的話，說明你適合當程序員，但是
。。。
。。。
。。。
。。。
。。。
。。。
。。。
你應該不會有老婆。

=========華麗麗的分割線===========
你們這群程序員也是夠了，一直在吵應該買幾個西瓜，你們這么吊你們老婆知道嗎？還有很多有經驗的程序猿說應該反復確認用戶需求的，你們確定你們都能找的到老婆？

我聽到需求時心裡運行的代碼如下：
int 到底買點啥 ( ) {
// 所有把大括弧放到這一行的人都去屎！
int 西瓜的數量 = 1;
if (看到了西紅柿) {
// 注意大括弧的位置
西瓜的數量 = 2;
}
return 西瓜的數量;
}
// 尼瑪，為什麼沒有縮進！！！！

那麼什麼時候該買三個西瓜呢？我們重現一下場景：

你老婆對你說：「傻X，晚上回來買一個西瓜，如果看到西紅柿，就再買兩個。這次你要是還買兩個西瓜回來，我就一輩子都不理你了！」
你仔細揣測了一下她的需求，發現了這個關鍵的「再」字！哈哈哈，這種戰鬥力只有5的渣題怎能難倒我這種top coder！你晚上開開心心地買了三個西瓜回來，跪碎了新買的HHKB pro，老婆還是摔門而去，攔都攔不住！

這次你運行的代碼如下：
int 到底買點啥 ( ) {
// 所有把大括弧放到這一行的人都去屎！
int 西瓜的數量 = 1;
if (看到了西紅柿) {
// 注意大括弧的位置
西瓜的數量 += 2;
}
return 西瓜的數量;
}

就讓這三個西瓜陪你過下半輩子吧！！！！

② 如何成為一名合格的程序員

很多人想要成為程序員，在學習編程的過程中，面對各種bug和源源不斷的問題，有時會對自己是否適合編程這一問題產生困擾。

作為一名教授全棧Web開發的教育工作者，我已經帶領很多新手成為了程序員。好消息是，我發現沒有任何人是不能學習編程的。我把它看作是一種基本的人類技能，就像閱讀、寫作和算術一樣，任何人都可以做到。它是我們人類能力的一部分，只是需要學習。

在過去的幾年的教學中，我目睹了不同的學生在學習過程中的斗爭，以及在他們的掙扎中出現的一些共同問題。

下面的列表將幫助你了解你是否喜歡編程

1、缺乏好奇心

如果你對計算機是如何工作的缺乏好奇心，那麼，作為一個程序員，你將永遠不會成功。

學習的一個基本要求是對你所學的東西有積極的興趣。如果你沒有一個對技術好奇的頭腦，你就沒有精力去堅持學習要成為一個成功的程序員所需要的廣博而深入的知識。相比之下，技術的世界就像一個巨大的海洋，裡面充滿了各種有趣的領域、相互聯系的思想和各種可能，它們可以激發人們的想像力。想要潛入這片海洋並發現你所能發現的一切，需要內在的動力。

找到你的好奇心：問問你自己，編程是否真的讓你感興趣？如果沒有興趣，去找你感興趣的東西，以節省時間和精力。但是如果你的答案是感興趣，那麼就強迫自鄭襪己去發現一些你以前沒有注意到的新事物，認識到浩瀚的技術海洋，再往下潛一點。

2、缺乏自主性

如果你不培養自己解決問題的能力，你就永遠不會成為一個成功的程序員。

毫無疑問，要成為一個成功的開發人員，你必須對自己的學習能力充滿信心。這實際上是一項基本的生活技能，如果你年滿18歲，沒有人有義務教你任何東西。這就是現實。當你想學習技術所需的技能時，首先要學會的是，在谷歌中輸入你想要的任何東西並獲取你需要的信息。除此之外，所有編程語言都有文檔和規范，這些文檔和規范對語言的工作方式解釋的非常清楚，它們就像字典一樣。作為一個程序員，最快速、最可靠的學習方法就是簡單地閱讀這些文檔。

當你有問題的時候，在問別人答案和查閱官方文檔之前，強迫自己先搜索一下，節省別人的時間。

3、面對問題缺乏毅力

如果你在遇到問題時輕易放棄，作為一個程序員，你將永遠不會成功。

編程的本質是解決問題，這也是計算機產生的全部原因！每當你開始編寫一個程序時，你總是會遇到一大堆問題。一旦你解決了一個問題，那麼幾乎總是有另一個問題在後面等著你。你在進步，但總是會有新的問題要面對。

這堆問題會讓人望而生畏，令人感到沮喪。如果你覺得程序應該「能用就好」，那麼你就沒有精力堅持下去，因為問題還在繼續出現，它們會一點一點地擊潰你的情緒和決心。從字面上來說，你的工作就是找出程序為什麼不能跑起來。

從我在授課上的經驗來看，通常每個班都有一兩個學生，和其他學生相比，他們似乎更容易遇到更多的問題——通常是非常隨機和模糊的問題。我提醒學生，他們面對的問題越多，學習越深入、越徹底的可能性就越大。如果他們能通過這些問題獲得深刻的理解，他們會很快發現他們變得更加自信了，因為他們面對和解決的問題比普通學生多。

你需要認識到，問題不僅僅只是問題，它實際上也是挑戰。你所面臨和克服的每一個挑戰都能讓你更深入地理解技術，更好地面對新的挑戰，並迅速解決舊的挑戰。

4、解決問題之後沒有成就感

如果你在解決一個問題後沒有興奮感和成就感，作為一個程序員，你將永遠不會成功。

與上一個問題相關的是，你成功地解決了一個問題，卻缺乏「良好的感覺」。當修復bug和問題變成了一個永遠不會結束的事情時，你會失去與克服問題的動力。

當你解決一個問題時，你需要的是多巴胺的釋放。這類似於在電子游戲中完成了一個關卡，或者解決了一個像縱橫字謎或數獨這樣的挑戰。我們都知道，堅持通過一項挑戰，然後最終贏得比賽，一般都會有成就感和興奮感。但是如果你失去了感受這些快樂的能力，或者從一開始就沒有真正有過這些感受，你將無法體驗到編程帶來的快樂。如果你把編程看作是一種磨礪，你只想盡可能容易地得到結果，那麼你永遠不會真正成為一個成功的程序員。

無論何時，當你解決了一個一直在努力解決的問題時，無論這個問題多麼微小，你總是為你的成就感到驕傲。你需要休息一下，祝賀你自己完成了一項出色的工作，讓成功的感覺滲透進你的心裡，為你即將面臨的下一個問題注入活力。

5、無法獨立思考

如果你期望別人為你著想，並且主動看到你自己所在的處境喊純激的細節，你將永遠不會成為一個真正成功的褲脊程序員。

當你在學習新的東西時，很容易感到缺乏知識和經驗，並沒有自己的觀點。主動做事或者說錯話似乎是有風險的。對於錯誤，我們的內心都有一種恐懼感。當對錯誤的恐懼抑制了你的探索和好奇心時，你會扼殺開發真正知識、從經驗中獲得的知識和「失敗」的能力。當你需要依靠「權威」的觀點、一個受歡迎的博客、一個最佳實踐或「教科書」的答案時，那麼你就沒有真正地整合編程的知識。你需要對什麼有效，什麼無效形成自己的觀點。你需要理解為什麼你認為你的解決方案有效，以及使用這個方案有什麼好處。你需要建立一個微妙的視角，超越那些顯而易見的東西。你需要能夠「證實」你的立場。

為自己著想。通過你的經驗和批判性思維技巧，發展出你自己的思想體系。做出合理的猜測，堅定立場，並願意隨著新信息的出現而改變立場。

6、僵化、狹隘、混亂的思維

如果你的思維僵化，並且難以保持代碼的條理化，那麼你將永遠無法成為一名真正成功的程序員。

我有時在學生中看到兩個極端。第一種是僵化和狹隘的思維方式。擁有這種態度的人拒絕幫助，盡管會有反饋，但不會有改變。他們看事情只從一個角度看，別人給的建議被忽略。

我看到的第二個極端是思維混亂。學生們似乎使事情變得更加復雜，他們的代碼雜亂無章，難以理解。他們過度思考問題，寫100行代碼，而其中只有10行是有用的。

當這兩種心態結合在一起時，結果就是一種用蠻力的方法去設計程序。我們需要的是回顧解決方案，重新評估它，放棄最初的方法，並重新組織方法。

無法看到其他可能性或無法反思反饋會抑製成長的能力。思維雜亂無章會減慢你的成長速度，阻止你看到那些原本顯而易見的模式。你的工作質量也會下降。

自我反省。你需要退後一步，看看你是接觸的事物的大局是什麼樣子的。你要怎樣才能做得更好？你能做些什麼讓你的生活更輕松嗎？你需要什麼來幫助你？

7、需要「正確」的答案，而不是識別一系列「好」和「壞」的答案的方法

如果你認為編程的最終目標是找到正確的解決方案，而不是一系列解決方案，那麼作為一個程序員，你將永遠不會真正成功。

當開始學習技能或編程時，學生往往想知道他們所做的是否「正確」，而答案總是「視情況而定」。

計算機科學是一門評估權衡的科學。在不同的環境下，哪條路更好，這完全取決於所處的環境和目標。當你把編程看作是一個有正確答案或錯誤答案的測試時，你就失去了對全局的認識，放棄了你的創造力。任何答案都可以是「正確的」，前提是你能根據具體情況證明這一點。現實情況是，編程更像是寫詩或寫短篇小說（如果程序很大，則可能是小說）。在你的代碼中可以看到一種美學和美麗，這些東西有時只有你和其他程序員能夠識別出來。你決定解決方案的原因，以及你對答案的設想，比「正確的方式」或「錯誤的方式」更重要。擁有一個藝術家的頭腦可以讓你編的程序具有選擇和可能性，而不是認為只有一種處理方式。這就是編程的美——有很多方法可以解決問題，考慮不同的可能性，然後決定哪種方法最適合當前的情況。

創造性很重要。你要認識到，解決問題的方法有很多種，通過經驗和積累，你會對哪些解決方案比其他解決方案感覺更好產生細微的理解。縱觀全局，想像不同的可能性，相信你的直覺，你會得到更滿意、更好的解決方案

如果你對學習編程感興趣，我鼓勵你開始這段旅程。記住提到的七條，並開始學習、探索在線資源，這些資源可以讓你快速學習。你不會後悔的！

合格程序員，對於一種計算機程序設計語言，我們將其分為語法、語義、語用三個層面。僅僅掌握語法是不夠的，不算學好。但是很多人，在履歷上寫自己掌握（甚至精通）了某種語言，其實就是解了語法，會寫簡單的程序而已。這就是為什麼我們行業特別不喜歡「精通」這個詞的原因。

現代軟體開發，規模都比較大，不是寫個HelloWorld那麼簡單，也不可能每個項目每件事都從頭開始造輪子，我們都是站在前輩、同行們的肩膀上工作的。也就是說，語言之外，還有「庫」這個東西需要掌握，不然就寸步難行。庫有語言級別支持的BuildIn的庫，比如JAVA裡面的util、concurrent，CPP的IOSTREAM、STL等等；更多的更豐富的還有第三方提供的庫，比如JDBC、Servlet、EJB的implementations等等。這些東西掌握了，幹活兒才可能得心應手，不然寸步難行。

比Libaray更高層一些的，是Framework。框架的作用在於，將某一方面開發的BestPractices搞到一起，給你提供一個更易用的、不關注底層的腳手架。比如做企業應用的，SpringFramework是標配了；訪問數據，Hibernate或者MyBatis也離不開，很少直接用JDBC去幹活的了；做WEB的，各種MVCFramework起碼得掌握一兩個（springmvcorstruts2?）；做網路的，Netty，MINA怎麼也得掌握一個......總而言之，框架是繞不過去的一個門檻。

然後呢，就是環境、輔助工具。應用伺服器，怎麼也得會調試配置那麼兩個吧。TOMCAT是入門標配，JBOSS，WEBLOGIC之類，起碼要弄得跑得起來；針對不同應用場景，還要會選擇。開發/管理工具，ECLIPSE是標配、GIT和SVN起碼要搞熟一款；其它比如單元測試工具、Build工具、測試覆蓋率、CodeReview這些插件...也得知道怎麼用。

最後，通用的，計算機科學的基礎，不說多扎實，至少不能一竅不通。說起來就那幾大件，操作系統、數據結構&演算法、編譯原理、體系結構。要懂一點點，你才知道你編的程序是怎麼run起來的，哪兒可能存在效率問題性能瓶頸，除了問題知道怎麼debug。如果僅僅把計算機當作一個黑盒子，那也不算學好了。

最最後，還有一樣，就是你要訓練一下，快速理解領域知識的能力。你參與做一個項目，你懂的只是上面這些專業知識，但並不懂客戶的行業知識。如何盡快地理解業務，並用你手頭的工具實現業務邏輯，這點對程序員而言是非常重要的，否則你做的東西客戶總不滿意，GET不到重點，很麻煩。

我覺得這是一個合格的程序員的基本要求。你看，我並沒要求你懂需求工程、懂項目管理、懂架構設計、懂很多演算法、模式，甚至更深的專業知識。

③ 如何辨別一個程序員水平的高低

1.自己介紹項目，看對項目的提煉總結能力（也是抽象能力）；
2.自己印象最深的bug，可以知道大概技術深度；
3.設計模式提問，看有沒有學習方法；
4.語法基礎問題，多線，分布，安全等問題，看知識面廣度；
5.智力問題，看反應能力，分析問題思路等
上述五步基本可知是否是一個好程序猿

計科專業從事軟體開發十幾年了，主要在瀏覽器內核領域研究的比較多，最近在研究伺服器後台方向，辨別程序員水平高低主要看做出了什麼產品，如同現在的程序員主要是項目經驗，簡歷上寫的一堆項目經驗都是面試的時候主要提及的問題。經常在面試中會問兩個關鍵點：一個是做過什麼項目；一個是在項目組中承擔什麼職務，畢竟參與過和做的多少程度是不一樣的，這些都是可以通過一些具體的細節檢測出來，問題越具體越是容易看出水準，具體的東西不是能夠編造出來的。

有很多技術公司直接不通過筆試，僅僅通過簡單的面試就確定工資水準了，最簡單的測試程序員水平的直接用筆試的方式，筆試可以把一些細節量化，盡量的細節化也是能測試出程序員基本功的，但這種基本用來測試初級程序員的，很多高級的程序員看到有筆試直接就抬腿走人了，因為有些程序員在一個方向做的時間太長了，很多基本功都忘得差不多了，所以筆試可能不過關，現實中很多程序員筆試不過關，面試還可以，也一樣可以做項目說的就是這類人，起碼這算是非常優秀的程序員。

有很多公司採用谷歌的方式，直接採用上機寫代碼的方式檢驗程序員水平，這種方式比較直接，但在現實中可能消耗的時間以及面試官的精力，目前只有極少數的公司用這種方式，國外的公司用這種方式比較多，這種看基本功非常有效。通過代碼可以看到編碼習慣以及演算法的設計上，都能直接看的出來。

普通的程序員直接看項目的經驗，高級的直接看做過的產品，特別是產品主要設計人員，這就是程序員內心的自豪感，畢竟作為一個程序員起碼要有自己設計開發的產品，也算是不白做一個程序員，在程序員的職業經歷中如果能經歷過一個產品從開始設計的初稿到最後推向市場，如果是完整的經歷，將是一種巨大的財富，只要經歷過一次都會對產品設計有一個比較層次的認識，這種能力需要靠直接的面試語言表達來展示出來，談下對產品的認識以及產品穩定性性能等方面的總結，能到這個層面起碼是高級軟體工程師的級別。

當然有些程序員內在的東西不是靠語言或者寫代碼看出來的，因為一個優秀的程序員不僅僅是代碼能力以及框架能力，還有幾個非常重要的能力

程序員的能力表面是可以直接展示出來，但很多內在需要是需要時間的磨合才能了解，人就才能見人心，而且很多優秀的程序員是培養出來的，能夠長時間在一起的隊友都是時間長了磨練出來的。

希望能夠幫到你。

自認為不是一個好的面試官，因為我認為在這么短的時間內，准確地衡量出來程序員水平的高低是有比較大的難度的，並且我有多次看走眼的時候，面試的時候覺得能力還不錯，但是入職工作了一段時間之後，編程能力不忍直視。

工作之後接觸一段時間，我會從這么幾個方面觀察他們，以判斷技術能力的高低和發展潛力。

能不能把開發任務按時按質量地完成，當然是最主要的衡量標准了:

在開發過程中，難免會遇到沒有見過的問題，有些程序員遇到問題無從下手，而優秀的程序員，自有一套解決問題的方法。

有人會認為，程序員的主要工作就是敲代碼，上班大部分時候都是在敲代碼，其實並不是這樣：

好的程序員，相同的問題不會犯第二次，差的程序員，總會在一個問題上栽跟頭：

不請自來，一介碼農路過，留下些看法。

程序員主要是有四種綜合能力，也就是debug 能力、 performance分析、 保護性編程和 投入產出比。

在這里不能說一棒子打死，至少對於很多人來說，能獨立完成是沒什麼問題的，有的是因為對業務熟悉，有的是真的基礎扎實。但怎麼說呢，程序員和瀏覽器打交道是最多的，現在這個互聯網時代，遇到的大部分問題網路都是可以解決的，也就是普通程序員 + 網路 = 超級程序員。 但很多人也沒明白具體的原理，甚至都是這個項目抄抄那個項目抄抄的，久而久之雖然解決了平時的業務，但進步的空間卻很少，甚至止步不前，寫出來的代碼也可能存在很多坑，所以，僅僅能獨立完成任務的話，離高手還有比較遠的一段距離。

也就是結合我們一開始列舉的那四個能力進行判斷。不同級別的程序員，在那綜合能力面前，強弱也是不同的。例如在奔潰的或者其他性能調優問題上，即使是面對大量復雜的代碼，在信息不全的時候也會一步步的分析，抽絲剝繭縮小范圍，最終定位根本原因

，並且最終給出一個好的方案。

當然還有看他摘了帽子是否禿頂這樣的笑話，就再不贅述了。

第一階段（黃金）:會用編程語言實現需求，比如現在的業務系統，都會找一些會搬代碼的人來拼工作量，也就是能自己獨立基於搭好的框架實現crud常規操作。

第二階段（鉑金）:除了crud，還會有一些自己踩過坑的經驗，知道如何處理一些常見問題，或者可以基於搜索引擎快速解決一些異常情況。

第三階段（鑽石）:能解決一些疑難雜症和會通過debug部分源碼類庫查看到這些疑難雜症是如何引發的，並通過編碼解決這些問題，還能進行一些局部的性能優化，類似某個系統介面緩慢可以單獨去優化。

第四階段（星耀）:會基於整個系統進行設計和規劃，根據業務特性選擇合適的框架，從源頭控制開發遇到問題的頻率，可以自主的搭建框架並完善機制，了解各個組件工作原理。

第五階段（王者）:小說裡面總是說練武功的永遠比不過創造武功的，同樣的道理，用框架的也往往不如寫框架的，所以寫框架的這類人單獨分層。

第六階段（榮耀）:其實這個階段不應該列入進來，因為這類人往往不編碼的，只是給出思想；像Hadoop這種框架就是基於人家發表的一些論文（bigdata)進行編碼實現的，這類人注重的是思想和演算法，區塊鏈，大數據，雲計算等等概念的創造和理論的支撐是這類人提出來的，這些人才是真正影響行業走向的人。

程序員的水平高低，不是靠語言或外在表現就能看出來的，不是看他會多少技術、參加過多少項目、寫了多少博客，而是看他在實際業務場景中解決問題的能力，尤其是面對一些特別復雜的問題，或在高強度、高壓工作狀態下解決問題的能力與態度。

技術可以通過學習掌握，但是解決問題、定位問題的能力卻不是一蹴而就。大家可能會說，「解決問題的能力」這個太寬泛了吧，可以更具象化嗎，有具體的測量方法嗎？簡單整理了以下幾點供參考。

會寫出滿足需求的代碼，早就不是評判程序員水平的標准了。代碼編寫既要滿足業務需求，同時還要考慮後續的軟體維護，說得通俗些，既要自己爽，也要別人爽。一個優秀的程序員，會致力於寫出更簡單、更效率、可讀性強、擴展性強的程序代碼。

程序員在日常工作中，需要理解各式各樣的業務需求，所以這就需要程序員具備一定的邏輯思維能力。可以說，邏輯思維是程序員的靈魂，因為每一行代碼都是程序員邏輯的體現。

項目著急上線，發布時出現問題？

業務高峰時段，系統宕機了？

業務催、運營催、用戶催、老闆催！

各種形態的bug，各種著急的心情，背後無數支眼睛盯得內心慌慌......

這些都是一位合格程序員所需要面對的日常。不同的程序員，在解決問題的方法、效率、質量等方面，都各有千秋。一個經驗豐富的程序員，能夠扛住各方壓力，在復雜條件下找到核心問題，通過抽絲剝繭的分析來找到產生問題的原因，並快速進行應對處理，事後及時復盤總結，減少同類問題出現的概率。

隨之互聯網的發展，越來越多的人湧入程序員這個賽道，競爭日益激烈，加之新技術層出不窮，更新迭代快，程序員所使用的語言、框架、模式都會發生天翻地覆的變化。如果不主動學習，你很快就會被落伍淘汰。

這種其實在面試過程中能體現出來，溝通主要是技術溝通，以及和客戶之間的溝通，所有技術都不是閉門造車就能搞定的，溝通能讓事情推進起來更加順暢，包括和產品經理之間的流暢的溝通也顯得非常重要。程序員的能力表面是可以直接展示出來，但很多內在需要是需要時間的磨合才能了解，人就才能見人心，而且很多優秀的程序員是培養出來的，能夠長時間在一起的隊友都是時間長了磨練出來的。

線上出bug了，第一時間響應、處理；

團隊項目進度緊張、人手緊缺，主動補位；

又或者，在項目推進過程中如果只是關心自己模塊內容，對於整個項目置之不理，只守著自己的一畝三分地。

隨著時間軸的拉長，你會發現，有此f技術能力不是最好的，甚至不如你的小夥伴，最後做到了技術主管或經理、甚至更高職位，這裡面除了技術實力，還有一個叫「責任心」的東西。

結束語

判斷一個程序員的水平高低，核心是其解決問題的能力，而解決問題的能力養成，需要扎實的底層基礎來支撐，要綜合其代碼質量、項目經驗、框架能力、邏輯思維等等多方面，不能單看某一方面。

而對於1-6歲的程序員來說，想要成為一個高級程序員，變得越來越優秀，唯有持之以恆去學習、積累、實踐、修煉。

----end----

一：50歲的時候，頭發還是黑色的濃密的。

二：賺到的錢能保證家人快樂的生活。

三：當公司不要你的時候能成功轉型。

其他的例如編程經驗、寫代碼厲害啊什麼的根本不值一提。

這就是程序員的面試嘛 :-)

（1）是否能熟練使用所用編程語言的主要功能；

（2）是否知道用合適的數據結構解決問題；

（3）是否知道基本的演算法，並且用這些演算法解決問題；

（4）只看少量代碼的話，從變數命名和程序結構一般能夠判斷是否是新手；

（5）給出具體問題，能夠用程序解決，能考慮到所有的邊界條件；

（6）考慮程序的可擴展性，可維護性；

再往高一點走，就需要

（7）面對模糊的問題能夠分析並且找到細節和具體的需求；

（8）知道利用已有的庫，架構和工具等來解決新的問題，而不是什麼都自己實現；

（9）能發現並改進已有程序中的瓶頸；

（10）對整個大項目的程序架構有很清晰的了解，知道相互之間的依賴，以及知道為什麼採用這樣就架構；

（11）給一個大的項目，能夠對整個項目的程序架構和組件進行合理的設計，考慮並行性，低延遲，大數據量等各種需求和應對方式。

帶領團隊已多年，項目數十個，對判別程序員水平的高低，我有自己的看法，歡迎大家一起交流。

1.代碼質量。

優質的代碼，首先是經得起考驗。靜態分析工具過一遍，無錯誤，無警告。當然警告部分需要人工重審，因為靜態分析工具不一定完全正確。過了這一關，重要的還須過測試關，少Bug或無Bug的代碼，才是好代碼。優質的代碼帶有技術氣質和藝術氣質。閱讀起來，有一種賞心悅目的快感，即工整美觀，干凈利落，又蘊含著理論常識，運用技巧，精準到位。

2.表達能力。

3.文檔能力。

文檔形式包括但不限於PPT，文字，圖表，音視頻。文檔內容包括但不限於API說明，工具手冊，項目事項，技術論述，陷阱總結，方案展示，指導手冊。文檔要求必須是滿足公司或部門的規范和格式，否則五花八門的，不利於交流和傳承。

以上3點，是我量化判斷程序員水平的標准，僅供參考。相比水平，其實我更看重程序員的態度，執行力，時間觀念，自學力等等，也是很重要的團隊作戰能力，也可以說是程序員水平的考量吧。

謝謝大家。

④ 程序員代碼質量的好壞是如何區別的

現在的程序設計是一個系統的過程，程序員代碼質量的高低往往也與他所處的團隊有較大的關系，也就是說頂層的設計與代碼質量有直接的關系。所以說優秀的團隊往往都是優秀的代碼，但是普通的團隊往往很難寫出優秀的代碼。
代碼的編寫大致上經歷幾個步驟，第一個步驟是頂層設計（架構師）。
頂層設計包括軟體架構設計、技術方案等內容，落實到代碼上往往就是大量介面的定義。好的設計需要考慮三方面因素，分別是結構性（模塊化）、完整性、擴展性，當然還需要考慮可移植性，通常結構性好的代碼移植性也會比較不錯。
第二步是核心代碼的實現（研發級程序員）。
有的團隊也把這部分稱作為「容器」開發，簡單的說就是功能性平台開發，目的是實現平台級API。這部分代碼的開發是整個軟體開發的核心部分，承擔這部分開發任務的程序員往往就是我們所說的研發級程序員。研發級程序員代碼質量的衡量標准主要在演算法設計與實現上，性能指標是考核的重要因素，另外還要考慮穩定性和完整性等核心因素。
第三步是功能編寫（應用級程序員）。
功能編寫簡單的說就是完成具體的業務邏輯實現，需要調用平台提供的API完成具體的功能。這部分程序員占據了程序員群體的大部分比例，也就是通常所說的應用級程序員。應用級程序員的代碼質量主要從代碼編寫結構上來看，比如是否有標準的打包、命名、注釋，以及代碼整體結構是否清晰，邏輯結構是否清晰等方面。
往往程序員代碼的質量會隨著編程經驗的提高而不斷得到提高。
我做軟體開發多年，目前的主要研究方向是大數據和人工智慧，也在帶大數據方向的研究生，我會陸續在頭條上寫一些關於大數據方面的文章，感興趣的朋友可以關注我的頭條號，相信一定會有所收獲。
如果有大數據方面的問題，也可以咨詢我，
謝謝！

⑤ 根據做項目的多少判斷程序員的水準合理嗎為什麼呢

根據做項目的多少判斷程序員的水準合理嗎？為什麼呢？程序員的水平，不是通過語言或外部表現就能看到的，不是看有多少技術，參與了多少項目，他會寫多少博客，而是看他在實際業務場景中解決問題的能力，尤其是面對一些特殊復雜的問題，或在高強度和高壓工作條件下解決問題的能力和態度。能夠編寫滿足需求的代碼不再是評判程序員的標准。

一個經驗豐富的程序員能夠承受來自各個方面的壓力，在復雜條件下找到核心問題，通過深入分析找到問題的原因，並迅速處理。經過及時的回顧和總結，減少出現類似問題的概率。隨著互聯網的發展，越來越多的人湧向程序員的軌道，競爭越來越激烈，新技術層出不窮，更新和迭代速度很快，程序員使用的語言、框架和模式將發生巨大的變化。

如果你不主動學習，你可能很快就會過時。在日常工作中，程序員往往希望將業務、產品、運營，甚至老闆作為對接交換需求和技術項目來連接和配合內部交換等，而流暢的溝通可以使事情推得更加順暢高效，溝通或信息不對稱，可能會導致項目啟動時出現相反的情況（不要相信，這種事情真的發生過）。判斷一個程序員的水平，核心是他解決問題的能力，而解決問題的能力需要堅實的基礎支撐，要綜合代碼質量、項目經驗、框架能力、邏輯思維等方面，而不僅僅是一個方面。

⑥ 程序員有哪些常見的壞習慣

好的程序員炫耀代碼，不好的程序員炫耀工具，自覺用VIM，EMACS的用Eclipse，VS的高級，喜歡問怎麼辦而不是為什麼。