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