高級程序員與初級程序員差異在哪裏？

以前在公衆號裏有個讀者給我留言：

請教個問題，公司高職級和初中級，都是寫業務代碼，那麼高職級的價值在哪裏呢？

因爲公衆號回覆留言的限制，當時我就簡單的回覆了以下的幾個點：

• 初級多在寫代碼，高級多在設計代碼；
• 初級多在解決一個問題，高級多在解決一類問題；
• 初級多在考慮技術問題，高級還要參與業務上的需求；
• 初級工程師只管接需求，致使本身忙不過來，高級工程師會砍需求， 用本身得經驗告訴產品這個需求不須要，告訴設計師這個交互不必；
• 初級工程師可能作完一個項目就完了，高級工程師可能會封裝幾個組件，整理一個腳手架出來。

還有不少不少，初級工程師和高級工程師差距不只僅是代碼質量上，並且其餘能力上，解決問題的能力，抽象問題的能力！

今天有時間，想詳細的跟你們談談我所遇到的、見到的厲害的程序員，一樣是寫業務代碼，爲何會比初級程序員拿的工資高？

初級多在寫代碼，高級多在設計代碼

通常人可能拿到需求，就開始寫代碼了，寫着寫着因爲頁面功能愈來愈多，感受代碼愈來愈複雜，本身都會以爲難以維護了。

我拿我本身舉個例子，以前有一次我寫完一個頁面以後，而後給另一個同事(能夠理解爲高級程序員)讓他幫我 Review 代碼，看到個人代碼以後就以爲這個寫得不對呀，怎麼會這麼去設計呢？

而後他給我理了下整個頁面應該如何去設計，一個頁面分爲哪些塊，有哪些事件，每一個事件應該 dispatch 哪些 action，而後整個模塊有哪些數據放在 store 裏，哪些模塊放在 state 裏，當時反正聽他理完以後，感受本身寫的代碼真的很垃圾，而後花了兩天時間把上週寫的代碼重寫了一邊。

注意，這裏是重寫，不是重構，重構是對軟件內部結構的一種調轉，目的是不改變軟件可觀察行爲的前提下，提升其可理解性，下降其修改爲本。那麼若是保證不改變軟件可觀察行爲呢？就須要寫測試用例，保證測試用例能跑通的狀況下進行從新構造代碼纔是重構的第一步，沒有測試用例的重構就是耍流氓。

那麼如何提升設計代碼的能力呢？

我以爲有一個方法對於提升設計代碼的能力很是有幫助，那就是採用 TDD(測試驅動開發)。

TDD 的原理是在開發功能代碼以前，先編寫單元測試用例代碼，測試代碼肯定須要編寫什麼產品代碼。 --來源百度百科

爲何 TDD 會提升設計代碼的能力呢？能夠看到 TDD 的原理是要在寫代碼以前就要寫測試用例，在寫測試用例的時候你必然得去思考你的每一個函數，每一個模塊，每一個組件應該如何去設計才能使得易於測試，每每易於測試的代碼都比較好維護。

這就能夠達到在寫代碼以前先去設計代碼，而後才寫代碼，也就是先思考，後行動。

我只是說 TDD 能夠提升設計代碼的能力，並無說我就特別提倡 TDD，說 TDD 很麻煩，難以實施的人就不要跟我討論了。

初級多在考慮技術問題，高級還要思考業務上的需求

咱們要知道，技術是爲業務服務的，沒有業務談技術的好壞都是瞎扯淡！

經常能夠看到不少實習生，或者剛來的應屆生會吐槽之前的老代碼用的框架老，用的技術舊，而後就去改爲新的，本身以爲牛逼的，而後沒有多個環境測試，發上線就掛了，這種例子不少不少，別說咱們公司，就連咱們組都出現過好幾回這樣的狀況了。

這種就是隻考慮技術問題的，而沒有去考慮爲何之前前人要這麼寫，前人沒有用這些東西，難道僅僅是由於那個時候沒有新東西，或者說認爲前人比你差。

極可能就是他們考慮到了業務上的需求，好比要兼容 IE、或者好比考慮到了有不少用戶用 iOS，Safari 不支持 webp ，或者好比考慮到不少用戶是低端機，性能很差，不能用一些新特性等等問題。

對於老闆來講，他根本無論你用什麼新技術，新特性，也許你用了新特性確實讓代碼更簡潔了，可是，可是，可是，發到線上掛了，那麼你寫的東西就是垃圾，連最基礎的穩定性都保證不了，更別說流暢性，高併發。

初級工程師只管接需求，高級工程師會砍需求

