之前在公眾號(hào)里有個(gè)讀者給我留言：

請(qǐng)教個(gè)問(wèn)題，公司高職級(jí)和初中級(jí)，都是寫(xiě)業(yè)務(wù)代碼，那么高職級(jí)的價(jià)值在哪里呢？

由于公眾號(hào)回復(fù)留言的限制，當(dāng)時(shí)我就簡(jiǎn)單的回復(fù)了如下的幾個(gè)點(diǎn)：

• 初級(jí)多在寫(xiě)代碼，高級(jí)多在設(shè)計(jì)代碼；
• 初級(jí)多在解決一個(gè)問(wèn)題，高級(jí)多在解決一類問(wèn)題；
• 初級(jí)多在考慮技術(shù)問(wèn)題，高級(jí)還要參與業(yè)務(wù)上的需求；
• 初級(jí)工程師只管接需求，導(dǎo)致自己忙不過(guò)來(lái)，高級(jí)工程師會(huì)砍需求， 用自己得經(jīng)驗(yàn)告訴產(chǎn)品這個(gè)需求不需要，告訴設(shè)計(jì)師這個(gè)交互沒(méi)必要；
• 初級(jí)工程師可能做完一個(gè)項(xiàng)目就完了，高級(jí)工程師可能會(huì)封裝幾個(gè)組件，整理一個(gè)腳手架出來(lái)。

還有很多很多，初級(jí)工程師和高級(jí)工程師差距不僅僅是代碼質(zhì)量上，而且其他能力上，解決問(wèn)題的能力，抽象問(wèn)題的能力！

今天有時(shí)間，想詳細(xì)的跟大家談?wù)勎宜龅降摹⒁?jiàn)到的厲害的程序員，同樣是寫(xiě)業(yè)務(wù)代碼，為什么會(huì)比初級(jí)程序員拿的工資高？

初級(jí)多在寫(xiě)代碼，高級(jí)多在設(shè)計(jì)代碼

一般人可能拿到需求，就開(kāi)始寫(xiě)代碼了，寫(xiě)著寫(xiě)著由于頁(yè)面功能越來(lái)越多，感覺(jué)代碼越來(lái)越復(fù)雜，自己都會(huì)覺(jué)得難以維護(hù)了。

我拿我自己舉個(gè)例子，之前有一次我寫(xiě)完一個(gè)頁(yè)面之后，然后給另外一個(gè)同事(可以理解為高級(jí)程序員)讓他幫我 Review 代碼，看到我的代碼之后就覺(jué)得這個(gè)寫(xiě)得不對(duì)呀，怎么會(huì)這么去設(shè)計(jì)呢？

然后他給我理了下整個(gè)頁(yè)面應(yīng)該如何去設(shè)計(jì)，一個(gè)頁(yè)面分為哪些塊，有哪些事件，每個(gè)事件應(yīng)該 dispatch 哪些 action，然后整個(gè)模塊有哪些數(shù)據(jù)放在 store 里，哪些模塊放在 state 里，當(dāng)時(shí)反正聽(tīng)他理完之后，感覺(jué)自己寫(xiě)的代碼真的很垃圾，然后花了兩天時(shí)間把上周寫(xiě)的代碼重寫(xiě)了一邊。

注意，這里是重寫(xiě)，不是重構(gòu)，重構(gòu)是對(duì)軟件內(nèi)部結(jié)構(gòu)的一種調(diào)轉(zhuǎn)，目的是不改變軟件可觀察行為的前提下，提高其可理解性，降低其修改成本。那么如果保證不改變軟件可觀察行為呢？就需要寫(xiě)測(cè)試用例，保證測(cè)試用例能跑通的情況下進(jìn)行重新構(gòu)造代碼才是重構(gòu)的第一步，沒(méi)有測(cè)試用例的重構(gòu)就是耍流氓。

那么如何提高設(shè)計(jì)代碼的能力呢？

我覺(jué)得有一個(gè)方法對(duì)于提高設(shè)計(jì)代碼的能力非常有幫助，那就是采用 TDD(測(cè)試驅(qū)動(dòng)開(kāi)發(fā))。

TDD 的原理是在開(kāi)發(fā)功能代碼之前，先編寫(xiě)單元測(cè)試用例代碼，測(cè)試代碼確定需要編寫(xiě)什么產(chǎn)品代碼。 --來(lái)源百度百科

為什么 TDD 會(huì)提高設(shè)計(jì)代碼的能力呢？可以看到 TDD 的原理是要在寫(xiě)代碼之前就要寫(xiě)測(cè)試用例，在寫(xiě)測(cè)試用例的時(shí)候你必然得去思考你的每個(gè)函數(shù)，每個(gè)模塊，每個(gè)組件應(yīng)該如何去設(shè)計(jì)才能使得易于測(cè)試，往往易于測(cè)試的代碼都比較好維護(hù)。

