身為程序員，難免會犯錯，小錯不可怕，怕的是有錯不改，形成了不好的習慣。今兒個咱們就來聊聊初級程序員必犯的10大錯誤，說是必犯，多少有些誇張，但是確實是我在教學工作中，發現的一些問題。在此總結提出，以饗讀者。
1 命名不規範
2 日誌不規範
3 拒絕寫接口和假數據
4 不寫單元測試
5 盲目集成
6 邏輯不清
7 不做方案
8 不關注性能
9 害怕重構
10 做出來就好，不考慮優雅的方案
一 命名不規範
命名很隨意，當時寫代碼特別High，什麼奇奇怪怪的命名都有的：xiaonaigou,xxxx,j1,jl,llst.
完全意識不到全名規範的價值和意義。
二 日誌不規範
日誌？那是什麼鬼東西，能吃麼？
曾經有一個從文思海輝出來的小夥伴，三年後端工程師經驗，出了問題不知道怎麼解決。
只好重啟。
找我來協助，問他，怎麼錯了？
不知道。
日誌呢？
沒有。
暈，那怎麼解決問題，神仙也搞不定啊。
後來才知道，他們解決問題都是本地改代碼然後直接部署，重新訪問看錯誤消失沒，沒有消失就繼續在本地改源碼。
三 拒絕寫接口和假數據
一個菜雞不可怕，可怕的是菜雞遇到菜雞。曾經有一個項目中的兩個菜雞，一個前端一個後端，他們很歡快的調接口，根本不寫文檔 ，兩個人效率特別高。
直到有一天，發現項目可能做不完了，需要另外兩個前端菜雞協助一下。
新來的兩個菜雞要獲取後端的數據，不知道接口的Url地址，不知道Get還是Post，不知道發送的參數和返回值。就這樣寫！
我壓根沒想到可以這麼寫代碼，兩個菜雞很開心！拍手稱快：通了，通了，通了！
我說你們通什麼呢？他們說接口終於通了！原來他們兩個參考之間的頁面，硬生生的一次一次不停的嘗試，就這樣把接口猜出來了！
這就是編程的樂趣嗎？
還有不寫假數據。曾經有一個馬姓小哥，對趙姓小哥信誓旦旦的說：3天，給我3天時間 ，我把真數據給你。
於是趙姓小哥信以為真。就這樣，3天又3天，3天又3天，3天又3天，3天又3天，3天又3天。
整整一個半月，趙姓小哥都沒有拿到全部的數據！
四 不寫單元測試
確切來說，是不按TDD的方式開發。在現在IDE這麼強大的情況下，先寫單元測試的習慣，不僅僅是代碼的嚴謹性，也是效率的代名詞啊。
可是很多菜雞理解不了單元測試的價值，沒關係，等到代碼重構，需求變更的時候，就哭都哭不出來了！
好的單元測試，你的邏輯必然會清楚。
五 先集成，再測試，再放棄。
很多時候，菜雞在引入第三方的庫，框架，接口或者是服務的時候，最喜歡的事情就是直接和自己原有的代碼集成在一起。
結果 是什麼呢？突然間不能用了，跑不起來了，不知道問題出在哪了，根本分不清倒底是第三方的問題還是自己的問題。
好的方法是什麼？先跑通官方提供的Demo，再想辦法一點一點加上自己的業務。
六 理不清楚邏輯，邊做邊猜
前端在這裡的問題特別多，做支付，不清楚支付的流程，分不清楚定義，總以為前端就是接口處理好數據展示好拉倒。
很多菜雞都會有這種習慣，這樣不好，先把邏輯處理好，弄清楚流程，再去動手才好。
七 不做方案
不做方案代表什麼含義呢？就是完全憑直覺行走啊。
跟閉上眼逛窯子一樣。
寫代碼的好習慣應該是先在腦袋裡把所有的需求細節過一遍，實現細節拿出來。
上個月就有一個張姓小菜雞，做一個匿名評論的功能。
基本上沒有什麼經驗，腦子也不好使，給出的方式是什麼你們猜得到麼？
用戶刷新一次就往用戶表裡插入一條數據，密碼默認暱稱隨機。
不多說了都是淚，我見過太多讓人目瞪狗呆的方案了，看著滿屏的代碼，你怎麼幫他調錯調優，最好的方式就是全部重寫。
做方案的好處太多了。
8 不關注性能
不關注性能也是新人很容易犯的錯。什麼是性能呢。對後端來說就是TPS和響應時間，對前端來說就是響應時間。
很多新人程序員的習慣就是把東西做出來，然後再優化。
最後就是東西做出來了，優化留給別人了。
對性能的關注也是晉升中級程序員最關鍵的技能點。在寫代碼的時候，有經驗的工程師已經知道了這個方法這個函數這個功能點的性能怎麼樣，瓶頸在哪裡。
9 害怕重構
“程序員最大的勇氣就是看自己三個月之前寫的代碼。”
其實重構並不應該是在幾個月之後重構，最好的方式是實時重構。寫一天代碼，70%的時間都放到重構上都不過份。
而新人呢，磕磕跘跘的完成一個功能，就跟多米諾骨牌做成的大黃蜂一樣，你敢動一下他的代碼試試？他會跟你拼命。
你讓他自己動一行代碼試試？
不重構在某種程度上也意味著你的代碼實現無法重塑。
10 做出來就好，不考慮優雅的方案
有個詞叫做最佳實踐，其實編碼規範和最佳實踐，是編程功底的重要體現。
優雅方案可以認為是最佳實踐的升級版，它和上面說到的不斷的重構是相輔相成的。
不好的方案是什麼呢？硬編碼居多，沒有可擴展性，用很醜陋的方式完成了功能。
上次他們去做了一個關於試聽課的方案，一個人能試聽多少節課，正常的邏輯應該是在用戶的表裡加一個字段來表示。
需求是寫著邀請幾個人，可以試聽多少節課，所以他們判斷試聽多少節課就直接在通過邀請人的表裡查詢去做。
完全沒考慮到以後如果我變換了試聽課的判斷條件怎麼辦？
實際上這是應該拆解成兩部分，一個是試聽課的產生條件，這是一個獨立的模塊，加一個是試聽課的確認。
像這種例子太多了，也和不做方案，不考慮擴展性有關係，結果就是無法應對任何稍微大一點的變化。
閱讀更多 從不加班的程序猿 的文章
