1. 寫在前面為什么要分享這條路這個(gè)標(biāo)題看起來平平無奇但我實(shí)實(shí)在在地想把它寫給每一位正在屏幕前猶豫、焦慮、或者正準(zhǔn)備轉(zhuǎn)行做技術(shù)的同學(xué)。我是從二流院校本科畢業(yè)第一份工作在一家不到二十人的小公司從寫后端接口到部署服務(wù)器再從帶小團(tuán)隊(duì)到做技術(shù)負(fù)責(zé)人前前后后折騰了快十年。今天這篇文章不吹不黑不講那些天賦異稟三個(gè)月進(jìn)大廠的神話只講一個(gè)普通人怎么靠方法和堅(jiān)持一步步走穩(wěn)工程師這條路。很多人問過我最多的一句話是現(xiàn)在入行還來得及嗎我的回答從來都是同一句——工程師這個(gè)職業(yè)拼的不是天賦而是學(xué)習(xí)能力和解決問題的耐心。你可以沒有名校背景可以沒有競(jìng)賽獎(jiǎng)項(xiàng)但你必須有一份獨(dú)立把事做成、把問題拆開、把代碼跑起來的能力。這篇文章適合剛?cè)腴T的學(xué)生、正在找工作的應(yīng)屆生、想轉(zhuǎn)行做技術(shù)的朋友也適合剛工作兩三年、正在迷茫期的初中級(jí)工程師參考。我會(huì)從成長(zhǎng)路線的整體規(guī)劃、技術(shù)棧和學(xué)習(xí)方法、從學(xué)生到職場(chǎng)人的關(guān)鍵轉(zhuǎn)變、軟技能提升以及我踩過的那些坑五個(gè)方面展開盡量講得具體、可落地每一條都有實(shí)際案例支撐。你有時(shí)間可以一口氣讀完沒時(shí)間可以先收藏按章節(jié)對(duì)照自己的階段去查漏補(bǔ)缺。2. 工程師成長(zhǎng)的整體認(rèn)知與路徑設(shè)計(jì)2.1 工程師的四個(gè)成長(zhǎng)階段你現(xiàn)在在哪一步很多新手對(duì)工程師職業(yè)最大的誤解就是覺得“寫好代碼好工程師”。實(shí)際上代碼能力只是工程師能力的其中一個(gè)維度。我更喜歡把工程師的成長(zhǎng)分成四個(gè)階段你可以拿這個(gè)框架來對(duì)照自己當(dāng)前的位置。第一階段是執(zhí)行者也就是剛?cè)肼殘?chǎng)的1-3年。這個(gè)階段的核心任務(wù)是把交代的任務(wù)做好代碼寫得清晰、可靠能按時(shí)交付。你不需要操心架構(gòu)設(shè)計(jì)也不需要對(duì)業(yè)務(wù)結(jié)果負(fù)責(zé)但需要養(yǎng)成好的編碼習(xí)慣和嚴(yán)謹(jǐn)?shù)墓こ藤|(zhì)量意識(shí)。第二階段是解決者大致對(duì)應(yīng)工作3-5年。這個(gè)階段你不再只被動(dòng)的執(zhí)行者而是開始主動(dòng)思考“為什么這樣做”“有沒有更好的方案”。你會(huì)承擔(dān)模塊級(jí)別的設(shè)計(jì)工作開始參與技術(shù)選型、接口設(shè)計(jì)、性能優(yōu)化也需要具備在沒人指導(dǎo)的情況下獨(dú)立排查問題的能力。第三階段是賦能者大概5-8年。這時(shí)候你的產(chǎn)出不再只是你自己寫了多少代碼而是你能讓整個(gè)團(tuán)隊(duì)產(chǎn)出的效率和質(zhì)量提升多少?？赡苁悄阍O(shè)計(jì)了一套代碼規(guī)范可能是你推動(dòng)了一個(gè)工具鏈的建設(shè)也可能只是你沉淀了一套團(tuán)隊(duì)內(nèi)部的排障手冊(cè)。衡量標(biāo)準(zhǔn)從“我能寫多快”變成了“團(tuán)隊(duì)能寫多快”。第四階段是骨干或?qū)＜?年以上。這類人往往是團(tuán)隊(duì)里最后兜底的那個(gè)。別人解決不了的問題你來解決別人看不清楚的方向你來判斷。你可能不寫太多業(yè)務(wù)代碼但你對(duì)系統(tǒng)的理解、對(duì)風(fēng)險(xiǎn)的前瞻判斷對(duì)團(tuán)隊(duì)來說是不可替代的。這個(gè)框架不是我自己瞎編的很多技術(shù)管理類的書里都有類似模型。關(guān)鍵是你要知道每個(gè)階段的核心目標(biāo)是不一樣的如果你都工作5年了還在拿“我加班多、代碼寫得快”來說事那說明你還在第一階段原地打轉(zhuǎn)這時(shí)候就該有意識(shí)地往更高階段去跨越了。2.2 廣度優(yōu)先還是深度優(yōu)先一個(gè)矛盾的平衡題幾乎每一個(gè)人都問過我我應(yīng)該先在某個(gè)方向挖得很深還是什么東西都了解一點(diǎn)這個(gè)問題沒有標(biāo)準(zhǔn)答案取決于你處在哪個(gè)階段以及你的目標(biāo)是什么。我的建議是前三年以深度為主廣度做輔助補(bǔ)充3年后再根據(jù)職業(yè)方向逐步打開廣度。為什么這么說因?yàn)樯疃仁悄憬I(yè)自信、獲得第一份認(rèn)可的基礎(chǔ)。一個(gè)剛畢業(yè)的新人如果能在一個(gè)技術(shù)點(diǎn)上鉆研得比周圍人都透比如把MySQL的索引優(yōu)化玩明白或者把JVM的調(diào)優(yōu)參數(shù)研究清楚你就有了自己的標(biāo)簽和差異化優(yōu)勢(shì)。公司面試時(shí)需要的也正是這種“在某一點(diǎn)上拿得出手”的人。三年之后你開始帶項(xiàng)目、帶新人這時(shí)候廣度就開始變得重要了。你需要理解前端同事在說什么需要知道運(yùn)維那邊的部署流程需要了解產(chǎn)品經(jīng)理為什么要做這個(gè)功能。廣度不是讓你每個(gè)領(lǐng)域都成為專家而是你要有足夠的知識(shí)儲(chǔ)備去理解協(xié)作方和判斷全局。我踩過的一個(gè)反面例子是工作前五年我始終悶頭寫后端代碼對(duì)前端的知識(shí)近乎空白。結(jié)果有一次要獨(dú)立負(fù)責(zé)一個(gè)全棧小項(xiàng)目前端部分完全抓瞎臨時(shí)抱佛腳學(xué)了半個(gè)月Vue交付質(zhì)量慘不忍睹。那次經(jīng)歷讓我認(rèn)識(shí)到廣度不是用來炫耀的而是為了在跨團(tuán)隊(duì)協(xié)作和獨(dú)立交付時(shí)不自斷一臂。2.3 目標(biāo)導(dǎo)向的反推法先看終點(diǎn)再定路線做職業(yè)規(guī)劃最容易犯的錯(cuò)誤是一頭扎進(jìn)學(xué)習(xí)里學(xué)到哪算哪。但更高效的方式是從目標(biāo)反推路徑。你要先想清楚三五年后你想成為一個(gè)什么樣的人是想做技術(shù)專家還是想走技術(shù)管理路線或者是想自己創(chuàng)業(yè)做獨(dú)立開發(fā)者這三個(gè)方向?qū)δ芰?cè)重點(diǎn)的要求是很不一樣的。技術(shù)專家路線核心要打磨的是單點(diǎn)深度、源碼閱讀能力、系統(tǒng)設(shè)計(jì)能力技術(shù)管理路線更看重的是溝通能力、項(xiàng)目管理能力和業(yè)務(wù)敏感度獨(dú)立開發(fā)路線則要求你具備全棧能力、產(chǎn)品思維和運(yùn)營推廣的基礎(chǔ)認(rèn)知。你可以用一張紙把目標(biāo)拆解成“能力清單”再對(duì)照清單去決定每一階段要學(xué)什么、做什么項(xiàng)目、補(bǔ)什么短板。我當(dāng)時(shí)給自己定的中期目標(biāo)是“三年內(nèi)成為團(tuán)隊(duì)里后端最靠譜的人”。于是我把目標(biāo)拆成了三個(gè)部分一是把Java語言本身和JVM機(jī)制吃透二是把數(shù)據(jù)庫和緩存相關(guān)的高頻問題掌握扎實(shí)三是至少完整參與兩次從零到一的項(xiàng)目開發(fā)。事實(shí)證明這個(gè)拆解方向?qū)髞淼拿嬖嚭蛯?shí)際工作幫助都很大因?yàn)槊嬖嚬賳柕降膬?nèi)容幾乎都能映射到我當(dāng)時(shí)設(shè)定的能力清單上。3. 技術(shù)棧選擇與高效學(xué)習(xí)方法3.1 語言和方向怎么選興趣不是唯一標(biāo)準(zhǔn)很多人在入門時(shí)會(huì)糾結(jié)我應(yīng)該學(xué)Java、Python、Go還是前端、后端、算法我的建議是不要單純憑興趣來選而是結(jié)合三個(gè)維度去判斷。第一是市場(chǎng)供需。你可以在招聘網(wǎng)站上看一看你所在城市或者你想去的城市哪種崗位需求量最大、招聘門檻最友好。第二是技術(shù)生態(tài)。生態(tài)豐富意味著你遇到問題時(shí)更容易搜到答案也更容易找到成熟的第三方庫。第三是遷移成本。不同語言之間不是完全互通的但編程思維是相通的。其實(shí)你先熟練掌握一門語言的核心機(jī)制再學(xué)第二門時(shí)會(huì)快很多。有一個(gè)很現(xiàn)實(shí)的規(guī)律是后端開發(fā)崗位的需求量長(zhǎng)期穩(wěn)定Java在國內(nèi)的生態(tài)和崗位量都很龐大Go在云原生領(lǐng)域增長(zhǎng)很快Python在數(shù)據(jù)分析、人工智能方向占優(yōu)勢(shì)。前端領(lǐng)域React和Vue兩分天下。算法崗門檻高、崗位數(shù)量相對(duì)有限。如果你目標(biāo)是盡快入行、穩(wěn)住職業(yè)基本盤我建議從后端開發(fā)入手Java或Go任選其一如果你對(duì)界面、交互更有興趣前端也是不錯(cuò)的選擇。我不建議一上來就選一個(gè)非常小眾的冷門方向比如某些偏門框架或者深耕多年的專屬語言除非你確實(shí)有平臺(tái)資源和堅(jiān)定的信念。對(duì)于大多數(shù)普通人來說選擇市場(chǎng)驗(yàn)證過的成熟路線是降低風(fēng)險(xiǎn)最樸素的手段。3.2 學(xué)習(xí)中的三大方法費(fèi)曼、刻意練習(xí)和項(xiàng)目驅(qū)動(dòng)可能你已經(jīng)聽過很多學(xué)習(xí)方法論了但真正有效的就那幾樣我把它們串成一套適合工程師的組合拳。首先我用得最多的是費(fèi)曼學(xué)習(xí)法。具體操作是每學(xué)完一個(gè)重要知識(shí)點(diǎn)比如“TCP三次握手為什么是三次”我就假設(shè)自己正在給一個(gè)完全不懂的人講這個(gè)概念用大白話寫在文檔里如果講到一半卡住了說明這個(gè)知識(shí)點(diǎn)我還沒真懂就回去重新查資料。后來這個(gè)習(xí)慣延伸成了我寫作和培訓(xùn)分享的底層能力對(duì)加深理解效果顯著。其次是刻意練習(xí)。工程師的刻意練習(xí)不是一遍一遍寫hello world而是針對(duì)自己的薄弱點(diǎn)做專項(xiàng)訓(xùn)練。比如你覺得SQL查詢優(yōu)化不行那就不要混在日常業(yè)務(wù)代碼里隨意寫而是專門花一個(gè)周末找10道不同類型的慢查詢案例一道一道分析執(zhí)行計(jì)劃、調(diào)整索引、驗(yàn)證效果。這種針對(duì)性練習(xí)的產(chǎn)出速度和效果遠(yuǎn)好于漫無目的地刷視頻課。最后是項(xiàng)目驅(qū)動(dòng)學(xué)習(xí)?？磿匆曨l學(xué)到的東西都是“假性掌握”只有當(dāng)你真的做出一個(gè)能跑起來的系統(tǒng)時(shí)那些知識(shí)才真正屬于你。你可以定一個(gè)目標(biāo)比如“做一個(gè)帶用戶注冊(cè)、登錄、發(fā)帖、評(píng)論功能的小社區(qū)”然后在這個(gè)項(xiàng)目里主動(dòng)加入你剛學(xué)會(huì)的技術(shù)點(diǎn)比如用Redis做會(huì)話緩存、用消息隊(duì)列做通知異步化。一個(gè)完整的項(xiàng)目做下來你掌握的內(nèi)容跨度可能比看十本書還要大。3.3 我需要看書嗎視頻、文檔和源碼怎么配合市面上學(xué)習(xí)資料太多很多同學(xué)陷入“收藏從未停止學(xué)習(xí)從未開始”的怪圈。我的經(jīng)驗(yàn)是不同類型的資料有不同的用途關(guān)鍵是要配合使用而不是只依賴其中一種。視頻課適合入門和建立整體認(rèn)知尤其是那些由一線工程師錄制的實(shí)戰(zhàn)課可以幫你快速了解一個(gè)領(lǐng)域的全貌。但視頻課的缺點(diǎn)是信息密度偏低容易讓人產(chǎn)生“我聽懂了我會(huì)了”的錯(cuò)覺所以看完一個(gè)章節(jié)后必須立刻動(dòng)手寫代碼驗(yàn)證。官方文檔是最權(quán)威的參考資料但新手直接讀文檔往往抓不住重點(diǎn)建議把它當(dāng)“字典”來查而不是當(dāng)“教材”來啃。源碼閱讀是進(jìn)階階段的重要功課不要從那些巨型項(xiàng)目開始讀而是從你日常使用的小型開源庫入手比如一個(gè)JSON解析庫、一個(gè)HTTP客戶端庫代碼量幾千行的規(guī)模剛剛好。我的習(xí)慣是“視頻入門文檔查證源碼深化”三步走。比如學(xué)一個(gè)新框架先花兩三天看一個(gè)不錯(cuò)的實(shí)戰(zhàn)視頻對(duì)整體流程有個(gè)概念接下來在工作中實(shí)際使用時(shí)遇到問題第一時(shí)間查官方文檔等用熟了之后再挑一兩個(gè)核心模塊去看源碼實(shí)現(xiàn)理解框架設(shè)計(jì)者的思路。這樣一輪下來你對(duì)這個(gè)技術(shù)的掌握程度就會(huì)明顯超過平均水平。4. 從學(xué)生到工程師求職與入職實(shí)戰(zhàn)解析4.1 簡(jiǎn)歷不是履歷流水賬用項(xiàng)目結(jié)果說話很多應(yīng)屆生和轉(zhuǎn)行同學(xué)寫簡(jiǎn)歷最大的問題就是把自己做過的事寫成了崗位JD職位描述比如“負(fù)責(zé)XX系統(tǒng)的開發(fā)與維護(hù)”這類描述幾乎沒有信息量。正確的寫法是以項(xiàng)目為單元用結(jié)果說話讓面試官一眼就看出你做了什么、做到了什么程度。我建議簡(jiǎn)歷里的每個(gè)項(xiàng)目都按四層結(jié)構(gòu)來寫項(xiàng)目背景為什么做、你的職責(zé)具體負(fù)責(zé)哪塊、技術(shù)方案用了什么技術(shù)、怎么設(shè)計(jì)的、結(jié)果數(shù)據(jù)性能提升多少、支撐多大訪問量、上線后穩(wěn)定性如何。舉個(gè)例子與其寫“負(fù)責(zé)用戶模塊開發(fā)”不如寫成“設(shè)計(jì)并實(shí)現(xiàn)了用戶注冊(cè)登錄模塊基于Spring Security整合JWT實(shí)現(xiàn)無狀態(tài)鑒權(quán)支持每日約2萬新增用戶登錄接口平均響應(yīng)時(shí)間低于200毫秒”。此外簡(jiǎn)歷上不要寫與自己能力不匹配的內(nèi)容。面試官順著你的簡(jiǎn)歷深挖時(shí)一旦發(fā)現(xiàn)你寫的技術(shù)棧自己根本講不清楚比不寫扣分還嚴(yán)重。你寫在簡(jiǎn)歷上的每一條都要準(zhǔn)備好被追問到細(xì)節(jié)這個(gè)原則我面試過很多人屢試不爽也幫你篩掉了大量靠包裝簡(jiǎn)歷混進(jìn)來的候選人。4.2 面試準(zhǔn)備八股文之外更要練系統(tǒng)設(shè)計(jì)國內(nèi)技術(shù)面試比較看重基礎(chǔ)知識(shí)和“八股文”式的問題比如HashMap原理、并發(fā)機(jī)制、TCP握手等等。這些當(dāng)然要準(zhǔn)備但我想提醒你的是只背八股文是不夠的現(xiàn)在越來越多的公司在面試中加入了系統(tǒng)設(shè)計(jì)題比如“如果讓你設(shè)計(jì)一個(gè)短鏈接系統(tǒng)你會(huì)怎么做”。這類題目考的不是你會(huì)不會(huì)某個(gè)API而是你分析問題、拆分模塊、權(quán)衡方案的綜合能力。準(zhǔn)備這類問題可以先從一套固定的答題框架練起先澄清需求預(yù)估QPS是多少數(shù)據(jù)量多大再做模塊拆分短鏈接生成、存儲(chǔ)、跳轉(zhuǎn)、統(tǒng)計(jì)再選型存儲(chǔ)MySQL還是Redis是否需要緩存最后補(bǔ)充容災(zāi)和擴(kuò)展方案。哪怕你最終的方案不完美只要邏輯清晰、考慮全面面試官也會(huì)給你不錯(cuò)的評(píng)價(jià)。面完試之后一定要做復(fù)盤。把面試中被問到的問題記錄下來挨個(gè)查漏補(bǔ)缺。我當(dāng)年準(zhǔn)備了一套“錯(cuò)題本”把每一次面試答得不好的問題都整理成一篇筆記。幾輪面試下來這套錯(cuò)題本的價(jià)值甚至超過了專門的復(fù)習(xí)資料因?yàn)樗峭耆槍?duì)你個(gè)人薄弱點(diǎn)的定制化方案。4.3 入職第一年如何快速建立信任和存在感順利拿到offer只是開始入職后的前半年才是決定你在團(tuán)隊(duì)位置上限的關(guān)鍵階段。很多新人入職后容易犯兩個(gè)極端一個(gè)是太靦腆有問題不敢問自己悶頭憋三天另一個(gè)是太冒進(jìn)沒理解需求和歷史背景就亂提重構(gòu)方案。這兩個(gè)極端都會(huì)讓團(tuán)隊(duì)對(duì)你產(chǎn)生不信任。我的建議是入職頭一個(gè)月先別急著表現(xiàn)重點(diǎn)做三件事第一把項(xiàng)目代碼從入口到出口完整走讀一遍畫一張架構(gòu)圖第二把團(tuán)隊(duì)的技術(shù)文檔、需求文檔、排期流程都看一遍理解團(tuán)隊(duì)怎么協(xié)作第三找到團(tuán)隊(duì)里最靠譜的1-2個(gè)同事建立良好溝通關(guān)系遇到問題先自己想超過30分鐘想不出來再找他們溝通。等入職一個(gè)月后你可以開始主動(dòng)爭(zhēng)取一些“小而確定性高”的任務(wù)比如修一個(gè)無關(guān)緊要的bug、補(bǔ)充一個(gè)單元測(cè)試、優(yōu)化一處代碼注釋。這些小事技術(shù)含量不高但能幫你積累團(tuán)隊(duì)的信任積分。記住一個(gè)樸素的道理團(tuán)隊(duì)只有先相信你能做好小事才會(huì)放心讓你做大事。這個(gè)信任積累的過程急不來但一旦建立了你后續(xù)的成長(zhǎng)速度會(huì)非常快。5. 軟技能與工程素養(yǎng)決定你能走多遠(yuǎn)的隱藏因素5.1 溝通能力工程師最容易忽略的必修課技術(shù)圈有個(gè)普遍的現(xiàn)象很多工程師技術(shù)能力很強(qiáng)但一到跨部門溝通就抓瞎要么沉默不語要么說話全是術(shù)語對(duì)方根本聽不懂。你在職業(yè)生涯初期可能感受不到溝通能力的價(jià)值但到了帶項(xiàng)目、做技術(shù)方案的階段溝通能力的差距會(huì)被急劇放大。我自己的體會(huì)是工程師溝通中最重要的一件事是區(qū)分事實(shí)和觀點(diǎn)。討論技術(shù)方案的時(shí)候不要只說“我覺得這樣好”而是要把依據(jù)列出來這個(gè)方案的優(yōu)勢(shì)是什么代價(jià)是什么對(duì)比其他方案的差異在哪里可能出現(xiàn)什么風(fēng)險(xiǎn)。用數(shù)據(jù)和事實(shí)說話不僅能減少無謂的爭(zhēng)論還能讓團(tuán)隊(duì)更愿意采納你的方案。另一個(gè)實(shí)用的技巧是面向聽眾調(diào)整表達(dá)方式。跟技術(shù)同事討論可以放開了聊技術(shù)細(xì)節(jié)跟產(chǎn)品經(jīng)理溝通重點(diǎn)說清“能做到什么效果、需要多少時(shí)間、有什么風(fēng)險(xiǎn)”跟非技術(shù)背景的領(lǐng)導(dǎo)匯報(bào)就只講結(jié)論和關(guān)鍵數(shù)據(jù)細(xì)節(jié)放到附錄里。這個(gè)能力看起來簡(jiǎn)單但你在實(shí)際工作中會(huì)發(fā)現(xiàn)能把技術(shù)問題講得讓外行聽懂是一項(xiàng)非常稀缺且受認(rèn)可的能力。5.2 代碼評(píng)審與文檔沉淀把隱性知識(shí)變成團(tuán)隊(duì)資產(chǎn)提到代碼評(píng)審很多初級(jí)工程師的第一反應(yīng)是抵觸覺得是在挑自己的毛病。但等你工作幾年后回過頭看會(huì)發(fā)現(xiàn)代碼評(píng)審其實(shí)是成長(zhǎng)速度最快的場(chǎng)域之一。每次評(píng)審別人代碼的時(shí)候你都能看到不同的實(shí)現(xiàn)思路和編碼習(xí)慣每次別人評(píng)審你的代碼時(shí)對(duì)方指出來的每一個(gè)問題都是你認(rèn)知盲區(qū)的直接暴露。我建議你主動(dòng)爭(zhēng)取參與團(tuán)隊(duì)里的代碼評(píng)審不要只做“已閱”的那種參與者而是認(rèn)真看改動(dòng)邏輯、提出具體問題。哪怕你的問題最后被證明是誤解也是一次深入的交流學(xué)習(xí)。時(shí)間久了你在團(tuán)隊(duì)里的技術(shù)影響力和話語權(quán)會(huì)自然而然地提升。文檔這件事也是同樣的道理。很多工程師不愛寫文檔覺得寫代碼就夠了。但實(shí)際上一份好的技術(shù)文檔能幫團(tuán)隊(duì)剩下大量溝通成本。一個(gè)簡(jiǎn)單的經(jīng)驗(yàn)是你花一小時(shí)寫一份排障文檔可能會(huì)為未來某個(gè)深夜排查問題的同事省下一整夜。而且文檔沉淀的過程也是你梳理自己思路、檢驗(yàn)理解深度的過程。我現(xiàn)在帶團(tuán)隊(duì)時(shí)會(huì)把文檔產(chǎn)出量作為考核工程師的重要指標(biāo)之一因?yàn)橐粋€(gè)能寫出清晰文檔的人大概率也是一個(gè)思路清晰的人。5.3 技術(shù)債務(wù)與質(zhì)量意識(shí)慢就是快快就是慢剛工作的時(shí)候我為了趕進(jìn)度經(jīng)常寫出“先能跑以后再優(yōu)化”的代碼。這些代碼當(dāng)時(shí)確實(shí)幫我快速交付了功能但幾個(gè)月后往往變成了一碰就炸的雷區(qū)每次改動(dòng)都要小心翼翼效率反而更低。這就是典型的技術(shù)債務(wù)借的時(shí)候輕松還的時(shí)候連本帶利。我給新人的建議是在寫每一行代碼之前都問自己三個(gè)問題這段代碼三個(gè)月后我還能看懂嗎如果有人接手他能快速理解嗎有沒有更簡(jiǎn)單但類似效果的做法這三個(gè)問題聽起來很基礎(chǔ)但如果你真的每次都認(rèn)真想一遍代碼質(zhì)量會(huì)明顯高于同齡人。當(dāng)然技術(shù)債務(wù)也不是完全不能有。有些業(yè)務(wù)場(chǎng)景要求快速上線驗(yàn)證這時(shí)候可以接受適當(dāng)?shù)暮?jiǎn)化實(shí)現(xiàn)但必須在代碼里寫清楚TODO和原因并且記在你的待辦清單里。關(guān)鍵區(qū)別在于有意識(shí)地欠債并計(jì)劃歸還和無意識(shí)地堆垃圾代碼是完全不同的兩回事。前者是技術(shù)決策后者是職業(yè)素養(yǎng)問題。6. 常見問題與避坑指南我踩過的一些坑6.1 新手入職后最容易踩的5個(gè)坑我把這些年見過新人踩得最多的問題整理成了一份避坑清單不分崗位通用分享給各位第一不問清楚需求就動(dòng)手寫代碼。很多新人接到任務(wù)后怕顯得自己笨不敢多問按自己的理解悶頭就寫結(jié)果做出來的東西和需求方想的完全是兩回事。我的建議是接到任何任務(wù)先用自己的話復(fù)述一遍需求找對(duì)方確認(rèn)再開始動(dòng)手。這個(gè)確認(rèn)過程最多花五分鐘卻能省下后面幾天改返工的代價(jià)。第二代碼只保證能跑不考慮異常和邊界。一些新人寫完代碼測(cè)了正常流程就提交了但一到線上就崩。真實(shí)世界的數(shù)據(jù)永遠(yuǎn)是臟的、亂的、不可預(yù)測(cè)的。寫代碼時(shí)多想想如果這個(gè)參數(shù)傳空怎么辦如果這個(gè)接口超時(shí)怎么辦如果用戶惡意輸入怎么辦這些邊界情況的處理才是區(qū)分初級(jí)和資深工程師的重要標(biāo)志。第三遇到問題不搜索就到處問人。問人本身沒錯(cuò)但如果每個(gè)問題都不經(jīng)過自己的思考和嘗試就去問同事很快就會(huì)不耐煩。我建議一個(gè)原則遇到問題先自己搜索嘗試30分鐘然后把嘗試過的方案記錄下來再帶著這些記錄去問人。這樣做的好處是即使你最終沒解決你也能把問題描述清楚對(duì)方幫你時(shí)效率也高。第四忽視測(cè)試的價(jià)值。在很多公司初級(jí)工程師往往是寫業(yè)務(wù)代碼的主力測(cè)試容易被當(dāng)成“額外負(fù)擔(dān)”跳過去。但如果你能養(yǎng)成寫完代碼順手補(bǔ)上核心用例的習(xí)慣你的代碼質(zhì)量會(huì)顯著提升而且這個(gè)習(xí)慣在面試和晉升中都會(huì)成為你的加分項(xiàng)。第五頻繁切換技術(shù)方向什么都學(xué)什么都沒學(xué)精。每半年換個(gè)熱門方向最后簡(jiǎn)歷上寫了一大堆技術(shù)但沒有一個(gè)能經(jīng)得起深挖。選擇方向后至少要在一到兩年內(nèi)持續(xù)深耕建立自己的護(hù)城河。6.2 領(lǐng)導(dǎo)把需求說得不清不楚怎么辦這其實(shí)是職場(chǎng)里一個(gè)非常高頻的問題值得單獨(dú)拿出來聊。很多時(shí)候不是領(lǐng)導(dǎo)故意不清不楚而是他自己也還在探索中或者他默認(rèn)你已經(jīng)掌握了背景信息。這時(shí)候你要做的不是抱怨而是把模糊變成清晰把被動(dòng)變成主動(dòng)。你可以把不清晰的需求拆成幾個(gè)具體的子問題逐一找相關(guān)人員確認(rèn)。比如“這個(gè)功能的核心用戶是誰”“優(yōu)先做哪些場(chǎng)景”“當(dāng)前最關(guān)鍵的指標(biāo)是什么”這些問題看起來簡(jiǎn)單卻能幫你快速鎖定工作的重點(diǎn)。如果你問了之后還是覺得不清不楚那你可以做一個(gè)最小方案給領(lǐng)導(dǎo)看用可視化的原型或者簡(jiǎn)單的demo來對(duì)齊認(rèn)知比用文字來回溝通效率高得多。記住一個(gè)核心心態(tài)把需求變清晰是你的職責(zé)之一不是額外負(fù)擔(dān)。那些能把模糊需求梳理清楚的工程師往往在團(tuán)隊(duì)里會(huì)逐步承擔(dān)更重要的工作。因?yàn)槟悴粌H能執(zhí)行還能定義問題這種能力非常稀缺。6.3 技術(shù)選型糾結(jié)癥怎么擺脫“學(xué)哪個(gè)好”的焦慮后臺(tái)經(jīng)常有同學(xué)問我我現(xiàn)在糾結(jié)學(xué)A還是B怎么辦這類問題背后往往不是技術(shù)問題而是選擇焦慮。我的建議是把“學(xué)哪個(gè)”這種問題轉(zhuǎn)化為“我現(xiàn)在最需要解決什么問題”然后選擇能最快幫你解決問題的那個(gè)技術(shù)。我舉一個(gè)自己的例子曾經(jīng)有段時(shí)間我需要給團(tuán)隊(duì)搭建一個(gè)內(nèi)部工具平臺(tái)在考慮用Python還是Node.js。我當(dāng)時(shí)并沒有糾結(jié)太久因?yàn)閳F(tuán)隊(duì)里后端是Java前端是Vue我選Node.js可以和前端共享語言生態(tài)減少團(tuán)隊(duì)協(xié)作成本。這個(gè)理由跟Python好壞完全沒關(guān)系純粹是“解決當(dāng)前問題的最佳選擇”。技術(shù)選型是有場(chǎng)景的脫離了具體場(chǎng)景談好壞基本都是耍流氓。如果你真的在兩個(gè)方向之間搖擺不定還有一個(gè)很實(shí)操的方法各花一周時(shí)間做一個(gè)同樣的小項(xiàng)目看看哪個(gè)方向你做得更順、更愿意繼續(xù)深入。真實(shí)體驗(yàn)帶來的判斷遠(yuǎn)勝于看網(wǎng)上各種對(duì)比文章帶來的紙上談兵。7. 長(zhǎng)期主義與持續(xù)學(xué)習(xí)的幾個(gè)習(xí)慣7.1 每天留出45分鐘的“學(xué)習(xí)留白時(shí)間”很多工作多年的工程師都會(huì)發(fā)現(xiàn)一個(gè)扎心的事實(shí)工作之后的學(xué)習(xí)時(shí)間遠(yuǎn)少于學(xué)生時(shí)代。白天被會(huì)議、需求、聯(lián)調(diào)占滿晚上回家只想躺著刷手機(jī)。但那些成長(zhǎng)快的人往往都有一個(gè)共同的習(xí)慣——每天留出一段固定的、不受打擾的學(xué)習(xí)時(shí)間。我自己的經(jīng)驗(yàn)是每天下班后留出45分鐘不做與工作直接相關(guān)的事情而是拿來擴(kuò)充自己的知識(shí)邊界?？梢允亲x一篇技術(shù)博客可以看一個(gè)開源項(xiàng)目的最新進(jìn)展也可以學(xué)一點(diǎn)軟技能相關(guān)的知識(shí)。關(guān)鍵是每天都要有形成習(xí)慣。別看每次只有45分鐘一年積累下來就是270多個(gè)小時(shí)足夠系統(tǒng)學(xué)習(xí)一個(gè)全新的方向。這個(gè)習(xí)慣還有一個(gè)意外的好處它能把你的注意力從“我今天又寫了多少行代碼”轉(zhuǎn)移到“我今天又學(xué)到了什么新東西”。長(zhǎng)期來看后者才是工程師職業(yè)發(fā)展真正的復(fù)利。7.2 寫作與分享最被低估的成長(zhǎng)杠桿如果你問我過去十年做過的最值得的投入是什么我的答案不是學(xué)了某個(gè)框架而是開始寫作和分享。一開始我只是在團(tuán)隊(duì)內(nèi)部分享技術(shù)筆記后來開始在一些技術(shù)社區(qū)寫博客再到后來出去做技術(shù)分享這一路收獲遠(yuǎn)超我的預(yù)期。寫作對(duì)工程師的價(jià)值至少有三個(gè)維度第一寫作會(huì)倒逼你把模糊的概念想清楚因?yàn)槟阆氩磺宄蛯懖幻靼椎诙懽鲿?huì)幫你建立個(gè)人品牌當(dāng)你的文章被別人看到并認(rèn)可時(shí)職業(yè)機(jī)會(huì)也會(huì)主動(dòng)找上門來第三寫作是很好的知識(shí)復(fù)利手段你五年前寫的技術(shù)文章到現(xiàn)在可能還在被搜索、被收藏、被轉(zhuǎn)發(fā)這是任何短期投入都難比擬的。如果你不知道怎么開始我的建議是降低門檻先從“給自己寫筆記”開始再逐漸把自己的踩坑記錄、學(xué)習(xí)心得發(fā)布出來。不用追求文筆多么優(yōu)美工程師寫東西核心是把事說清楚。哪怕一篇文章只解決了一個(gè)具體問題也會(huì)有人因此受益。7.3 職業(yè)倦怠期怎么和自己和解再出發(fā)雖然這篇文章大部分篇幅在講“如何變得更強(qiáng)”但我也想聊一個(gè)相對(duì)沉重的話題——職業(yè)倦怠。做了多年工程師幾乎每個(gè)人都會(huì)遇到那么幾個(gè)時(shí)刻代碼寫煩了、業(yè)務(wù)沒有挑戰(zhàn)、感覺自己在重復(fù)勞動(dòng)、升職遙遙無期。我第一次出現(xiàn)明顯倦怠感是在工作第四年那段時(shí)間每天上班做需求下班刷劇覺得日子過得像復(fù)制粘貼。后來我認(rèn)真復(fù)盤了一下發(fā)現(xiàn)自己倦怠的核心原因是“沒有長(zhǎng)進(jìn)”。當(dāng)一個(gè)人長(zhǎng)期處在舒適區(qū)每天做同樣的事情大腦就會(huì)分泌出無聊和疲憊的信號(hào)。走出倦怠期我的經(jīng)驗(yàn)是給自己找一個(gè)“新挑戰(zhàn)支點(diǎn)”?？梢允侵鲃?dòng)接手一個(gè)你從沒做過的任務(wù)類型可以是學(xué)一門與當(dāng)前工作方向不同的技術(shù)也可以是嘗試帶一個(gè)新人。關(guān)鍵是打破原有的節(jié)奏讓自己重新感受到成長(zhǎng)帶來的正反饋。如果嘗試了這些之后還是覺得不喜歡那也可以認(rèn)真考慮換一個(gè)環(huán)境。工作換不換其實(shí)是次要的真正重要的是你要保持對(duì)世界的好奇和對(duì)自己成長(zhǎng)的主導(dǎo)權(quán)。這條路沒有什么最終終點(diǎn)走好每一步時(shí)間自然會(huì)給你答案。根據(jù)我個(gè)人的觀察那些走得遠(yuǎn)的工程師往往不是最聰明的那批而是最能堅(jiān)持、最會(huì)總結(jié)、最愿意分享的那批。希望這篇分享能給你一點(diǎn)參考和力量在屬于你自己的工程師之路上走得更穩(wěn)、更遠(yuǎn)。