這就可以達(dá)到在寫(xiě)代碼之前先去設(shè)計(jì)代碼，然后才寫(xiě)代碼，也就是先思考，后行動(dòng)。

我只是說(shuō) TDD 可以提高設(shè)計(jì)代碼的能力，并沒(méi)有說(shuō)我就特別提倡 TDD，說(shuō) TDD 很麻煩，難以實(shí)施的人就不要跟我討論了。

初級(jí)多在考慮技術(shù)問(wèn)題，高級(jí)還要思考業(yè)務(wù)上的需求

我們要知道，技術(shù)是為業(yè)務(wù)服務(wù)的，沒(méi)有業(yè)務(wù)談技術(shù)的好壞都是瞎扯淡！

常常可以看到很多實(shí)習(xí)生，或者剛來(lái)的應(yīng)屆生會(huì)吐槽以前的老代碼用的框架老，用的技術(shù)舊，然后就去改成新的，自己覺(jué)得牛逼的，然后沒(méi)有多個(gè)環(huán)境測(cè)試，發(fā)上線就掛了，這種例子很多很多，別說(shuō)我們公司，就連我們組都出現(xiàn)過(guò)好幾次這樣的情況了。

這種就是只考慮技術(shù)問(wèn)題的，而沒(méi)有去考慮為什么以前前人要這么寫(xiě)，前人沒(méi)有用這些東西，難道僅僅是因?yàn)槟莻€(gè)時(shí)候沒(méi)有新東西，或者說(shuō)認(rèn)為前人比你差。

很可能就是他們考慮到了業(yè)務(wù)上的需求，比如要兼容 IE、或者比如考慮到了有很多用戶用 iOS，Safari 不支持 webp ，或者比如考慮到很多用戶是低端機(jī)，性能不好，不能用一些新特性等等問(wèn)題。

對(duì)于老板來(lái)說(shuō)，他根本不管你用什么新技術(shù)，新特性，也許你用了新特性確實(shí)讓代碼更簡(jiǎn)潔了，但是，但是，但是，發(fā)到線上掛了，那么你寫(xiě)的東西就是垃圾，連最基礎(chǔ)的穩(wěn)定性都保證不了，更別說(shuō)流暢性，高并發(fā)。

初級(jí)工程師只管接需求，高級(jí)工程師會(huì)砍需求

經(jīng)常看到很多初級(jí)工程師就是，不管產(chǎn)品、運(yùn)營(yíng)甚至后端提出一些需求，他也很友好，只要是需求，他都接，然后整天忙忙碌碌，還經(jīng)常加班，但是實(shí)際上，很多需求做了沒(méi)有什么價(jià)值，也許還有些是重復(fù)工作，還把自己搞得很辛苦，這種情況真的很多很多。

然后還有一種情況是有一個(gè)產(chǎn)品需求來(lái)了，然后 balabala 一頓需求討論之后，產(chǎn)品給出一個(gè)期限，初級(jí)工程師滿打滿算，可能能完成，然后就說(shuō)能行，結(jié)果要么對(duì)自己能力估算錯(cuò)誤，要么很多突發(fā)情況，然后不能按時(shí)上線。

而高級(jí)工程師基本上不會(huì)出現(xiàn)不能按時(shí)上線的情況，我思考了幾點(diǎn)原因：

會(huì)給自己留 buffer，來(lái)避免突發(fā)情況導(dǎo)致時(shí)間的耽擱。

在需求分析的時(shí)候會(huì)思考每個(gè)需求是否有必要，如果有些需求覺(jué)得沒(méi)必要，會(huì)和產(chǎn)品討論，拿出充分的理由將需求砍掉。如果都有必要，然后時(shí)間又不太夠，會(huì)去和產(chǎn)品談是否能使交互簡(jiǎn)單一下，一期先出個(gè)什么樣子，下一期再做完整一點(diǎn)。

對(duì)需求的評(píng)估以及自己能力的評(píng)估更準(zhǔn)確。

這里我想要表達(dá)，不是所有的需求都是有必要的，不要每個(gè)需求都去接。

那么如果來(lái)判斷一個(gè)需求是否應(yīng)該接呢？

我覺(jué)得主要是去思考他背后的價(jià)值，為什么要做這個(gè)東西，做了能達(dá)到什么樣的效果，如果產(chǎn)品說(shuō)不出來(lái)價(jià)值，或者說(shuō)產(chǎn)生的價(jià)值與你花費(fèi)的時(shí)間不匹配，那么這個(gè)需求就是有待商討的。

初級(jí)多在解決一個(gè)問(wèn)題，高級(jí)多在解決一類問(wèn)題

很多初級(jí)工程師可能昨晚一個(gè)項(xiàng)目就完了，還覺(jué)得很 OK 呀，然后也把在項(xiàng)目中的問(wèn)題一個(gè)一個(gè)的解決了，按時(shí)按量的完成了任務(wù)。

