菜雞程序員是如何寫代碼的？

每一個程序員都要歷經從菜雞到大牛過程蛻變胡過程。當初你們起點都差很少，工做多年後，有些人依然停留在菜雞，有些人卻已成爲大牛，全部的事情，都是一點一滴習慣養成。讓咱們看看菜雞程序員是如何寫代碼的？有可能找到你當初的影子，甚至是如今的影子。

1、命名不規範

命名很隨意，當時寫代碼特別High，什麼奇奇怪怪的命名都有的：xiaonaigou,xxxx,j1,jl,llst.徹底意識不到全名規範的價值和意義。

2、日誌不規範

日誌？
那是什麼鬼東西，能吃麼？

曾經有一個從文思海輝出來的小夥伴，三年後端工程師經驗，出了問題不知道怎麼解決。只好重啓。找我來協助，問他，怎麼錯了？  不知道。  日誌呢？   沒有。

暈，那怎麼解決問題，神仙也搞不定啊。 
後來才知道，他們解決問題都是本地改代碼而後直接部署，從新訪問看錯誤消失沒，沒有消失就繼續在本地改源碼。

3、拒絕寫接口和假數據

一個菜雞不可怕，可怕的是菜雞遇到菜雞。曾經有一個項目中的兩個菜雞，一個前端一個後端，他們很歡快的調接口，根本不寫文檔 ，兩我的效率特別高。直到有一天，發現項目可能作不完了，須要另外兩個前端菜雞協助一下。新來的兩個菜雞要獲取後端的數據，不知道接口的Url地址，不知道Get仍是Post，不知道發送的參數和返回值。就這樣寫！我壓根沒想到能夠這麼寫代碼，兩個菜雞很開心！拍手稱快：通了，通了，通了！

我說大家通什麼呢？他們說接口終於通了！原來他們兩個參考之間的頁面，硬生生的一次一次不停的嘗試，就這樣把接口猜出來了！這就是編程的樂趣嗎？還有不寫假數據。曾經有一個馬姓小哥，對趙姓小哥信誓旦旦的說：3天，給我3天時間 ，我把真數據給你。因而趙姓小哥信覺得真。就這樣，3天又3天，3天又3天，3天又3天，3天又3天，3天又3天。整整一個半月，趙姓小哥都沒有拿到所有的數據！

4、不寫單元測試

確切來講，是不按TDD的方式開發。在如今IDE這麼強大的狀況下，先寫單元測試的習慣，不只僅是代碼的嚴謹性，也是效率的代名詞啊。但是不少菜雞理解不了單元測試的價值，不要緊，等到代碼重構，需求變動的時候，就哭都哭不出來了！好的單元測試，你的邏輯必然會清楚。第一次啓動個人單元測試時，每每是這樣

5、先集成，再測試，再放棄。

不少時候，菜雞在引入第三方的庫，框架，接口或者是服務的時候，最喜歡的事情就是直接和本身原有的代碼集成在一塊兒。結果 是什麼呢？忽然間不能用了，跑不起來了，不知道問題出在哪了，根本分不清倒底是第三方的問題仍是本身的問題。  

好的方法是什麼？先跑通官方提供的Demo，再想辦法一點一點加上本身的業務。

6、理不清楚邏輯，邊作邊猜

前端在這裏的問題特別多，作支付，不清楚支付的流程，分不清楚定義，總覺得前端就是接口處理好數據展現好拉倒。不少菜雞都會有這種習慣，這樣很差，先把邏輯處理好，弄清楚流程，再去動手纔好。

7、不作方案

不作方案表明什麼含義呢？就是徹底憑直覺行走啊。

跟閉上眼逛窯子同樣。寫代碼的好習慣應該是先在腦殼裏把全部的需求細節過一遍，實現細節拿出來。上個月就有一個張姓小菜雞，作一個匿名評論的功能。基本上沒有什麼經驗，腦子也很差使，給出的方式是什麼大家猜獲得麼？用戶刷新一次就往用戶表裏插入一條數據，密碼默認暱稱隨機。很少說了都是淚，我見過太多讓人目瞪狗呆的方案了，看着滿屏的代碼，你怎麼幫他調錯調優，最好的方式就是所有重寫。作方案的好處太多了。

八、不關注性能

不關注性能也是新人很容易犯的錯。什麼是性能呢。對後端來講就是TPS和響應時間，對前端來講就是響應時間。不少新人程序員的習慣就是把東西作出來，而後再優化。最後就是東西作出來了，優化留給別人了。對性能的關注也是晉升中級程序員最關鍵的技能點。在寫代碼的時候，有經驗的工程師已經知道了這個方法這個函數這個功能點的性能怎麼樣，瓶頸在哪裏。

九、懼怕重構

「程序員最大的勇氣就是看本身三個月以前寫的代碼。」

