菜鳥程式員都是怎樣寫代碼的？你也可以學一手

每個程式員都要經曆“菜雞”這個階段，那麼，在菜雞階段，程式員是怎麼寫代碼的呢？下面12大瞬間，能否找到你當初的影子？

1、命名不規範

可能不少程式員都會有這樣的經曆，寫代碼時靈光乍現，為了保證在靈感消逝前敲出更多代碼，敲代碼速度飛快，當然命名就顯得很随意了。什麼樣奇奇怪怪的命名都有：xiaonaigou，ergouzi，xxxx，j1，llst等等，可能過後這些命名連你自己都你完全不知道是什麼鬼。

2、日志不規範

可能有些同學會問：日志？那是什麼東西，能吃嗎？有不少同學會忽視日志的重要性，報錯的時候也是選擇在本地改代碼然後直接部署，但是等待出了問題不知道怎麼解決的時候，找誰來都會摸不着頭腦。

3、不寫單元測試

确切來說，是不按TDD的方式開發。在現在IDE這麼強大的情況下，先寫單元測試的習慣，不僅能夠使得代碼更具嚴謹性，而且也能夠極大提升效率。可是很多菜鳥了解不了單元測試的價值，直到代碼重構，需求變更的時候，才欲哭無淚！

4、先內建，再測試，再放棄

很多時候，菜雞在引入第三方的庫，架構，接口或者是服務的時候，最喜歡的事情就是直接和自己原有的代碼內建在一起。結果，卻跑不起來了，而且最崩潰的是，根本不知道問題出在哪裡。有經驗的程式員會先跑通官方提供的Demo，再想辦法一點一點加上自己的業務。

5、沒有理清邏輯，邊做邊猜

前端菜雞在這裡的問題特别多，做支付，不清楚支付的流程，分不清楚定義，總以為前端就是處理好借口和資料展示。先把邏輯處理好，弄清楚流程，再去動手才好。

6、不做方案，直接開幹

不做方案就意味着做事全憑感覺，而寫代碼時最好的習慣是先在腦袋裡把所有的需求細節過一遍，實作細節拿出來。

7、不關注性能

這是新手菜雞很容易犯的錯，什麼是性能呢。對後端來說就是TPS和響應時間，對前端來說就是響應時間。很多新手菜鳥的習慣就是把東西做出來，然後再做優化。但往往是東西做出來了，優化留給了别人。對性能的關注也是晉升中級程式員最關鍵的技能點。在寫代碼的時候，有經驗的工程師會知道了這個方法這個函數這個功能點的性能怎麼樣，瓶頸在哪裡。

8、害怕重構

“程式員最大的勇氣就是看自己三個月之前寫的代碼。”這句話一點都不假。其實重構并不應該是在幾個月之後重構，最好的方式是實時重構。

9、隻求做出來，不求最佳實踐

不少菜雞做項目時，寫死居多，沒有可擴充性，用很醜陋的方式完成了功能。

10、不考慮未來需求的變化

工程師的水準，其實可以分成以下幾個階段：面向功能程式設計-面向性能程式設計-面向未來程式設計。工程師拿到需求的第一件事，應該聚集在以下幾個問題：

第一，哪些需求是我之前完成過的；

第二，哪些需求是有可能變化的；

第三，有幾種方案，分别支援什麼樣的需求變化。

但是，菜鳥卻永遠不會考慮這麼多，一是因為對業務不熟悉，判斷不出來哪些需求可能會産生變化；二是對可選的方案掌握的不多，根本就沒有什麼可選的餘地；三是沒有這種思維習慣，分不清楚哪些是現在要完成的，哪些是未來可能會支援或者是變動的。

11、遇到問題不會試錯

這也是新手常見的問題。很多時候新人會遇到問題，解決不了，去找一個有經驗的工程師，這個有經驗的工程師雖然也沒有遇到過這種情況，但是卻有解決問題的思路，通過試錯很快就跑通了。其實，解決問題就是一個分析推理的過程。解決問題應該是：

1、尋找正确的代碼；

2、理清楚正确的執行順序；

3、重制錯誤；

4、最小化錯誤産生的場景；

5、修改代碼到一個已知的錯誤類型等等等。

12、不做資料量的預估

後端工程師在前期經常會忽視資料量的大小，沒有形成一個好的習慣。寫代碼隻注重功能，沒有一個關于資料量的概念。比較好的做法是，程式員要對資料很敏感，後端要知道每一個表的規模可能會有多大，目前的系統能支援的資料庫表的大小是多大，而前後端都需要知道每一個操作，都分成了哪幾個步驟，每一個步驟花費的時間是多少，大概占用的記憶體是什麼樣的。做到這一點其實并不難，難的是養成這種習慣，初級工程師眼裡看的是功能和代碼，中級工程師眼裡看到的是資料和時間。