普通的程序員和大神級的程序員的區別，小編來列舉幾點，順便給一些普通程序員一些學習建議，請查收 ~
一、主要問題
1、沒有編程思想
或許很多人覺得很扯，但確實是這樣的。高級程序員在看到一個需求的時候，總是能夠快速在大腦裏生成這個需求在現實生活中的映射。每當產品經理提一個需求的時候，高級程序員首先想到的就是，這個需求需要哪些數據庫上的改動，對現有的邏輯有什麼影響，需要提供多少接口，存在哪些可能的風險，以及需要多久的開發週期。普通程序員拿到需求以後，首先表現的是一臉懵逼，因爲往往產品經理的文檔寫的非常長，有時還難以理解，普通程序員難以提取裏面的關鍵點。所以這時就需要項目經理這種角色，提取需求，然後告訴他，提供什麼接口，對數據庫做什麼修改。
聰明的人在項目經理說完以後，總會自己去對着需求文檔去思考項目經理爲什麼要這麼做，還有一部分人悶着頭就去開發了。很多工作四五年的程序員，工作經驗一大堆，讓他真的說出些什麼，他卻說不出來。不懂得在工作中思考，工作十年也只是一個普通程序員。
2、沒有學習路線
普通程序員在學完基本的知識以後，後續就不知道該學什麼了，沒有一條屬於自己的進階路線。高級程序員不同，他們在學完基本工作知識以後，會思考下一步自己該如何提升，他們會擁有自己的選擇。知識是永無止境的，學完基礎以後，還有自動化部署，還有微服務，大數據，以及各種架構。制定一條屬於自己的學習路線，是非常有必要的。
因此，在這裏我也給大家推薦一個Java的交流學習社區：586446657，裏面不僅可以交流討論，還有大神的學習路線規劃圖以及免費的資料下載，包括Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。相信對於已經工作和遇到技術瓶頸的碼友，在這裏會有你需要的內容。
3、不會用Git
高級程序員的代碼都是通過Git一類的版本控制工具維護的很好，針對不同的功能他們會建立不同的分支，以及測試分支，灰度環境分支，正式環境分支，有的還會建出發佈分支。普通程序員總是喜歡在主分支上面做修改，一旦同時有多人並行開發，或者需要回退分支到某一個功能點的時候，對於他們來說往往都是災難性的存在。普通程序員提交Git還總喜歡用 123 這種提交日誌，高級程序員總會在提交日誌中詳細寫出自己做了哪些修改，方便以後遇到問題的時候查找原因。
4、命名不規範
這是一個很大的問題，普通程序員很喜歡使用拼音或者是拼音加英文的方式來命名。高級程序員哪怕自己英語很差，也懂得使用百度翻譯或者谷歌翻譯來把對應的中文翻譯成英文。這樣做最大的好處就是，別人看到你這個類，或者看到你這個方法和變量的時候，第一時間能夠知道這個東西是幹嘛的。
5、結構不規範
無論是什麼編程語言，無論是面向對象還是面向過程，甚至不分前端和後端。任何一個語言在開發的時候，代碼結構都應該清晰。相同功能，相同模塊的文件應該放在一起，針對不同的處理邏輯建出不同的文件夾或包。重複使用超過三次以上的代碼應該考慮把它寫進一個公共的方法裏，大家都調用這個公共的方法，避免維護太多的重複代碼。這樣當項目發展的很大以後，開發起來也不至於很亂。
6、不知道如何解決BUG
普通程序員看到程序報錯以後，第一時間是懵逼狀態，他們會很慌亂，不知道該如何是好。有的還知道看一下控制檯打印的錯誤信息，來百度一下，但往往這種方式能不能解決問題都看運氣。高級程序員如果做的是一個web程序，報錯以後他們會首先看瀏覽器的控制檯是否發送了對應的請求，如果發送了請求會看瀏覽器的錯誤碼是什麼，是請求超時還是發生了500或者是404的錯誤。然後再針對不同的錯誤碼做出不同的調試方案，如果500的錯誤，報錯日誌明顯就直接找到對應的地點修改，如果報錯信息不明顯就通過開發工具來進行斷點調試，一步一步找到問題。
7、不會用搜索引擎
遇到問題去百度一下是很明智的，但是如果不看報錯的信息盲目的去百度，搜索的結果也只是浪費自己的時間。如果盲目去嘗試搜索到的解決方案，只會讓瞎子變成瘸子。針對這個，大家可以報錯以後看報錯日誌的最後一行，往往報錯最後一行就是錯誤的原因。一般都是英文的，但是並不複雜，往往都是幾個單詞來說明問題，然後指向一個錯誤產生的代碼位置。先看報錯原因，自己思考以後大概明白是什麼原因，不要上來就去拿着最後一行百度。
如果擁有科學上網的能力，可以使用谷歌來進行搜索，效率更高，答案更準確。
還可以有更多選擇：
以上是普通程序員在工作中最容易產生的問題。
二、提升建議
1、培養編程思想
編程思想這個東西，不是說工作的久了就能有的，而是在學習和工作中要去思考。思想思想，肯定要先思而後想，這樣才能擁有思想。建議是大家可以針對項目中一些簡單的功能去思考，如果讓你來從頭開發這個功能，你需要對數據庫進行哪些操作，需要提供什麼接口，需要什麼類型的數據，數據需要進行哪些必要的驗證，數據庫的字段類型以及長度。用筆在紙上把內容都列舉出來，寫完以後再看幾遍，有沒有哪些可以做的更好的地方。然後去看項目裏原來的設計，是不是跟你的類似，如果不如你設計的可以在後面的優化中改進它，如果比你的好，那就去思考別人爲什麼要這麼做。久而久之，遇到複雜的需求也能快速拆分成一個個的小需求，那個時候你離項目經理就不遠了。
2、制定學習路線
因爲大家的方向不同，有的人是前端，有的人是後端，學習的語言也不同。在這裏就針對前端和服務端提一些建議。
前端
前端最重要的其實還是基礎的js，只有把js學好了，才能輕易的理解高級框架的原理。如果現在能夠完成公司的開發任務，建議可以好好學習一下js的基礎課程，弄懂它。然後去看看jquery是如何實現的，jquery只有一個文件，而且代碼並不複雜，當弄懂jquery是如何實現的以後，再看vue這些複雜的框架，也不覺得難以理解了。一個前端程序員初期工資有多高，是看他掌握多少框架。但未來能夠走多遠，是看他內功修煉的是否紮實。
後端
一般無論是大公司還是小公司，服務端的主要工作就是使用一個或多個框架來開發一些接口。所以很多技術大佬總喜歡自嘲自己是一個 CRUD工程師 （增刪改查工程師）。那麼如何讓增刪改查變得更優秀呢，同樣都是增刪改查爲什麼有人8K有人30K。建議是在熟練掌握自己所使用的框架以後，不妨去學習一些項目性能優化方面的知識。比如緩存，比如數據庫性能優化。有人可能會說，緩存有什麼好學的，不就是redis插入一個key，查詢一個key嗎？redis一樣存在很多高級的用法，也同樣存在許多的坑，如果應用不好，輕則數據丟失，重則整個服務器癱瘓。掌握基本的性能優化以後，就可以去研究如何把項目通過容器技術來分離成一個個的小項目。這時就需要學習docker這種技術，隨着docker數量的增多，docker的啓動停止，狀態監測就成了一個比較繁瑣的事情。又需要學習docker的自動化技術。學完這些以後就初步掌握了微服務開發的一些思想，實際上微服務就是在這樣的一個過程中不斷演進而來的。當擁有了自己的知識廣度以後，再去深研框架和語言的底層。
說到這裏我也順便給大家推薦一個Java後端的交流學習社區：586446657，裏面不僅可以交流討論，還有大神的學習路線規劃圖以及免費的資料下載，包括Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。相信對於已經工作和遇到技術瓶頸的碼友，在這裏會有你需要的內容。
有些東西，並非是運維或者是DBA才能做的，而是每個程序員都必須要掌握的，如果什麼事情都依靠運維和DBA，那麼十年以後依然還是CRUD工程師。任何技術，特別是編程相關的，他們最終的本源都是一樣的，都是代碼。所以無論學習數據庫，學習緩存，學習容器，爲的都是增加大家的知識廣度。只有閱盡千帆的人，才能像大海一樣睿智。
最後
願大家都能在編程這條路，越走越遠。