在面試的時候, 我們經常會談論到面試需要考察一個人的技術深度和廣度, 但實際操作中, 經常會遇到情況是, 面試造火箭, 進來擰螺絲.
我曾看到知乎中一些做算法的同行曾經討論過, 關於算法和算法工程之前的區別, 對於算法研究並不是算法工程師的工作, 對於算法工程師而言, 更多的是參數調優, 當然能做這件事的前提是你得懂算法. 但幹我們這一行的都清楚, 雖然做工程做業務是就業路子最廣的, 但是時間長了在技術上的深度和廣度都會受到影響.
而對於軟體工程師, 或者前端工程師而言, 如果做工程, 做業務沒有出路, 業務經驗再豐富連基本的面試都通不過, 積累工作經驗的意義又何在?
如果你做過管理, 我相信你一定曾經有過這樣的心態, 招人用人喜歡年輕有想法有活力的, 但是在面對業務壓力的時候依然會選擇讓那些業務熟悉的老人來頂, 雖然內心覺得此類往往缺乏潛力, 但真正能扛得住事的卻恰恰又是他們.
業務經驗毫無價值, 在面試的時候往往一筆帶過, 但是實際工作中承擔業務團隊重心的卻恰恰又是業務經驗最豐富的的人. 為什麼會有這種矛盾? 這個問題一直困擾著我. 直到最近才有些心得, 決定拿出來跟大家分享.
正文什麼是前端技術?如果有前端開發技術, 前端研發技術與應用這樣的學科, 你覺得會包含哪些內容? 參考在大學中學過的計算機科學與技術, 我相信對於前端技術而言, 主要包含的應該是這些
所以從這個角度看, 你會發現你日常工作中 90% 以上的內容和前端技術毫不相關, 回想下自己今天的工作內容吧.
毫無意義?, 既然日常工作和前端技術毫無關係, 自然無法提升任何技術深度和廣度, 只能在面試的時候獲得一個 業務經驗豐富, 做業務沒問題的評價.
那究竟啥叫前端技術, 或者說什麼叫做搞前端技術的?
答案其實就在上面, 只要把 2 個大類拆解一下
JavaScript 語言的研究, 參與和貢獻新的語法提案這三塊和大部分人都沒啥關係, 這種基礎技術的研究工作通常都不會落在普通人身上.
特定技術棧下的代碼封裝技術的研究(webpack plugin, loder...)特定技術棧下的代碼封裝技術的研究(postcss-puglin...)特定技術棧下的代碼封裝技術的研究(babel-plugin ...)瀏覽器兼容性處理(borwserlist, autoPrefix...)特定技術棧下的代碼封裝技術的研究(redux, vuex...)瀏覽器 Api 操作代碼封裝技術的研究(從操作 dom 到操作各種 webapi 都屬於這一範疇)JavaScript 代碼封裝技術的研究(lodash 就屬於此類)JavaScript 編譯和執行技術的研究(TypeScript babel v8 等)css 編譯和執行的研究(scss, less, postcss...)各位可能會有點好奇, 似乎少了什麼, 比如 nodejs, rn flutter 等?如果看過我之前寫多文章, 應該了解我的觀點, 上述均不屬於嚴格意義上的前端技術範疇, 包括 nodejs
nodejs 作者開發 nodejs 的初衷也不是為了前端技術的發展, nodejs 在自動化技術上的應用, 對於前端代碼模塊化封裝技術的推動是一個副作用.
如果你不做任何和服務端相關的事情, nodejs 對你而言幾乎是透明的, 只是為了用來執行
npm i hello-world
來來讓我們對照下, 上述內容是否和你的日常工作有關係, 別沮喪, 雖然我知道 80% 的人會回答 No!
沒錯大部分前端的日常工作和前端技術毫不相關, 你唯一需要做的僅僅是用你所了解和掌握的前端技術去解決問題, 不是這些技術的問題, 而是業務需求.
當我們討論一個人的技術深度的時候, 我們其實就是在談論在上述技術領域的任一分支下, 你是否擁有足夠多的實踐, 足夠深入和透徹的了解.
如果深入和透徹了解還能面前靠閱讀源碼和文章, 通過思考和悟性解決.
但足夠多的實踐卻能卡掉大部分人提升技術能力的機會. 想想什麼樣的部門或者團隊有機會去實踐?
反正不是業務團隊就對了!!!
在業務團隊你最大的可能性大概就是研究下特定技術棧下的代碼封裝技術, 例如 webpack plugin, babel plugin 等, 但是大概率也是非常淺顯的
那麼搞業務, 寫業務代碼是不是就是沒有出路的工具人, 資源符號? 績效淘汰備選對象?
說句實話, 從我這麼多年的經驗和身邊的例子看, 90% 的前端寫業務, 90% 裡的 80% 都面臨被持續淘汰的風險, 一般都是過了工作 5 年這個節點, 開始不斷的被淘汰, 從大廠到中廠到小廠到外包, 無論你是做管理還是做技術, 隨著工作環境的惡化幾乎難逃越混越慘的命運.
但如果這是我思考的結果, 那我就不寫這篇文章了, 因為接下來我要談論不是廣泛所指的前端工程, 前端工程化等概念, 再我看來, 當下談論的前端工程化依然只是上述技術的一根分支, 屬於自動化技術的範疇, 說是搞工程其實就是搞技術, 我要講的工程是實實在在的工程, 緊貼業務的工程.
因為我也是常年業務團隊出身, 我一直在思索破局之法, 我相信佔據了 90% 前端工程師精力的事情不可能是這種毫無意義註定走下坡路的工作, 這裡一定有啥是不對的. 或者不科學的.
為此讓我們進入本文最重要的部分
什麼是前端工程
什麼是搞前端工程?在大學裡有一個專業叫軟體工程, 在研究生領域也有專門的軟體工程碩士, 當年我看過的軟考教材裡也有一個職稱叫軟體工程師, 從位階分類上, 軟體工程師在程式設計師之上. 在系統分析師之下.
回顧下軟體工程領域的經典之作吧
在上面章節中提到的所有技術分支中, 或者你回想下在你用過的 JavaScript 庫中是否有一個庫是給你快速應用設計模式的?
我想應該沒有, 因為設計模式最早是用 Java 寫的, 隨後的幾年有人用 JavaScript 翻譯了這些模式, 但代碼已經老舊了, 或者說部分設計模式已經被 JavaScript 語言的天然特性所解決了.
包括在 Java 內部也一直圍繞 設計模式 是否還持續可用持續著不斷的討論. 所以設計模式是一種技術麼? 或者說設計模式能變成一種直接可以使用的技術麼, 比如 React ? Vue ?
顯然不行, 因為設計模式只是一種抽象方法, 是使用面向對象語言在進行軟體研發, 組織軟體工程所使用的的快速思維模板.
這種模板可用於任何滿足模板使用條件的語言, 例如 OC Java JavaScript 等
因此對於前端領域的工程, 或者說有別於前端技術的前端工程這件事, 究竟是在搞啥. 我給的定義是
前端工程是指採用前端技術組織前端代碼開發和維護前端項目
所以搞前端工程,做業務的人的出路在哪? 或者說除了謀求一個管理崗位, 有什麼是廣義上的前端編程技術可以讓我們實踐和研究, 我們自稱為前端工程師, 但是幹了這麼多年真的有在前端工程上花費過多少心思呢?
廣義上的前端編程技術包含了前端技術和前端工程
我這麼說完, 估計會被人噴, 說的容易, 具體怎麼搞? 難不成大家都去當四人幫?
怎麼搞? 很難搞, 事實上前端工程的研究難度遠大於前端技術. 為什麼?
因為前端技術是標準的, 就拿難啃的 EcmaScrip 規範舉例, 在難啃, 只要你頭夠鐵, 也能啃下來.或者以 V8 引擎舉例, 不好啃, 怕啥 chrome 源碼都啃了還在乎加一個 V8 麼?
React Fiber 好啃麼, 也不好啃. 但是這些東西都是技術標準, 在一段時間內是確定性的, 你只要有足夠的時間, 你都能啃下來.
但是業務是高度不確定的, 圍繞業務建立起來的前端工程同樣是高度不穩定的, 所以如果要在業務端, 在前端工程裡要搞出高度來, 還真的很難.
如果說搞前端技術, 最終的路徑是往前端基礎架構方向深入, 那搞前端工程, 搞業務, 就應該同樣有一條路徑通往前端業務架構.
說到這裡又不得不提下前端編程技術架構的兩個分支了
嶄露頭角的前端基礎架構和完全摸不著頭腦的前端業務架構在一些大廠, 近幾年已經開始流行在前端團隊中搭建特殊的部門, 前端基礎架構. 其實這並不是新鮮事, 在我看來這是前端技術發展趨於成熟的一個標誌, 對既往的前端技術進行更有效的統一資源投入研究, 通過組織力量來匹配.
但另一個架構分支, 前端業務架構, 你可能聽過, 但目前在各個團隊的組織架構中基本不存在這樣的人或者這樣的崗位, 如果有的話歡迎交流, 因為我就是
前端業務架構師
目前我們團隊對前端業務架構師的定義是, 成為前端業務和前端基礎架構的紐帶, 同時致力於打造前端業務中臺, 有效避免業務組織架構的調整對前端工程的影響
怎麼理解? 如果你從事或者想從事這個工作歡迎和我交流, 本文暫不深入.
還是讓我們回到廣泛的前端業務工程上來吧.
組件提取和 CV 大法其實都是死路一條前端社區近 10 年的發展可以說是典型的殘疾模式, 一條腿特別粗 → 前端技術, 另一條腿高度營養不良 → 前端工程.
基本上所有業務上的問題我們都是用技術思維去解決的, 但技術畢竟有瓶頸不是萬能的, 技術解決不了怎麼辦? 兩個辦法
組件聽起來是一種抽象封裝技術, 但在前端領域其實嚴格來講應該叫標準件, 即忽視了產品和設計以及體驗上的訴求, 根據特定技術棧的要求對代碼進行封裝後的產物. 為了解決業務開發上復用代碼的需求.甚至有一段時間, 前端團隊為了讓標準件穩定, 把產品和設計一塊綁架了, 讓他們閉嘴.
我們解決不了產品和設計提出的差異性需求, 所以把提出問題的人給解決了
只要產品不改, 設計不想, 一切完美.
但理想很豐滿, 現實很骨感, 一堆公司花精力投資源搞了一堆的組件庫, 最後還不如直接用 antd, 那些被提取出來的組件最後都陷入一種怪圈
組件就這個標準, 你們有需求要麼你你們來改, 要不就用!!
參數已經不能再加了, 都 20 幾個參數了...
不行啊, 這個邏輯其他團隊再用, 給你們改了, 他們要回歸, 要不我發個特殊版本?
需求越多死得越快, 前端目前所謂的組件就是這麼個玩意.
你有這種經歷麼, 看到一個同事 CV 大法了一下然後義正言辭的跟他說, 你這麼搞不行, 要提取組件.
在我看來其實 CV 雖然也是一條死路, 死得還比組件快, 但是 CV 也有組件沒有的優點, 就是對代碼修改的隔離.
目前很多社區方案提到的區塊其實就是 CV 的一個改進, 不過雖然比 CV 好點, 能夠統一集中管理, 定期升級, 但是依然無法解決改動後的版本的同步問題. 只能說一定程度上延長了採用 CV 大法的壽命
所以前端工程有設計模式麼? 其實有的, 不過就 2 種
這兩種模式就是我們前端的基本編碼抽象思維的快速模板, 也就是前端的設計模式.
他們各自擁有對方沒有的優點, 但同時又有對方沒有的缺點, 就像個太極圖, 不過解決都一樣, 都是奔著重寫去的.
提取組件易於同步, 但是對差異化處理會帶來參數膨脹, api 濫用的問題, 最後也是個死CV 大法可以有效隔離差異, 但是隨著時間推移, 越來越多的版本同步問題也會摧毀你. 也是個死所以前端工程是不是比前端技術更難? 對於一個致力於研究前端工程技術的人而言, 應該思考新的設計模式, 新的抽象方法來解決上述問題, 這才是 90% 前端的出路.
雖然是一條比搞前端技術更難的路, 但是卻能給後來人踩出希望
關於這點, 我們團隊在這方面有了些成果, 在 CV 和組件提取之外找了一條新路, 至於通不通, 等我分享了你們再品一品吧. 在我前面的文章中有提到過
Membrane Mode
在我們開發的 React 狀態管理框架中也有部分展示, 可以移駕去看下, 如果你感興趣可以順手點個 star 😁
地址奉上:
https://github.com/kinop112365362/structured-react-hook/blob/main/README_ZN.md#membrane-%E6%A8%A1%E5%BC%8F
後話繼續招人, 招人一起搞事情, 搞大事情呀...如果你對前端基礎架構和前端業務架構感興趣, 請務必聯繫我, 我們需要你這樣的人才 😁