常常看到不少初級工程師就是，無論產品、運營甚至後端提出一些需求，他也很友好，只要是需求，他都接，而後成天忙忙碌碌，還常常加班，可是實際上，不少需求作了沒有什麼價值，也許還有些是重複工做，還把本身搞得很辛苦，這種狀況真的不少不少。

而後還有一種狀況是有一個產品需求來了，而後 balabala 一頓需求討論以後，產品給出一個期限，初級工程師滿打滿算，可能能完成，而後就說能行，結果要麼對本身能力估算錯誤，要麼不少突發狀況，而後不能按時上線。

而高級工程師基本上不會出現不能按時上線的狀況，我思考了幾點緣由：

1. 會給本身留 buffer，來避免突發狀況致使時間的耽擱。
2. 在需求分析的時候會思考每一個需求是否有必要，若是有些需求以爲不必，會和產品討論，拿出充分的理由將需求砍掉。若是都有必要，而後時間又不太夠，會去和產品談是否能使交互簡單一下，一期先出個什麼樣子，下一期再作完整一點。
3. 對需求的評估以及本身能力的評估更準確。

這裏我想要表達，不是全部的需求都是有必要的，不要每一個需求都去接。

那麼若是來判斷一個需求是否應該接呢？

我以爲主要是去思考他背後的價值，爲何要作這個東西，作了能達到什麼樣的效果，若是產品說不出來價值，或者說產生的價值與你花費的時間不匹配，那麼這個需求就是有待商討的。

初級多在解決一個問題，高級多在解決一類問題

不少初級工程師可能昨晚一個項目就完了，還以爲很 OK 呀，而後也把在項目中的問題一個一個的解決了，按時按量的完成了任務。

對，這就是初級工程師的標準，能完成一個項目。

那麼對於高級工程師除了完成項目還會作什麼呢？

也許會封裝幾個公用組件發到 npm 上你們均可以用。

也許會整理一個腳手架出來你們用，好比之前公司沒有用 TS，那麼用 TS 寫完項目以後，踩了不少坑，你就能夠整理出一個腳手架，而後把踩得坑記錄下來，方便後面想用 TS 的人用。

也許發現前端工程師還原 UI 搞是一件枯燥無味，並且沒有技術含量的事兒，我司有個大佬就寫了一個 UI2Code 的工具，能夠將 Sketch 文件轉化爲 html 代碼。

也許高級工程師發現一上線一個功能，小程序和 H5 都要寫一套如出一轍的，而後我司大佬就寫了一個能夠將 vue 代碼轉換爲小程序的框架，一套 vue 代碼，h5 和小程序都能用。

這些都是我身邊的例子，能夠看到高級工程師常常解決的不是一個問題，而是解決一類通用的問題，而後給出解決方案，而且得以實施，歷來不會認爲吧項目作完了就完了，沒有一點產出，也許你作這個項目是對本身太大的幫助，成長的。

初級程序員常常犯的錯誤集錦

而後我在知乎上看到了一個初級程序員常常犯的錯誤集錦，我以爲很是你們均可以看看，本身有沒有這些毛病。

1 命名不規範

2 日誌不規範

3 拒絕寫接口和假數據

4 不寫單元測試

5 盲目集成

6 邏輯不清

7 不作方案

8 不關注性能

9 懼怕重構

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

11 不考慮將來需求的變化

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

13 不會寫僞代碼

14 不作數據量的預估

15 提交代碼不規範

16 不喜歡打Tag

17 不遵照發布流程

18 不知道Bug修復的優先級

19 總喜歡手動修改線上代碼

20 不作數據備份

21 不作自測

22 不盡力模仿真實數據，測試數據很隨意

23 不抽取公共代碼

24 不認真聽需求講解

25 不看驗收標準

26 不主動推動項目進度

27 遇到難題不主動反饋

做者：暗滅連接：[]( https://www.zhihu.com/questio... https://www.zhihu.com/question/33578621/answer/451931102

總結

初級程序員主要是體如今目光短淺，缺少思考，作完東西沒有成果，不積極主動。

而高級程序員不只僅是代碼寫得好，寫得快，確實思考得更長遠，作的東西更有用。

我列舉我身邊所遇到的高級程序員所作的事，我以爲更有說服力，不是空談大道理，都是我從身邊的大佬們身上學到的，但願能給剛入職場，或者感受本身是個初級程序員的程序員們一些警戒。

固然，上面所說的高級工程師所擁有的優勢和初級工程師的缺點，都不是全部高級工程師都會有全部的這些優勢，也不是全部的初級工程師都具備這些缺點，這是沒辦法進行定量的。

大家身邊還遇到什麼高級工程師的特色，或者初級工程師的缺點，歡迎在評論區裏面留言。

最後歡迎你們關注個人公衆號「前端桃園」