請教個問題，公司高職級和初中級，都是寫業務代碼，那么高職級的價值在哪里呢？
-
初級多在寫代碼，高級多在設計代碼；
-
初級多在解決一個問題，高級多在解決一類問題；
-
初級多在考慮技術問題，高級還要參與業務上的需求；
-
初級工程師只管接需求，導致自己忙不過來，高級工程師會砍需求， 用自己得經驗告訴產品這個需求不需要，告訴設計師這個交互沒必要；
-
初級工程師可能做完一個項目就完了，高級工程師可能會封裝幾個組件，整理一個腳手架出來。
還有很多很多，初級工程師和高級工程師差距不僅僅是代碼質量上，而且其他能力上，解決問題的能力，抽象問題的能力！
今天有時間，想詳細的跟大家談談我所遇到的、見到的厲害的程序員，同樣是寫業務代碼，為什么會比初級程序員拿的工資高？
初級多在寫代碼，高級多在設計代碼
一般人可能拿到需求，就開始寫代碼了，寫着寫着由於頁面功能越來越多，感覺代碼越來越復雜，自己都會覺得難以維護了。
我拿我自己舉個例子，之前有一次我寫完一個頁面之后，然后給另外一個同事(可以理解為高級程序員)讓他幫我 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 遇到難題不主動反饋
作者：暗滅鏈接：https://www.zhihu.com/question/33578621/answer/451931102
總結
初級程序員主要是體現在目光短淺，缺乏思考，做完東西沒有成果，不積極主動。
而高級程序員不僅僅是代碼寫得好，寫得快，確實思考得更長遠，做的東西更有用。
我列舉我身邊所遇到的高級程序員所做的事，我覺得更有說服力，不是空談大道理，都是我從身邊的大佬們身上學到的，希望能給剛入職場，或者感覺自己是個初級程序員的程序員們一些警惕。
當然，上面所說的高級工程師所擁有的優點和初級工程師的缺點，都不是所有高級工程師都會有所有的這些優點，也不是所有的初級工程師都具有這些缺點，這是沒辦法進行定量的。
你們身邊還遇到什么高級工程師的特點，或者初級工程師的缺點