普通的程式設計師和大神級的程式設計師的區別，小編來列舉幾點，順便給一些普通程式設計師一些學習建議，請查收 ~

一、主要問題

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工程師。任何技術，特別是程式設計相關的，他們最終的本源都是一樣的，都是程式碼。所以無論學習資料庫，學習快取，學習容器，為的都是增加大家的知識廣度。只有閱盡千帆的人，才能像大海一樣睿智。

最後

願大家都能在程式設計這條路，越走越遠。