其實重構並不該該是在幾個月以後重構，最好的方式是實時重構。寫一天代碼，70%的時間都放到重構上都不過份。而新人呢，磕磕跘跘的完成一個功能，就跟多米諾骨牌作成的大黃蜂同樣，你敢動一下他的代碼試試？他會跟你拼命。你讓他本身動一行代碼試試？不重構在某種程度上也意味着你的代碼實現沒法重塑。當你再看到本身幾個月沒碰過的代碼，每每是這樣：

十、作出來就好，不考慮優雅的方案

有個詞叫作最佳實踐，其實編碼規範和最佳實踐，是編程功底的重要體現。優雅方案能夠認爲是最佳實踐的升級版，它和上面說到的不斷的重構是相輔相成的。很差的方案是什麼呢？硬編碼居多，沒有可擴展性，用很醜陋的方式完成了功能。好比輪子是正方形的，也認爲車子能開就行：

上次他們去作了一個關於試聽課的方案，一我的能試聽多少節課，正常的邏輯應該是在用戶的表裏加一個字段來表示。需求是寫着邀請幾我的，能夠試聽多少節課，因此他們判斷試聽多少節課就直接在經過邀請人的表裏查詢去作。徹底沒考慮到之後若是我變換了試聽課的判斷條件怎麼辦？實際上這是應該拆解成兩部分，一個是試聽課的產生條件，這是一個獨立的模塊，加一個是試聽課的確認。像這種例子太多了，也和不作方案，不考慮擴展性有關係。就是接下來要說的。

十一、不考慮將來需求的變化

工程師的水準，其實能夠分紅如下幾個階段：

• 面向功能編程    

• 面向性能編程    

• 面向將來編程  

工程師拿到需求的第一件事，應該彙集在如下幾個問題：

• 第一 哪些需求是我以前完成過的  

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

• 第三 有幾種方案，分別支持什麼樣的需求變化  

 

當一個新續期來時，每每都要推到從新來： 

可是差一點的程序員就考慮不到那麼遠，一個是對業務不熟悉，判斷不出來哪些需求可能會產生變化，一個是對可選的方案掌握的很少，根本就沒有什麼可選的餘地，還有就是沒有這種思惟習慣，分不清楚哪些是如今要完成的，哪些是將來可能會支持或者是變更的。

十二、遇到問題的時候不會試錯

這也是新手常見的問題。不少時候新人會遇到問題，解決不了，去找一個有經驗的工程師，這個有經驗的工程師呢，大概也不曾遇到這種狀況，可是他解決問題的思路清楚啊。一下子試試這個，一下子刪刪那段代碼，很快就跑通了。解決問題是一個很見功底的技術點，並且是有不少方法論的，以前總結過一些，簡單列舉過來：

• 1.尋找正確的代碼  

• 2.理清楚正確的執行順序  

• 3.重現錯誤  

• 4.最小化錯誤產生的場景  

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

解決問題就是一個分析推理的過程，而在這裏呢，背後的功底就是你知道不少哪些是確定不會錯的小公理，而後再挨個去定位可能產生錯誤的環節，分解流程是最基礎的工做。高級開發調試問題，每每以下：

1三、不會寫僞代碼

僞代碼是什麼呢？就是天然語言啊。其實編程只有三種邏輯控制塊，順序，循環，判斷。因此你只要用天然語言來描述出來，先作什麼，再作什麼，何時循環，何時判斷，代碼寫出來的問題就不大。這是一個先寫僞代碼再寫細節的過程。你不要上來就開始平鋪寫代碼。 
平鋪代碼是最菜的方式，好的代碼是有結構的，有不一樣的抽像層級。

• 第一步，幹嗎。     

• 第二步，幹嗎。   

• 第三步，幹嗎。   

• 先把這個列清楚，這是僞代碼的第一級。   

• 而後變成註釋，這是第二級。     

• 刪掉註釋變成函數名，這是第三級。

因此說，好的程序員寫代碼是不須要註釋的，不是說讓你把註釋刪掉，而是讓你完成這三步昇華的過程。寫的好的代碼，命名規範，你看到的真的是一首詩， 是一種編程語言，是在用語言來描述一件功能的完成，這種編程藝術的工業感很爽快，你看那些不爽的代碼，簡直了。一步一個坑：

1四、不作數據量的預估

後端工程師在前期常常會忽視數據量的大小，沒有影成一個好的習慣。寫代碼只注重功能，沒有一個關於數據量的概念。這個地方其實還和性能是一致的，在性能上，先後端並無太大的差異。推薦的作法是，程序員要對數據很敏感，後端要知道每個表的規模可能會有多大，當前的系統能支持的數據庫表的大小是多大，而先後端都須要知道每個操做，都分紅了哪幾個步驟，每個步驟花費的時間是多少，大概佔用的內存是什麼樣的。作到這一點其實並不難，難的是養成這種習慣，初級工程師眼裏看的是功能和代碼，中級工程師眼裏看到的是數據和時間。沒有預估，最後起火了，每每是這樣的：