一、主要問題

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的自動化技術。學完這些以后就初步掌握了微服務開發的一些思想，實際上微服務就是在這樣的一個過程中不斷演進而來的。當擁有了自己的知識廣度以后，再去深研框架和語言的底層。

有些東西，并非是運維或者是DBA才能做的，而是每個程序員都必須要掌握的，如果什么事情都依靠運維和DBA，那么十年以后依然還是CRUD工程師。任何技術，特別是編程相關的，他們最終的本源都是一樣的，都是代碼。所以無論學習數據庫，學習緩存，學習容器，為的都是增加大家的知識廣度。只有閱盡千帆的人，才能像大海一樣睿智。

最后

愿大家都能在編程這條路，越走越遠。