作為前端，多少還是要有一點 hard core 精神

本文是題目《前端工程師的深度或者核心競爭力體現在哪裡？》答案的優化版，去掉了技術無關的部分。

原答案鏈接：https://www.zhihu.com/question/263926959/answer/275947141

一個前端工程師，或者廣義地說一個客戶端工程師，一種非常重要的競爭力，是你編寫複雜代碼的能力。這裡說的競爭力，不是那種能讓你升職加薪飛黃騰達的競爭力（當然也可能有用），而是那種讓你面對需求不頭疼不發愁，敢拍胸脯說「我給你做」的競爭力。

換句話說，它決定了你在開發工作中享有多少「自由」。

前端開發跟後端開發有一個非常不同的點，就是前端開發應用層的代碼邏輯很容易就變得極其複雜，而後端的複雜邏輯主要集中在和業務正交的領域。

舉個和數學無關的例子（和數學無關意味著你作為應用開發會碰到），OA 系統里的工作流，大家都用過吧？那麼，下面這個界面，在前端怎麼做？

注意：

1，不是讓你畫框圖，開源 svg 或 canvas 框圖庫是現成的。

2，不是做純展示頁面，是做編輯器。

具體方案不談，我們就談談思路。或者說，我只想要達成一個共識：

你懂 react，懂 vue，懂 redux，或者你做過多少個幾百頁面的「大項目」，對你實現上面這個東西有多大幫助？

坦白講，沒有多大幫助。

想實現這麼個東西，應該怎麼做呢？正常的思路是這樣——首先按照業務邏輯，設計一個 model 描述整個圖，這個 model 一般是樹形結構，每一層包含若干節點，每個節點上包含若干連接點，另外還需要一個結構描述連線。

大致是：graph - node - pin - connection 這樣的層次關係。

另外還有很多細節，比如四個泳道如何描述，不同的節點類型如何抽象；不同顏色的連線表示不同關係；以及如何處理注釋框，如何處理聯動，如何序列化/反序列化……一時半會兒說不全。

如果加上界面邏輯，就更複雜了，位置，樣式，拖動，事件，刷新，局部刷新（也許需要），context menu，undo，redo，等等。

面對這樣的需求，談什麼「前端數據流」，好像沒多大意義。為什麼？因為前端數據流是開發範式，實際上並不會幫你建立業務模型，不管依賴什麼工具，模型總要你自己建立。

那麼如何建立模型，又如何使用代碼合理的實現模型？沒有什麼黑科技，就是一點一點的寫，抽絲剝繭，功力足夠，你就能寫出簡潔有序抽象可復用的實現，功力不夠，寫個一千行就亂套了。

類似的需求，我還能舉出更變態的。

比如這個，複雜框圖加實時數據展示加滑鼠操作，簡稱組態：

還有這個，CAD 搬到網頁里，這還不算複雜的，複雜的直接在網頁里渲染 BIM：

甚至這個，跨平台頁游：

我猜有讀者會說：

你舉得這些，根本不是前端典型應用。

沒錯，確實不是典型應用。但是——

那些你認為的「典型前端應用」，很可能包含了一些非常複雜的部分，只是沒分到你頭上而已。知乎算典型前端應用吧？知乎 pc 端富文本編輯器是知乎程序員自己寫的，絕對不比那個工作流編輯器簡單。

那我們想像一下，假設你是知乎的程序員，你同部門的同事，在開發一個你寫不出來的程序，你心裡會不會有點不舒服？你好意思張嘴說「我有核心競爭力」嘛？

其實我貼的圖，無非是舉幾個例子讓大家感受一下什麼是「複雜」，並不是就讓你去做這些應用。本質上，「複雜」就是程序裡面層次特別多，狀態特別多，關係特別多，特別考驗程序員一種和平台工具都無關的能力——就是你腦子裡得能裝得下這些東西。就是我所謂的「hard core能力」

而現實中，咱們大部分前端在這方面的能力又是怎樣的呢？

比較遺憾，大部分前端程序員常常忽視了這種能力。很多人各種技術架構說的頭頭是道，但是別說那些特殊應用，遇到一個複雜聯動表單，比如這樣的：

這就已經抓耳撓腮，bug 頻出了。

然後他們會在簡歷中寫，熟練掌握 react/angular/vue/webpack/……然後上網發帖子說前端過剩了，自己很恐慌，以後怎麼辦云云。

當然恐慌了，稍微 hard core 一點的程序你就投降，查個 bug 沒有 sourcemap 都不知道該咋辦，就靠著背得過幾個 api 過日子，任誰誰都恐慌。

那應該怎麼辦呢？很多人說要保持學習能力，隨時學習新東西，這不失為一個辦法，但我總覺得不是長計。別的不說，程序員加班那麼多，你能保證有時間整天學這學那嗎？

倒不如聽聽我的的建議——你在一個平台上能寫出那種打眼一看一時反應不過來該怎麼寫的程序，那你在任何平台上都有能力做到這一點，別讓自己做的項目只有填充簡歷的功能，還要讓它們給你背書。