對(duì)，這就是初級(jí)工程師的標(biāo)準(zhǔn)，能完成一個(gè)項(xiàng)目。

那么對(duì)于高級(jí)工程師除了完成項(xiàng)目還會(huì)做什么呢？

也許會(huì)封裝幾個(gè)公用組件發(fā)到 npm 上大家都可以用。

也許會(huì)整理一個(gè)腳手架出來(lái)大家用，比如以前公司沒(méi)有用 TS，那么用 TS 寫(xiě)完項(xiàng)目之后，踩了很多坑，你就可以整理出一個(gè)腳手架，然后把踩得坑記錄下來(lái)，方便后面想用 TS 的人用。

也許發(fā)現(xiàn)前端工程師還原 UI 搞是一件枯燥無(wú)味，而且沒(méi)有技術(shù)含量的事兒，我司有個(gè)大佬就寫(xiě)了一個(gè) UI2Code 的工具，可以將 Sketch 文件轉(zhuǎn)化為 html 代碼。

也許高級(jí)工程師發(fā)現(xiàn)一上線一個(gè)功能，小程序和 H5 都要寫(xiě)一套一模一樣的，然后我司大佬就寫(xiě)了一個(gè)可以將 vue 代碼轉(zhuǎn)換為小程序的框架，一套 vue 代碼，h5 和小程序都能用。

這些都是我身邊的例子，可以看到高級(jí)工程師經(jīng)常解決的不是一個(gè)問(wèn)題，而是解決一類通用的問(wèn)題，然后給出解決方案，并且得以實(shí)施，從來(lái)不會(huì)認(rèn)為吧項(xiàng)目做完了就完了，沒(méi)有一點(diǎn)產(chǎn)出，也許你做這個(gè)項(xiàng)目是對(duì)自己太大的幫助，成長(zhǎng)的。

初級(jí)程序員經(jīng)常犯的錯(cuò)誤集錦

然后我在知乎上看到了一個(gè)初級(jí)程序員經(jīng)常犯的錯(cuò)誤集錦，我覺(jué)得非常大家都可以看看，自己有沒(méi)有這些毛病。

1 命名不規(guī)范

2 日志不規(guī)范

3 拒絕寫(xiě)接口和假數(shù)據(jù)

4 不寫(xiě)單元測(cè)試

5 盲目集成

6 邏輯不清

7 不做方案

8 不關(guān)注性能

9 害怕重構(gòu)

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

11 不考慮未來(lái)需求的變化

12 遇到問(wèn)題的時(shí)候不會(huì)試錯(cuò)

13 不會(huì)寫(xiě)偽代碼

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

15 提交代碼不規(guī)范

16 不喜歡打Tag

17 不遵守發(fā)布流程

18 不知道Bug修復(fù)的優(yōu)先級(jí)

19 總喜歡手動(dòng)修改線上代碼

20 不做數(shù)據(jù)備份

21 不做自測(cè)

22 不盡力模仿真實(shí)數(shù)據(jù)，測(cè)試數(shù)據(jù)很隨意

23 不抽取公共代碼

24 不認(rèn)真聽(tīng)需求講解

25 不看驗(yàn)收標(biāo)準(zhǔn)

26 不主動(dòng)推進(jìn)項(xiàng)目進(jìn)度

27 遇到難題不主動(dòng)反饋

作者：暗滅鏈接：https://www.zhihu.com/question/33578621/answer/451931102

總結(jié)

初級(jí)程序員主要是體現(xiàn)在目光短淺，缺乏思考，做完?yáng)|西沒(méi)有成果，不積極主動(dòng)。

而高級(jí)程序員不僅僅是代碼寫(xiě)得好，寫(xiě)得快，確實(shí)思考得更長(zhǎng)遠(yuǎn)，做的東西更有用。

我列舉我身邊所遇到的高級(jí)程序員所做的事，我覺(jué)得更有說(shuō)服力，不是空談大道理，都是我從身邊的大佬們身上學(xué)到的，希望能給剛?cè)肼殘?chǎng)，或者感覺(jué)自己是個(gè)初級(jí)程序員的程序員們一些警惕。

當(dāng)然，上面所說(shuō)的高級(jí)工程師所擁有的優(yōu)點(diǎn)和初級(jí)工程師的缺點(diǎn)，都不是所有高級(jí)工程師都會(huì)有所有的這些優(yōu)點(diǎn)，也不是所有的初級(jí)工程師都具有這些缺點(diǎn)，這是沒(méi)辦法進(jìn)行定量的。

你們身邊還遇到什么高級(jí)工程師的特點(diǎn)，或者初級(jí)工程師的缺點(diǎn)，歡迎在評(píng)論區(qū)里面留言。

總結(jié)

以上是生活随笔為你收集整理的高级程序员与初级程序员差别在哪里？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。