技術路線：前端開發已進入深水區

著做權歸做者全部。商業轉載請聯繫 Scott 得到受權，非商業轉載請註明出處[務必保留全文，勿作刪減]。

Scott 近兩年不管是面試仍是線下線上的技術分享，遇到許許多多前端同窗，因爲團隊緣由，我的緣由，職業成長，技術方向，甚至家庭等等緣由，在理想國與現實之間，在放棄與堅守之間，搖擺不停，心酸硬扛，你們能夠找我聊聊南聊聊北，對工程師的宿命有更多的瞭解，有更多的看見與聽見，Scott 微信： codingdream

正文開始

對於普通人，最大潛水深度通常不超過水下 30 米，極限爲水下 40 米，超過 40 米就進入到技術潛水的範疇，就會面臨各類複雜的危險情況，須要各類裝備的集成和系統化的訓練才能保證必定的安全性。

• 爲何技術晉升愈來愈難了
• 爲何高薪資的崗位 Offer 愈來愈難拿了
• 爲何公司老是說作技術也要懂業務
• 爲何不少團隊主管總把價值掛在嘴邊
• 爲何 What/How/Why 必需要搞清楚
• 爲何單純技術硬很難向前突破了
• 爲何前端開發往上走比以前更難了
• 爲何我想發力卻老是懶於動手
• 爲何我趴鍵盤上看不到明天看不到但願
• ...

紅利已逝，今非昔比。對比 2010 年，整個前端生態已經翻新了好幾遍，直到近幾年的 Node BFF、IDE Cloud，抑或是客戶端 AI，仍是 Serverless 的建設，前端想要深度參與的話，單純依靠原來的 HTML/CSS/JS 三件套技能也遠遠不夠了，再拋開技術，整個互聯網創業生態也重構了好幾遍，生意的本質沒變，但作生意的理念和方法論以及輔助的工具都發生了巨大的變化。

新的商業環境下就有新的公司組織架構形態，以及新的產品研發流程和合做模式，這些也對今日的前端開發工程師提出更新更高的要求，不管是技術層面仍是意識層面，現在的前端開發已經進入深水區，要在深水區中生存以及捕撈獵物，就須要有深水區所須要的系統化的技能體系以及配套的軟硬件能力，以及從淺水區進往深水區所須要的進階方法論，本文試圖向你們傳達這樣一種觀點，但願帶給你們一些啓示，不管是新人老人都要居安思危，提早作出儲備，以應對新的職場挑戰，更靈活的延展本身的職業路線。

本文是小菜前端 TL 內訓課程中， 《上手技術管理的初級套路》 這一節裏面，關於前端已迎來深水區這個觀點的展開陳述，文中會截取幾頁 PPT 來輔助敘述幫你們理解:

淺水區須要哪些技能

站在 2019 年，一般一個工程師履歷中體現的是跳槽歷史、參與項目的難度、React/Vue/Angular 等框架底層熟悉度、編程方法論的掌握程度以及職位的變遷等，而在工做中的確與編程強相關的技能有不少（該圖是我多年前整理修改而來，有同窗知道出處能夠告知我）：

拋開 BATMD 這種大致量的公司，放在市面上任意一個 50 人規模如下技術團隊的公司裏面，大機率掌握最好的是 IDE/框架/API 這一層，至於代碼實現的足夠優雅很難保障，更不要提程序設計的嫺熟套路、項目背後沉澱的方法論等等，單純在這張圖上打怪升級花個 5 年 10 年絲絕不爲怪，而對於前端工程師，這張圖的技能點花個 7 年 10 年所有打滿打透，此時也差很少三十而立了，而立之年也就是摸到了技術路線的第一個天花板，這個天花板就是技術專家，即使如此，用 10 年時間碰到這個天花板的人依然是極少數，大部分人須要花費更久甚至一直到不了這個高度，這張圖上我把它定義成淺水區技能，是肉眼可見的，是能夠量化的，是最容易產生共鳴而造成學習動力的，可是放在現在的新商業環境中就顯得很單薄了。

爲何單薄呢？咱們把圖上的能力和知識體系打碎重組，提煉後就是三個關鍵字：架構、編程、運維，一個是意識和邏輯層面，一個是過程實現層面，一個是環境保障層面，這些能力依然是落純技術體系內，並無跟外部的商業和職場環境發生多少交集。

深水區須要哪些技能

在深水區，腦海中若是隻有編程二字是不夠的，就算帶一些溝通合做也仍是遠遠不夠，可是不是必定須要深水區技能才能把工做作好，答案也並非，深水區技能是更長期性更深入的，從長期看具有這些特質能夠更快更好的跨過技術專家的這個天花板，走到更高的一個 Level，但不具有這些特質也未必會嚴重影響淺水區的表現。不過當更多同齡人具有深水區能力的時候，只具有淺水區能力的你慢慢就變成了裸泳，而更多更多的新人跳入到淺水區和你一塊兒競爭，此時你跟深水區已是隔絕的兩個世界，看到的和收穫也大相徑庭了。

