前端成長01 高階程式設計師和普通程式設計師有哪些區別？
先不說高階。就只說初級程式設計師經常容易犯的錯誤，把這些錯誤改正了，你離中級就不遠了。
初級程式設計師經常犯的錯誤集錦
- 命名不規範
- 日誌不規範
- 拒絕寫介面和假資料
- 不寫單元測試
- 盲目整合
- 邏輯不清
- 不做方案
- 不關注效能
- 害怕重構
- 做出來就好，不考慮優雅的方案
- 不考慮未來需求的變化
- 遇到問題的時候不會試錯
- 不會寫虛擬碼
- 不做資料量的預估
- 提交程式碼不規範
- 不喜歡打Tag
- 不遵守釋出流程
- 不知道Bug修復的優先順序
- 總喜歡手動修改線上程式碼
- 不做資料備份
- 不做自測
- 不盡力模模擬實資料，測試資料很隨意
- 不抽取公共程式碼
- 不認真聽需求講解
- 不看驗收標準
- 不主動推進專案進度
- 遇到難題不主動反饋
一 命名不規範
命名很隨意，當時寫程式碼特別High，什麼奇奇怪怪的命名都有的：xiaonaigou,xxxx,j1,jl,llst.
完全意識不到全名規範的價值和意義。
二 日誌不規範
日誌？那是什麼鬼東西，能吃麼？
曾經有一個從文思海輝出來的小夥伴，三年後端工程師經驗，出了問題不知道怎麼解決。
只好重啟。
找我來協助，問他，怎麼錯了？
不知道。
日誌呢？
沒有。
暈，那怎麼解決問題，神仙也搞不定啊。
後來才知道，他們解決問題都是本地改程式碼然後直接部署，重新訪問看錯誤消失沒，沒有消失就繼續在本地改原始碼。
三 拒絕寫介面和假資料
一個菜雞不可怕，可怕的是菜雞遇到菜雞。曾經有一個專案中的兩個菜雞，一個前端一個後端，他們很歡快的調介面，根本不寫文件 ，兩個人效率特別高。
直到有一天，發現專案可能做不完了，需要另外兩個前端菜雞協助一下。
新來的兩個菜雞要獲取後端的資料，不知道介面的Url地址，不知道Get還是Post，不知道傳送的引數和返回值。就這樣寫！
我壓根沒想到可以這麼寫程式碼，兩個菜雞很開心！拍手稱快：通了，通了，通了！
我說你們通什麼呢？他們說介面終於通了！原來他們兩個參考之間的頁面，硬生生的一次一次不停的嘗試，就這樣把介面猜出來了！
這就是程式設計的樂趣嗎？
還有不寫假資料。曾經有一個馬姓小哥，對趙姓小哥信誓旦旦的說：3天，給我3天時間 ，我把真資料給你。
於是趙姓小哥信以為真。就這樣，3天又3天，3天又3天，3天又3天，3天又3天，3天又3天。
整整一個半月，趙姓小哥都沒有拿到全部的資料！
四 不寫單元測試
確切來說，是不按TDD的方式開發。在現在IDE這麼強大的情況下，先寫單元測試的習慣，不僅僅是程式碼的嚴謹性，也是效率的代名詞啊。
可是很多菜雞理解不了單元測試的價值，沒關係，等到程式碼重構，需求變更的時候，就哭都哭不出來了！
好的單元測試，你的邏輯必然會清楚。
五 先整合，再測試，再放棄
很多時候，菜雞在引入第三方的庫，框架，介面或者是服務的時候，最喜歡的事情就是直接和自己原有的程式碼整合在一起。
結果 是什麼呢？突然間不能用了，跑不起來了，不知道問題出在哪了，根本分不清倒底是第三方的問題還是自己的問題。
好的方法是什麼？先跑通官方提供的Demo，再想辦法一點一點加上自己的業務。
六 理不清楚邏輯，邊做邊猜
前端在這裡的問題特別多，做支付，不清楚支付的流程，分不清楚定義，總以為前端就是介面處理好資料展示好拉倒。
很多菜雞都會有這種習慣，這樣不好，先把邏輯處理好，弄清楚流程，再去動手才好。
七 不做方案
不做方案代表什麼含義呢？就是完全憑直覺行走啊。
跟閉上眼逛窯子一樣。
寫程式碼的好習慣應該是先在腦袋裡把所有的需求細節過一遍，實現細節拿出來。
上個月就有一個張姓小菜雞，做一個匿名評論的功能。
基本上沒有什麼經驗，腦子也不好使，給出的方式是什麼你們猜得到麼？
使用者重新整理一次就往使用者表裡插入一條資料，密碼預設暱稱隨機。
不多說了都是淚，我見過太多讓人目瞪狗呆的方案了，看著滿屏的程式碼，你怎麼幫他調錯調優，最好的方式就是全部重寫。
做方案的好處太多了。
八 不關注效能
不關注效能也是新人很容易犯的錯。什麼是效能呢。對後端來說就是TPS和響應時間，對前端來說就是響應時間。
很多新人程式設計師的習慣就是把東西做出來，然後再優化。
最後就是東西做出來了，優化留給別人了。
對效能的關注也是晉升中級程式設計師最關鍵的技能點。在寫程式碼的時候，有經驗的工程師已經知道了這個方法這個函式這個功能點的效能怎麼樣，瓶頸在哪裡。
九 害怕重構
“程式設計師最大的勇氣就是看自己三個月之前寫的程式碼。”
其實重構並不應該是在幾個月之後重構，最好的方式是實時重構。寫一天程式碼，70%的時間都放到重構上都不過份。
而新人呢，磕磕跘跘的完成一個功能，就跟多米諾骨牌做成的大黃蜂一樣，你敢動一下他的程式碼試試？他會跟你拼命。
你讓他自己動一行程式碼試試？
不重構在某種程度上也意味著你的程式碼實現無法重塑。
十 做出來就好，不考慮優雅的方案
有個詞叫做最佳實踐，其實編碼規範和最佳實踐，是程式設計功底的重要體現。
優雅方案可以認為是最佳實踐的升級版，它和上面說到的不斷的重構是相輔相成的。
不好的方案是什麼呢？硬編碼居多，沒有可擴充套件性，用很醜陋的方式完成了功能。
上次他們去做了一個關於試聽課的方案，一個人能試聽多少節課，正常的邏輯應該是在使用者的表裡加一個欄位來表示。
需求是寫著邀請幾個人，可以試聽多少節課，所以他們判斷試聽多少節課就直接在通過邀請人的表裡查詢去做。
完全沒考慮到以後如果我變換了試聽課的判斷條件怎麼辦？
實際上這是應該拆解成兩部分，一個是試聽課的產生條件，這是一個獨立的模組，加一個是試聽課的確認。
像這種例子太多了，也和不做方案，不考慮擴充套件性有關係。就是接下來要說的。
十一 不考慮未來需求的變化
工程師的水準，其實可以分成以下幾個階段（馬丹我找不到之前在哪個答案裡寫過了）：
面向功能程式設計
面向效能程式設計
面向未來程式設計
工程師拿到需求的第一件事，應該聚集在以下幾個問題：
第一 哪些需求是我之前完成過的
第二 哪些需求是有可能變化的
第三 有幾種方案，分別支援什麼樣的需求變化
但是差一點的程式設計師就考慮不到那麼遠，一個是對業務不熟悉，判斷不出來哪些需求可能會產生變化，一個是對可選的方案掌握的不多，根本就沒有什麼可選的餘地，還有就是沒有這種思維習慣，分不清楚哪些是現在要完成的，哪些是未來可能會支援或者是變動的。
十二 遇到問題的時候不會試錯
這也是新手常見的問題。很多時候新人會遇到問題，解決不了，去找一個有經驗的工程師，這個有經驗的工程師呢，大概也未曾遇到這種情況，但是他解決問題的思路清楚啊。
一會兒試試這個，一會兒刪刪那段程式碼，很快就跑通了。
解決問題是一個很見功底的技術點，而且是有很多方法論的，之前總結過一些，簡單列舉過來：
- 尋找正確的程式碼
- 理清楚正確的執行順序
- 重現錯誤
- 最小化錯誤產生的場景
- 修改程式碼到一個已知的錯誤型別
等等等。
解決問題就是一個分析推理的過程，而在這裡呢，背後的功底就是你知道很多哪些是肯定不會錯的小公理，然後再挨個去定位可能產生錯誤的環節，分解流程是最基礎的工作。
十三 不會寫虛擬碼
虛擬碼是什麼呢？就是自然語言啊。其實程式設計只有三種邏輯控制塊，順序，迴圈，判斷。
所以你只要用自然語言來描述出來，先做什麼，再做什麼，什麼時候迴圈，什麼時候判斷，
程式碼寫出來的問題就不大。
這是一個先寫虛擬碼再寫細節的過程。你不要上來就開始平鋪寫程式碼（我之前講過優雅程式碼之道，有興趣的可以加群聽一下，重點講了怎麼寫出來優雅程式碼）。
平鋪程式碼是最菜的方式，好的程式碼是有結構的，有不同的抽像層級。
第一步，幹嘛。
第二步，幹嘛。
第三步，幹嘛。
先把這個列清楚，這是虛擬碼的第一級。
然後變成註釋，這是第二級。
刪掉註釋變成函式名，這是第三級。
所以說，好的程式設計師寫程式碼是不需要註釋的，不是說讓你把註釋刪掉，而是讓你完成這三步昇華的過程。
寫的好的程式碼，命名規範，你看到的真的是一首詩， 是一種程式語言，是在用語言來描述一件功能的完成，這種程式設計藝術的工業感很爽快，你看那些不爽的程式碼，簡直了。。
十四 不做資料量的預估
後端工程師在前期經常會忽視資料量的大小，沒有影成一個好的習慣。
寫程式碼只注重功能，沒有一個關於資料量的概念。
這個地方其實還和效能是一致的，在效能上，前後端並沒有太大的差別。
推薦的做法是，程式設計師要對資料很敏感，後端要知道每一個表的規模可能會有多大，當前的系統能支援的資料庫表的大小是多大，而前後端都需要知道每一個操作，都分成了哪幾個步驟，每一個步驟花費的時間是多少，大概佔用的記憶體是什麼樣的。
做到這一點其實並不難，難的是養成這種習慣，初級工程師眼裡看的是功能和程式碼，中級工程師眼裡看到的是資料和時間。