每個程式設計師都要經歷「菜雞」這個階段，那麼，在菜雞階段，程式設計師是怎麼寫代碼的呢？下面12大瞬間，能否找到你當初的影子？
01命名不規範
可能不少程式設計師都會有這樣的經歷，寫代碼時靈光乍現，為了保證在靈感消逝前敲出更多代碼，敲代碼速度飛快，當然命名就顯得很隨意了。
什麼樣奇奇怪怪的命名都有：xiaonaigou，ergouzi，xxxx，j1，llst等等，可能過後這些命名連你自己都你完全不知道是什麼鬼。
02、日誌不規範
可能有些同學會問：日誌？那是什麼東西，能吃嗎？
有不少同學會忽視日誌的重要性，報錯的時候也是選擇在本地改代碼然後直接部署，但是等待出了問題不知道怎麼解決的時候，找誰來都會摸不著頭腦。
03、不寫單元測試
確切來說，是不按TDD的方式開發。
在現在IDE這麼強大的情況下，先寫單元測試的習慣，不僅能夠使得代碼更具嚴謹性，而且也能夠極大提升效率。
可是很多菜雞理解不了單元測試的價值，直到代碼重構，需求變更的時候，才欲哭無淚！
4、先集成，再測試，再放棄
很多時候，菜雞在引入第三方的庫，框架，接口或者是服務的時候，最喜歡的事情就是直接和自己原有的代碼集成在一起。結果，卻跑不起來了，而且最崩潰的是，根本不知道問題出在哪裡。
有經驗的程式設計師會先跑通官方提供的Demo，再想辦法一點一點加上自己的業務。
5、沒有理清邏輯，邊做邊猜
前端菜雞在這裡的問題特別多，做支付，不清楚支付的流程，分不清楚定義，總以為前端就是處理好藉口和數據展示。
先把邏輯處理好，弄清楚流程，再去動手才好。
06、不做方案，直接開干
不做方案就意味著做事全憑感覺，而寫代碼時最好的習慣是先在腦袋裡把所有的需求細節過一遍，實現細節拿出來。
07、不關注性能
這是新手菜雞很容易犯的錯，什麼是性能呢。對後端來說就是TPS和響應時間，對前端來說就是響應時間。
很多新手菜雞的習慣就是把東西做出來，然後再做優化。但往往是東西做出來了，優化留給了別人。
對性能的關注也是晉升中級程式設計師最關鍵的技能點。在寫代碼的時候，有經驗的工程師會知道了這個方法這個函數這個功能點的性能怎麼樣，瓶頸在哪裡。
08、害怕重構
「程式設計師最大的勇氣就是看自己三個月之前寫的代碼。」這句話一點都不假。其實重構並不應該是在幾個月之後重構，最好的方式是實時重構。
09、只求做出來，不求最佳實踐
不少菜雞做項目時，硬編碼居多，沒有可擴展性，用很醜陋的方式完成了功能。
10、不考慮未來需求的變化
工程師的水準，其實可以分成以下幾個階段：
- 面向功能編程
- 面向性能編程
- 面向未來編程
工程師拿到需求的第一件事，應該聚集在以下幾個問題：
- 第一，哪些需求是我之前完成過的；
- 第二，哪些需求是有可能變化的；
- 第三，有幾種方案，分別支持什麼樣的需求變化。
但是，菜雞卻永遠不會考慮這麼多，一是因為對業務不熟悉，判斷不出來哪些需求可能會產生變化；二是對可選的方案掌握的不多，根本就沒有什麼可選的餘地；三是沒有這種思維習慣，分不清楚哪些是現在要完成的，哪些是未來可能會支持或者是變動的。
11、遇到問題不會試錯
這也是新手常見的問題。很多時候新人會遇到問題，解決不了，去找一個有經驗的工程師，這個有經驗的工程師雖然也沒有遇到過這種情況，但是卻有解決問題的思路，通過試錯很快就跑通了。
其實，解決問題就是一個分析推理的過程。解決問題應該是：
- 1、尋找正確的代碼；
- 2、理清楚正確的執行順序；
- 3、重現錯誤；
- 4、最小化錯誤產生的場景；
- 5、修改代碼到一個已知的錯誤類型等等等。
12、不做數據量的預估
後端工程師在前期經常會忽視數據量的大小，沒有形成一個好的習慣。寫代碼只注重功能，沒有一個關於數據量的概念。
比較好的做法是，程式設計師要對數據很敏感，後端要知道每一個表的規模可能會有多大，當前的系統能支持的資料庫表的大小是多大，而前後端都需要知道每一個操作，都分成了哪幾個步驟，每一個步驟花費的時間是多少，大概占用的內存是什麼樣的。
做到這一點其實並不難，難的是養成這種習慣，初級工程師眼裡看的是功能和代碼，中級工程師眼裡看到的是數據和時間。
上面這些，你占了幾條呢？敢不敢留言讓大家看看？
關注「重慶千鋒」公眾號，搶千鋒14天免費試聽課，名師大咖面授教學，項目實操經驗積累，輕鬆入門，快速進階，菜雞也能變大神！