我把深水區的技能，更口語化的總結爲： 技術創新、流程優化、團隊合做、影響大盤、驅動業務、商業決策和團隊管理，以下圖：

每個能力的解釋我也標註在了圖上，再通俗的解釋一下：

• 技術創新，從技術面、業務和產品面出發，以技術做爲突破點，取得技術上的突破，好比兼容多端的框架研發、客戶端淺層次 AI 的實現
• 流程優化，更可能是從產品研發流程上發力，藉助向上向下的管理，推進流程變得更高效，好比先後端的接口聯調方式、好比產品 PRD 到測試流程的介入更敏捷的迭代方式，多是規範多是工具層面
• 團隊合做，這個最好理解也最難作好，一樣是從管理和業務的視角切過去，促成團隊成員之間有更高層面的共識達成，有更信任的紐帶關係，以及有更匹配的使命目標驅動，好比與業務同窗一塊兒出差拜訪客戶，並在過程當中發現更多共鳴點，從而驅動彼此更快調整協做方式，最終爲客戶解決問題
• 影響大盤，所謂大盤就是公司或者部門的業務大盤，這個必定須要對業務的前景有較爲客觀深入的認識，而且造成本身的獨立判斷和決策，去發現業務缺失哪些核心的因素點，並去補全這個遺漏甚至是發現一個機會點，去發掘實現一個新的業務可能性，好比公司的內容生產是一個核心業務，去發現它將來規模化生產會遇到人力瓶頸，有沒有可能經過產品化背後的技術能力提供生產力，讓業務看到一個新的可能性從而修正整個內容的規劃方向
• 驅動業務，與影響大盤不一樣，驅動業務更可能是有實質性的推動而不只僅是想法，好比經過配套的埋點監控工具，來捕捉用戶一些有意義的行爲，從而不斷從中發現問題並推進業務去優化解決，或者發現有價值的方向，從而開放這些價值點背後的技術能力給到業務和產品，賦能他們更好的迭代業務流程
• 商業決策，這一點更可能是從數據價值層面，好比可視化不少時候是從前端來主導研發和推動，從各類展示模型中爲業務提供更好的決策視角，但在它以前必定是對業務和產品有足夠深的理解纔會造成有效的決策路徑和模型
• 團隊管理，這個則是一個很大的話題了，站在組織的視角把團隊從弱帶到強，從小帶到大，從層次不齊帶到規矩有章法能衝能創，成爲公司具有核心影響力的團隊

通過咱們再次簡單分析後，能夠發現這些技能背後，是四個核心能力，分別是：技術、產品、業務和管理能力，把它們再拆到每一個能力上，按照影響的權重，是這樣的對應關係：

大部分僅僅是靠技術都不可能去推動了，甚至技術都未必是它的重要影響權重，好比團隊合做、影響大盤、商業決策等，通通這些能力的集合就是一個足夠資深的工程師，他能在深水區存活，而且靠此打出一片天所須要的軟實力了。

怎麼修煉深水區能力

聊清楚深水區對於工程師的 What 和 Why 之後，咱們來聊一聊 How。開始以前咱們必須認識到這些能力不是一蹴而就的，不管是你已經具有了部分能力，仍是絲絕不具有，咱們都要認識到它的習得須要一個過程，這個過程一般就分爲這三個階段：初級練習階段、漸變嫺熟的階段、質變內化爲能力的階段，在初級練習階段沒有足夠的沉澱前，直接跳日後兩個階段都是不切實際的。

首先是初級階段怎麼練習，我把 PDCA 修改後造成這一個作事套路，你們能夠參考：

工做中的每一項具體的任務，均可以按照這個路子走一遍，一開始的時候會不適應，甚至有點僵硬的硬套模仿，多來幾回慢慢就會成爲一種習慣，舉個例子：

團隊裏有不少表單開發的場景，你們的效率都很低，開發很痛苦，我看到這個問題後，就想要作一個複雜表單組件，我首先就是研究各類市面方案，研究公司的業務場景，研究已有的端產品上業務表達的交互表達方式，團隊有沒有人研究過表單的方案，我去收集相關的信息，而且我也弄明白爲何要開發這個表單組件，它能爲業務帶來實際的價值麼，這個表單應該承載什麼核心功能呢，作完能推進落地麼，我本人能推得動麼.... 這個環節就是造成判斷決策的時候，也就是捉摸。

