很多人也會有這種疑惑，尤其是入行好幾年了還是個底層人員的小夥伴，今天就告訴你，你如何晉級爲高級程序員。同時也反思下自己還有哪些不足。
主要是分析初級程序員愛犯的錯誤有哪些？
一、 命名不規範
命名很隨意，當時寫代碼特別High，什麼奇奇怪怪的命名都有的：xiaonaigou,xxxx,j1,jl,llst.
完全意識不到全名規範的價值和意義。不過這也可能是沒有養成好的工作習慣的原因。尤其是一些年紀偏小的程序員會有這個問題。
二 、日誌不規範
日誌？那是什麼鬼東西，能喫麼？
曾經有一個從文思海輝出來的小夥伴，三年後端工程師經驗，出了問題不知道怎麼解決。
只好重啓。
找我來協助，問他，怎麼錯了？
不知道。
日誌呢？
沒有。
暈，那怎麼解決問題，神仙也搞不定啊。
後來才知道，他們解決問題都是本地改代碼然後直接部署，重新訪問看錯誤消失沒，沒有消失就繼續在本地改源碼。
我能說我弟後來面試文思海輝，我把他吐槽的不要不要的麼
三 、拒絕寫接口和假數據
一個菜雞不可怕，可怕的是菜雞遇到菜雞。曾經有一個項目中的兩個菜雞，一個前端一個後端，他們很歡快的調接口，根本不寫文檔 ，兩個人效率特別高。
直到有一天，發現項目可能做不完了，需要另外兩個前端菜雞協助一下。
新來的兩個菜雞要獲取後端的數據，不知道接口的Url地址，不知道Get還是Post，不知道發送的參數和返回值。就這樣寫！
我壓根沒想到可以這麼寫代碼，兩個菜雞很開心！拍手稱快：通了，通了，通了！
我說你們通什麼呢？他們說接口終於通了！原來他們兩個參考之間的頁面，硬生生的一次一次不停的嘗試，就這樣把接口猜出來了！
這就是編程的樂趣嗎？
還有不寫假數據。曾經有一個馬姓小哥，對趙姓小哥信誓旦旦的說：3天，給我3天時間 ，我把真數據給你。
於是趙姓小哥信以爲真。就這樣，3天又3天，3天又3天，3天又3天，3天又3天，3天又3天。
整整一個半月，趙姓小哥都沒有拿到全部的數據！
四、不寫單元測試
確切來說，是不按TDD的方式開發。在現在IDE這麼強大的情況下，先寫單元測試的習慣，不僅僅是代碼的嚴謹性，也是效率的代名詞啊。
可是很多菜雞理解不了單元測試的價值，沒關係，等到代碼重構，需求變更的時候，就哭都哭不出來了！
好的單元測試，你的邏輯必然會清楚。
五 、先集成，再測試，再放棄
。
很多時候，菜雞在引入第三方的庫，框架，接口或者是服務的時候，最喜歡的事情就是直接和自己原有的代碼集成在一起。
結果 是什麼呢？突然間不能用了，跑不起來了，不知道問題出在哪了，根本分不清倒底是第三方的問題還是自己的問題。
好的方法是什麼？先跑通官方提供的Demo，再想辦法一點一點加上自己的業務。
六 、理不清楚邏輯，邊做邊猜
前端在這裏的問題特別多，做支付，不清楚支付的流程，分不清楚定義，總以爲前端就是接口處理好數據展示好拉倒。
很多菜雞都會有這種習慣，這樣不好，先把邏輯處理好，弄清楚流程，再去動手纔好。
七 、不做方案
不做方案代表什麼含義呢？就是完全憑直覺行走啊。
跟閉上眼逛窯子一樣。
寫代碼的好習慣應該是先在腦袋裏把所有的需求細節過一遍，實現細節拿出來。
上個月就有一個張姓小菜雞，做一個匿名評論的功能。
基本上沒有什麼經驗，腦子也不好使，給出的方式是什麼你們猜得到麼？
用戶刷新一次就往用戶表裏插入一條數據，密碼默認暱稱隨機。
不多說了都是淚，我見過太多讓人目瞪狗呆的方案了，看着滿屏的代碼，你怎麼幫他調錯調優，最好的方式就是全部重寫。
做方案的好處太多了。
八、不關注性能
不關注性能也是新人很容易犯的錯。什麼是性能呢。對後端來說就是TPS和響應時間，對前端來說就是響應時間。
很多新人程序員的習慣就是把東西做出來，然後再優化。
最後就是東西做出來了，優化留給別人了。
對性能的關注也是晉升中級程序員最關鍵的技能點。在寫代碼的時候，有經驗的工程師已經知道了這個方法這個函數這個功能點的性能怎麼樣，瓶頸在哪裏。
九、 害怕重構
“程序員最大的勇氣就是看自己三個月之前寫的代碼。”
其實重構並不應該是在幾個月之後重構，最好的方式是實時重構。寫一天代碼，70%的時間都放到重構上都不過份。
而新人呢，磕磕跘跘的完成一個功能，就跟多米諾骨牌做成的大黃蜂一樣，你敢動一下他的代碼試試？他會跟你拼命。
你讓他自己動一行代碼試試？
不重構在某種程度上也意味着你的代碼實現無法重塑。
十、 做出來就好，不考慮優雅的方案
有個詞叫做最佳實踐，其實編碼規範和最佳實踐，是編程功底的重要體現。
優雅方案可以認爲是最佳實踐的升級版，它和上面說到的不斷的重構是相輔相成的。
不好的方案是什麼呢？硬編碼居多，沒有可擴展性，用很醜陋的方式完成了功能。
上次他們去做了一個關於試聽課的方案，一個人能試聽多少節課，正常的邏輯應該是在用戶的表裏加一個字段來表示。
需求是寫着邀請幾個人，可以試聽多少節課，所以他們判斷試聽多少節課就直接在通過邀請人的表裏查詢去做。
完全沒考慮到以後如果我變換了試聽課的判斷條件怎麼辦？
實際上這是應該拆解成兩部分，一個是試聽課的產生條件，這是一個獨立的模塊，加一個是試聽課的確認。
像這種例子太多了，也和不做方案，不考慮擴展性有關係。就是接下來要說的。
十一、不考慮未來需求的變化
工程師的水準，其實可以分成以下幾個階段（馬丹我找不到之前在哪個答案裏寫過了）：
面向功能編程
面向性能編程
面向未來編程
工程師拿到需求的第一件事，應該聚集在以下幾個問題：
第一 哪些需求是我之前完成過的
第二 哪些需求是有可能變化的
第三 有幾種方案，分別支持什麼樣的需求變化
但是差一點的程序員就考慮不到那麼遠，一個是對業務不熟悉，判斷不出來哪些需求可能會產生變化，一個是對可選的方案掌握的不多，根本就沒有什麼可選的餘地，還有就是沒有這種思維習慣，分不清楚哪些是現在要完成的，哪些是未來可能會支持或者是變動的。
十二、遇到問題的時候不會試錯
這也是新手常見的問題。很多時候新人會遇到問題，解決不了，去找一個有經驗的工程師，這個有經驗的工程師呢，大概也未曾遇到這種情況，但是他解決問題的思路清楚啊。
一會兒試試這個，一會兒刪刪那段代碼，很快就跑通了。
解決問題是一個很見功底的技術點，而且是有很多方法論的，之前總結過一些，簡單列舉過來：
1.尋找正確的代碼
2.理清楚正確的執行順序
3.重現錯誤
4.最小化錯誤產生的場景
5.修改代碼到一個已知的錯誤類型
等等等。
解決問題就是一個分析推理的過程，而在這裏呢，背後的功底就是你知道很多哪些是肯定不會錯的小公理，然後再挨個去定位可能產生錯誤的環節，分解流程是最基礎的工作。
十三、不會寫僞代碼
僞代碼是什麼呢？就是自然語言啊。其實編程只有三種邏輯控制塊，順序，循環，判斷。
所以你只要用自然語言來描述出來，先做什麼，再做什麼，什麼時候循環，什麼時候判斷，
代碼寫出來的問題就不大。
這是一個先寫僞代碼再寫細節的過程。你不要上來就開始平鋪寫代碼（我之前講過優雅代碼之道，有興趣的可以加羣聽一下，重點講了怎麼寫出來優雅代碼）。
平鋪代碼是最菜的方式，好的代碼是有結構的，有不同的抽像層級。
第一步，幹嘛。
第二步，幹嘛。
第三步，幹嘛。
先把這個列清楚，這是僞代碼的第一級。
然後變成註釋，這是第二級。
刪掉註釋變成函數名，這是第三級。
所以說，好的程序員寫代碼是不需要註釋的，不是說讓你把註釋刪掉，而是讓你完成這三步昇華的過程。
寫的好的代碼，命名規範，你看到的真的是一首詩， 是一種編程語言，是在用語言來描述一件功能的完成，這種編程藝術的工業感很爽快，你看那些不爽的代碼，簡直了。。
十四、不做數據量的預估
後端工程師在前期經常會忽視數據量的大小，沒有影成一個好的習慣。
寫代碼只注重功能，沒有一個關於數據量的概念。
這個地方其實還和性能是一致的，在性能上，前後端並沒有太大的差別。
推薦的做法是，程序員要對數據很敏感，後端要知道每一個表的規模可能會有多大，當前的系統能支持的數據庫表的大小是多大，而前後端都需要知道每一個操作，都分成了哪幾個步驟，每一個步驟花費的時間是多少，大概佔用的內存是什麼樣的。
做到這一點其實並不難，難的是養成這種習慣，初級工程師眼裏看的是功能和代碼，中級工程師眼裏看到的是數據和時間。