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

每個程序員都要歷經(jīng)從菜雞到大牛過程蛻變胡過程。當(dāng)初大家起點都差不多，工作多年后，有些人依然停留在菜雞，有些人卻已成為大牛，所有的事情，都是一點一滴習(xí)慣養(yǎng)成。讓我們看看菜雞程序員是如何寫代碼的？有可能找到你當(dāng)初的影子，甚至是現(xiàn)在的影子。

創(chuàng)新互聯(lián)建站主營東莞網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,app軟件開發(fā),東莞h5成都小程序開發(fā)搭建,東莞網(wǎng)站營銷推廣歡迎東莞等地區(qū)企業(yè)咨詢

一、命名不規(guī)范

命名很隨意，當(dāng)時寫代碼特別High，什么奇奇怪怪的命名都有的：xiaonaigou,xxxx,j1,jl,llst.完全意識不到全名規(guī)范的價值和意義。

二、日志不規(guī)范

日志？
那是什么鬼東西，能吃么？ ? ?
曾經(jīng)有一個從文思海輝出來的小伙伴，三年后端工程師經(jīng)驗，出了問題不知道怎么解決。只好重啟。找我來協(xié)助，問他，怎么錯了？ ? 不知道。 ? 日志呢？ ? ?沒有。 ??
暈，那怎么解決問題，神仙也搞不定啊。???
后來才知道，他們解決問題都是本地改代碼然后直接部署，重新訪問看錯誤消失沒，沒有消失就繼續(xù)在本地改源碼。

三、拒絕寫接口和假數(shù)據(jù)

一個菜雞不可怕，可怕的是菜雞遇到菜雞。曾經(jīng)有一個項目中的兩個菜雞，一個前端一個后端，他們很歡快的調(diào)接口，根本不寫文檔 ，兩個人效率特別高。直到有一天，發(fā)現(xiàn)項目可能做不完了，需要另外兩個前端菜雞協(xié)助一下。新來的兩個菜雞要獲取后端的數(shù)據(jù)，不知道接口的Url地址，不知道Get還是Post，不知道發(fā)送的參數(shù)和返回值。就這樣寫！我壓根沒想到可以這么寫代碼，兩個菜雞很開心！拍手稱快：通了，通了，通了！我說你們通什么呢？他們說接口終于通了！原來他們兩個參考之間的頁面，硬生生的一次一次不停的嘗試，就這樣把接口猜出來了！這就是編程的樂趣嗎？ 還有不寫假數(shù)據(jù)。曾經(jīng)有一個馬姓小哥，對趙姓小哥信誓旦旦的說：3天，給我3天時間 ，我把真數(shù)據(jù)給你。于是趙姓小哥信以為真。就這樣，3天又3天，3天又3天，3天又3天，3天又3天，3天又3天。整整一個半月，趙姓小哥都沒有拿到全部的數(shù)據(jù)！

四、不寫單元測試

確切來說，是不按TDD的方式開發(fā)。在現(xiàn)在IDE這么強大的情況下，先寫單元測試的習(xí)慣，不僅僅是代碼的嚴(yán)謹(jǐn)性，也是效率的代名詞啊?？墒呛芏嗖穗u理解不了單元測試的價值，沒關(guān)系，等到代碼重構(gòu)，需求變更的時候，就哭都哭不出來了！好的單元測試，你的邏輯必然會清楚。

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

很多時候，菜雞在引入第三方的庫，框架，接口或者是服務(wù)的時候，最喜歡的事情就是直接和自己原有的代碼集成在一起。結(jié)果 是什么呢？突然間不能用了，跑不起來了，不知道問題出在哪了，根本分不清倒底是第三方的問題還是自己的問題。 ? 好的方法是什么？先跑通官方提供的Demo，再想辦法一點一點加上自己的業(yè)務(wù)。

六、理不清楚邏輯，邊做邊猜

前端在這里的問題特別多，做支付，不清楚支付的流程，分不清楚定義，總以為前端就是接口處理好數(shù)據(jù)展示好拉倒。很多菜雞都會有這種習(xí)慣，這樣不好，先把邏輯處理好，弄清楚流程，再去動手才好。

七、不做方案

不做方案代表什么含義呢？就是完全憑直覺行走啊。 ? ? ?
跟閉上眼逛窯子一樣。寫代碼的好習(xí)慣應(yīng)該是先在腦袋里把所有的需求細節(jié)過一遍，實現(xiàn)細節(jié)拿出來。上個月就有一個張姓小菜雞，做一個匿名評論的功能。基本上沒有什么經(jīng)驗，腦子也不好使，給出的方式是什么你們猜得到么？用戶刷新一次就往用戶表里插入一條數(shù)據(jù)，密碼默認(rèn)昵稱隨機。不多說了都是淚，我見過太多讓人目瞪狗呆的方案了，看著滿屏的代碼，你怎么幫他調(diào)錯調(diào)優(yōu)，最好的方式就是全部重寫。做方案的好處太多了。

8、不關(guān)注性能

不關(guān)注性能也是新人很容易犯的錯。什么是性能呢。對后端來說就是TPS和響應(yīng)時間，對前端來說就是響應(yīng)時間。很多新人程序員的習(xí)慣就是把東西做出來，然后再優(yōu)化。最后就是東西做出來了，優(yōu)化留給別人了。對性能的關(guān)注也是晉升中級程序員最關(guān)鍵的技能點。在寫代碼的時候，有經(jīng)驗的工程師已經(jīng)知道了這個方法這個函數(shù)這個功能點的性能怎么樣，瓶頸在哪里。

9、害怕重構(gòu)