捉摸明白後，我開始制定目標，這個要符合 SMART 法則，儘可能的可量化，好比：我要用 2 周時間開發一個表單組件，這個組件要能夠被兼容替換到 AB 兩個業務的 DEF 三個產品的 10 個頁面的交互中，而後開始制定具體的開發計劃，哪一個時間點找老闆徵得贊成，開始定出分幾個版原本迭代，每一個版本的週期是幾天，每一個版本完成的具體功能是什麼，在這個過程當中須要哪些資源，好比架構組同窗的支持，業務組同窗的反饋，交互組同窗的設計配合，產品經理同窗的理解和認同，而後把整個開發過程以可被感知的方式量化出來，透明化出來，這就是規劃的階段。

規劃後開始進行技術方案的設計，模塊的設計，三方庫等等直到編碼完成，開始推進組件在匹配的業務線和產品中使用，推進並幫助其餘同窗使用該組件，跟蹤組件使用的效果並及時的修理 Bug 優化交互等，這個就是執行階段。

在業務線用了一段時間後，組織一個小小覆盤，針對實際應用中的問題作個收集整理，而且把過程當中本身的不足也作一個檢視，好比常常忘記跟老闆同步進度，常常疏忽其餘同窗的吐槽建議等等，另外根據覆盤和反饋來確保這個組件的確有提效的價值。

最後是沉澱開發組件的方法論，相應的技術文檔（這個每每在開發過程當中就沉澱下來了），以及組件化立項開發的套路，本身我的能力有什麼成長，這種能力如何快速複製給其餘新手同窗...也就是沉澱 Share 的階段。

實際工做中的問題，每每比一個組件要複雜的多的多，這就須要咱們更加謹慎的對待每一個階段，把它們靈活應用並保障每次都比上一次拿到更好的結果，我的每次都比上一次方法論用的更純熟。

上面拋磚引玉介紹了單純實現層面能夠訓練的方法論，這種方法論一樣適用了任何能力的練習，但方法論畢竟是方法論，真正決定它們訓練結果其實還有一個前置條件，就是你的作事驅動力，也就是能力和意願的狀況。

能力意願是前置條件

咱們先講了方法論，讓你們更明確的感覺到一些可執行的套路，而後再來看能力和意願的重要性，所謂能力就是你斷定問題和分析解決問題的能力，所謂意願就是你面對任何一個突入飛來的難題或者任務，心裏是抵觸、認同仍是興奮這樣的一種情緒。

首先，咱們分析下一個員工的作事動機，一般有這幾類：

• 不知道不關心，對這個任務不清楚 what/how/why，也不關心它作不作的價值有多大
• 這麼作是由於必須這麼作，依然不理解它的價值，但知道這樣作是由於我是前端工程師，這是我份內事
• 不這麼作會有罪疚感，老闆對我有信任，我若是不作好會以爲很差意思，心理過不去
• 這麼作對我很重要，我認同這件事交給我作的緣由和意義，這件事對個人成長及將來晉升都有意義，我很重視
• 喜歡並專一去作，這件事是我一直以來期待的機會，我很喜歡很想去實現它，我很理解它作好的意義

因此一個同窗有可能作不一樣的項目會有不一樣的動機，即使作同一個項目的不一樣階段也會有不一樣的動機，這是一個徹底主觀的事情，可是它很重要，由於不一樣的動機會帶來三個結果：老闆及周圍同事經過你作這件事所看出的你的作事態度，這件事你作完達成的結果，以及你由此而得到的成就感或者成長，固然全部的團隊都但願你不管喜歡與否，都至少是理解並執行這個任務：

最怕的是理解不執行和不理解和不執行，最終反映在能力和意願上，在一個團隊的分佈中，你就有了不一樣的象限，是能力好意願度高的，仍是能力高意願度低的，只有意願高能力高的人才能得到最大程度的受權和自由空間，反之不只得到受權會縮水，甚至必須遵從具體的拆解後的任務去作執行的角色，因此如何讓本身不管能力高低，先讓本身具有一個高意願度都是一個明智的選項。

那麼存不存在一些事情是無心義的，作了也是白作呢，必定存在，如今這樣高節奏的創業環境中，試錯始終是一種常態，作一件事而拿不到結果也是常有的事，可是不是所以就否認了組織的動機，從而把本身束縛的愈來愈緊，正面看過去好像本身再也不虧什麼了，反過來看本身卻失去了進入深水區而該有的歷練，這個歷練中必定有汗水也有委屈。

面對深水壓力不需緊張

其實何止前端開發，整個技術行業都已步入深水區，只是前端工程師的感知來的晚一些而已。只要把眼光投向深水區，問題就會一個接一個的浮上來，當愈來愈多問題浮起來的時候，就是你慢慢沉向深水區的時候，這時候不須要太過緊張，此時的發生正在見證者你的成長，歡迎你們文後提問更多問題，咱們能夠再換一期來針對性討論，本文主要幫你們引導到深水區已然到來，在它之上須要儲備技能的必要性和重要性，目的就達到了。