之前有個讀者給我留言：
請教個問題，公司高職級和初中級，都是寫業務代碼，那麼高職級的價值在哪裡呢？
由於公眾號回覆留言的限制，當時我就簡單的回覆瞭如下的幾個點：
- 初級多在寫代碼，高級多在設計代碼；
- 初級多在解決一個問題，高級多在解決一類問題；
- 初級多在考慮技術問題，高級還要參與業務上的需求；
- 初級工程師只管接需求，導致自己忙不過來，高級工程師會砍需求， 用自己得經驗告訴產品這個需求不需要，告訴設計師這個交互沒必要；
- 初級工程師可能做完一個項目就完了，高級工程師可能會封裝幾個組件，整理一個腳手架出來。
還有很多很多，初級工程師和高級工程師差距不僅僅是代碼質量上，而且其他能力上，解決問題的能力，抽象問題的能力！
今天有時間，想詳細的跟大家談談我所遇到的、見到的厲害的程序員，同樣是寫業務代碼，為什麼會比初級程序員拿的工資高？
初級多在寫代碼，高級多在設計代碼
一般人可能拿到需求，就開始寫代碼了，寫著寫著由於頁面功能越來越多，感覺代碼越來越複雜，自己都會覺得難以維護了。
我拿我自己舉個例子，之前有一次我寫完一個頁面之後，然後給另外一個同事(可以理解為高級程序員)讓他幫我 Review 代碼，看到我的代碼之後就覺得這個寫得不對呀，怎麼會這麼去設計呢？
然後他給我理了下整個頁面應該如何去設計，一個頁面分為哪些塊，有哪些事件，每個事件應該dispatch 哪些action ，然後整個模塊有哪些數據放在store 裡，哪些模塊放在state裡，當時反正聽他理完之後，感覺自己寫的代碼真的很垃圾，然後花了兩天時間把上週寫的代碼重寫了一邊。
注意，這裡是重寫，不是重構，重構是對軟件內部結構的一種調轉，目的是不改變軟件可觀察行為的前提下，提高其可理解性，降低其修改成本。那麼如果保證不改變軟件可觀察行為呢？就需要寫測試用例，保證測試用例能跑通的情況下進行重新構造代碼才是重構的第一步，沒有測試用例的重構就是耍流氓。
那麼如何提高設計代碼的能力呢？
我覺得有一個方法對於提高設計代碼的能力非常有幫助，那就是採用 TDD(測試驅動開發)。
TDD 的原理是在開發功能代碼之前，先編寫單元測試用例代碼，測試代碼確定需要編寫什麼產品代碼。 --來源百度百科
為什麼 TDD 會提高設計代碼的能力呢？可以看到 TDD 的原理是要在寫代碼之前就要寫測試用例，在寫測試用例的時候你必然得去思考你的每個函數，每個模塊，每個組件應該如何去設計才能使得易於測試，往往易於測試的代碼都比較好維護。
這就可以達到在寫代碼之前先去設計代碼，然後才寫代碼，也就是先思考，後行動。
我只是說 TDD 可以提高設計代碼的能力，並沒有說我就特別提倡 TDD，說 TDD 很麻煩，難以實施的人就不要跟我討論了。
初級多在考慮技術問題，高級還要思考業務上的需求
我們要知道，技術是為業務服務的，沒有業務談技術的好壞都是瞎扯淡！
常常可以看到很多實習生，或者剛來的應屆生會吐槽以前的老代碼用的框架老，用的技術舊，然後就去改成新的，自己覺得牛逼的，然後沒有多個環境測試，發上線就掛了，這種例子很多很多，別說我們公司，就連我們組都出現過好幾次這樣的情況了。
這種就是隻考慮技術問題的，而沒有去考慮為什麼以前前人要這麼寫，前人沒有用這些東西，難道僅僅是因為那個時候沒有新東西，或者說認為前人比你差。
很可能就是他們考慮到了業務上的需求，比如要兼容 IE、或者比如考慮到了有很多用戶用 iOS，Safari 不支持 webp ，或者比如考慮到很多用戶是低端機，性能不好，不能用一些新特性等等問題。
對於老闆來說，他根本不管你用什麼新技術，新特性，也許你用了新特性確實讓代碼更簡潔了，但是，但是，但是，發到線上掛了，那麼你寫的東西就是垃圾，連最基礎的穩定性都保證不了，更別說流暢性，高併發。
初級工程師只管接需求，高級工程師會砍需求
經常看到很多初級工程師就是，不管產品、運營甚至後端提出一些需求，他也很友好，只要是需求，他都接，然後整天忙忙碌碌，還經常加班，但是實際上，很多需求做了沒有什麼價值，也許還有些是重複工作，還把自己搞得很辛苦，這種情況真的很多很多。
然後還有一種情況是有一個產品需求來了，然後 balabala 一頓需求討論之後，產品給出一個期限，初級工程師滿打滿算，可能能完成，然後就說能行，結果要麼對自己能力估算錯誤，要麼很多突發情況，然後不能按時上線。
而高級工程師基本上不會出現不能按時上線的情況，我思考了幾點原因：
- 會給自己留 buffer，來避免突發情況導致時間的耽擱。
- 在需求分析的時候會思考每個需求是否有必要，如果有些需求覺得沒必要，會和產品討論，拿出充分的理由 將需求砍掉。如果都有必要，然後時間又不太夠，會去和產品談是否能使交互簡單一下，一期先出個什麼樣子，下一期再做完整一點。
- 對需求的評估以及自己能力的評估更準確。
這裡我想要表達，不是所有的需求都是有必要的，不要每個需求都去接。
那麼如果來判斷一個需求是否應該接呢？
我覺得主要是去思考他背後的價值，為什麼要做這個東西，做了能達到什麼樣的效果，如果產品說不出來價值，或者說產生的價值與你花費的時間不匹配，那麼這個需求就是有待商討的。
初級多在解決一個問題，高級多在解決一類問題
很多初級工程師可能昨晚一個項目就完了，還覺得很 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 遇到難題不主動反饋