“程序員最大的勇氣就是看自己三個月之前寫的代碼?！?/strong>其實重構(gòu)并不應(yīng)該是在幾個月之后重構(gòu)，最好的方式是實時重構(gòu)。寫一天代碼，70%的時間都放到重構(gòu)上都不過份。而新人呢，磕磕跘跘的完成一個功能，就跟多米諾骨牌做成的大黃蜂一樣，你敢動一下他的代碼試試？他會跟你拼命。你讓他自己動一行代碼試試？不重構(gòu)在某種程度上也意味著你的代碼實現(xiàn)無法重塑。

10、做出來就好，不考慮優(yōu)雅的方案

有個詞叫做最佳實踐，其實編碼規(guī)范和最佳實踐，是編程功底的重要體現(xiàn)。優(yōu)雅方案可以認(rèn)為是最佳實踐的升級版，它和上面說到的不斷的重構(gòu)是相輔相成的。不好的方案是什么呢？硬編碼居多，沒有可擴展性，用很丑陋的方式完成了功能。上次他們?nèi)プ隽艘粋€關(guān)于試聽課的方案，一個人能試聽多少節(jié)課，正常的邏輯應(yīng)該是在用戶的表里加一個字段來表示。需求是寫著邀請幾個人，可以試聽多少節(jié)課，所以他們判斷試聽多少節(jié)課就直接在通過邀請人的表里查詢?nèi)プ觥Ｍ耆珱]考慮到以后如果我變換了試聽課的判斷條件怎么辦？實際上這是應(yīng)該拆解成兩部分，一個是試聽課的產(chǎn)生條件，這是一個獨立的模塊，加一個是試聽課的確認(rèn)。像這種例子太多了，也和不做方案，不考慮擴展性有關(guān)系。就是接下來要說的。

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

工程師的水準(zhǔn)，其實可以分成以下幾個階段：

• 面向功能編程 ? ?

• 面向性能編程 ? ?

• 面向未來編程 ?

工程師拿到需求的第一件事，應(yīng)該聚集在以下幾個問題：

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

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

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

但是差一點的程序員就考慮不到那么遠，一個是對業(yè)務(wù)不熟悉，判斷不出來哪些需求可能會產(chǎn)生變化，一個是對可選的方案掌握的不多，根本就沒有什么可選的余地，還有就是沒有這種思維習(xí)慣，分不清楚哪些是現(xiàn)在要完成的，哪些是未來可能會支持或者是變動的。

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

這也是新手常見的問題。很多時候新人會遇到問題，解決不了，去找一個有經(jīng)驗的工程師，這個有經(jīng)驗的工程師呢，大概也未曾遇到這種情況，但是他解決問題的思路清楚啊。一會兒試試這個，一會兒刪刪那段代碼，很快就跑通了。解決問題是一個很見功底的技術(shù)點，而且是有很多方法論的，之前總結(jié)過一些，簡單列舉過來：

• 1.尋找正確的代碼 ?

• 2.理清楚正確的執(zhí)行順序 ?

• 3.重現(xiàn)錯誤 ?

• 4.最小化錯誤產(chǎn)生的場景 ?

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

解決問題就是一個分析推理的過程，而在這里呢，背后的功底就是你知道很多哪些是肯定不會錯的小公理，然后再挨個去定位可能產(chǎn)生錯誤的環(huán)節(jié)，分解流程是最基礎(chǔ)的工作。

13、不會寫偽代碼

偽代碼是什么呢？就是自然語言啊。其實編程只有三種邏輯控制塊，順序，循環(huán)，判斷。所以你只要用自然語言來描述出來，先做什么，再做什么，什么時候循環(huán)，什么時候判斷，代碼寫出來的問題就不大。這是一個先寫偽代碼再寫細節(jié)的過程。你不要上來就開始平鋪寫代碼（我之前講過優(yōu)雅代碼之道，有興趣的可以加群聽一下，重點講了怎么寫出來優(yōu)雅代碼）。 ??
平鋪代碼是最菜的方式，好的代碼是有結(jié)構(gòu)的，有不同的抽像層級。

• 第一步，干嘛。 ? ? ?

• 第二步，干嘛。 ? ?

• 第三步，干嘛。 ? ?

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

• 然后變成注釋，這是第二級。 ? ? ?

• 刪掉注釋變成函數(shù)名，這是第三級。

所以說，好的程序員寫代碼是不需要注釋的，不是說讓你把注釋刪掉，而是讓你完成這三步升華的過程。寫的好的代碼，命名規(guī)范，你看到的真的是一首詩， 是一種編程語言，是在用語言來描述一件功能的完成，這種編程藝術(shù)的工業(yè)感很爽快，你看那些不爽的代碼，簡直了。

14 不做數(shù)據(jù)量的預(yù)估

后端工程師在前期經(jīng)常會忽視數(shù)據(jù)量的大小，沒有影成一個好的習(xí)慣。寫代碼只注重功能，沒有一個關(guān)于數(shù)據(jù)量的概念。這個地方其實還和性能是一致的，在性能上，前后端并沒有太大的差別。推薦的做法是，程序員要對數(shù)據(jù)很敏感，后端要知道每一個表的規(guī)?？赡軙卸啻?，當(dāng)前的系統(tǒng)能支持的數(shù)據(jù)庫表的大小是多大，而前后端都需要知道每一個操作，都分成了哪幾個步驟，每一個步驟花費的時間是多少，大概占用的內(nèi)存是什么樣的。做到這一點其實并不難，難的是養(yǎng)成這種習(xí)慣，初級工程師眼里看的是功能和代碼，中級工程師眼里看到的是數(shù)據(jù)和時間。