前端工程師做事的三重境界：我的進階之路

共 2835 字，讀完需 5 分鐘。寫作本文的目的：構建自己關於前端工程師成長過程的認知模型，從自己的視角來分析 Programmer、Developer、Enginner 的能力結構與工程師成長過程的關聯，並分享出來給大家，期望能對入門的前端同學有所借鑒和啟發。需要提前說明的是，文中用到的工程師的不同叫法並不是要給工程師分類或者貼標籤，因為工程師的成長過程是連續的，喜歡鑽牛角尖的同學請自行繞路。

程序員 or 工程師

圈內對從事軟體開發的同學有很多叫法，如程序員（Programmer）、開發者（Developer）、工程師（Engineer），甚至是碼農，「碼農」是圈內人用來自嘲的，那其他幾個名詞呢？表面上看起來都是做軟體開發，叫什麼真的重要麼？

不得不說，叫什麼並不重要，不論是自稱還是他稱，什麼學歷、幾年工作經驗也不重要，真正重要的是人所具備的能力。那麼既然名稱不重要？為什麼還要談論它？名稱的真正意義在於能讓我積極拓寬自己的視野，不斷點亮自己的技能樹，在職業發展的道路上不斷積累、不斷提升。

工程師做事的三重境界是什麼？程序員、開發者、工程師這些叫法跟這三重境界又有啥關係？

第 1 重境界：把事情做成

把事情做成是公司對員工的基本要求，絕大多數入門同學就處在這個境界，這個境界的人可稱為程序員（Programmer），對於 Programmer 通常需要告訴他做什麼、怎麼做，他所需要的是執行力和基礎技能，這裡的技能包括：基本的編程技能，至少會一門編程語言，對這門語言的熟悉程度至少能夠讓他把基本需求解決。具體到前端領域，對 Programmer 的要求就是需要能夠使用 JS、CSS、HTML，並且熟悉編輯器、瀏覽器來完成基本需求。

以常見的 WEB 端統計為例，為了研究頁面關鍵元素的用戶行為，需要對用戶的部分交互添加事件統計（更常見的叫法是「埋點」），比如單擊事件，表單提交事件，如果使用百度統計，在頁面中埋點的方法大概如下：

<a onclick="_hmt.push([_trackEvent, checkout, click]);">購買</a>n

或者在 JS 中埋點：

// 需要發送統計的時候n_hmt.push([_trackEvent, checkout, click]);n

接下來由於業務需要，相同的統計，需要往 Google Analytics 發一份，最簡單粗暴的解決方案如下：

<a onclick="_hmt.push([_trackEvent, checkout, click]);n _gaq.push([_trackEvent, checkout, click]);">購買</a>n

JS 中也需要做同樣的修改：

// 需要發送統計的時候n_hmt.push([_trackEvent, checkout, click]);n_gaq.push([_trackEvent, checkout, click]);n

如果網站的頁面規模、統計事件量小，變更埋點可能會比較輕鬆，但當頁面和事件數量隨著業務發展激增，估計程序員會埋點埋到手抽筋了。這個時候 Programmer 會不高興，很可能 Boss 也會不高興，因為埋點效率提不上來，並且容易出錯。聰明的 Programmer 會發現，僅僅從表面上把問題解決貌似還不夠。該如何破局？

第 2 重境界：把事情做好

具備什麼樣的能力才能把事情做好？對基本技術的熟悉程度超過（需要超過一大截）把事情做成的需要；對於業務需求有一定的前瞻性；能給出比較健壯的技術方案，能一次解決一類問題而不是一個問題，知道什麼樣的方案是不靠譜的，具備這些能力的人可稱為開發者（Developer）。

不可否認，Developer 是升級版的 Programmer，相比而言，Developer 大多數時候需要自行找到問題的解決方案並落地實施。通俗的說，面對具體的技術、業務問題，Developer 能比 Programmer 顧及到更多的點，想到更多的方案。但是要實現這兩個「更多」，需要的是努力、時間和經驗的積累。

當然，從 Programmer 到 Developer 的進階是可以加速的，需要壓縮自己的時間在更短的時間內做更多的事情，注意這裡不是把相同的事情重複 N 遍，如果是那樣就很容易出現 3 年工作時間半年工作經驗的尷尬。

回到上面提到的埋點方案，簡單粗暴的解決方式存在什麼問題？

• 首先，代碼擴展性太差，後續如果需求方需要接入自建的統計，前端的工作量並沒有減少，反而改起來會需要更加的小心翼翼；
• 其次，直接發送統計是否能保障精確送達，有沒有可能存在漏報的情況，細心的同學肯定能想到這種風險；
• 最後，前端代碼風格，其實不太推薦在 HTML 中內聯書寫 JS 事件，這就是臟代碼的典型例子；

Developer 會如何解決這個問題呢？先理清楚埋點代碼的本質：發送統計的動作、指定統計參數，其中發送統計的動作跟需要接入的統計平台有關，確保統計到達也跟這個動作有關，這個動作跟統計參數無關，而統計參數本身跟節點的關係比較緊密，動作和參數可以解耦開。

基於這樣的認知，不難設計出下面的方案，在所有需要埋點的地方約定參數的標記方式，使用 data-event-* 參數標記事件名稱、事件類型以及額外的參數：

<a data-event-name=checkout data-event-type=click>購買</a>n

然後，在頁面級別監聽那些埋點的節點，並且恰當的時機發送統計代碼，簡化版如下：

// 相同的參數發送給所有已接入的統計平台，如果平台不同，適配工作也在這裡做nconst sendEventLog = (name, type, param) => {n _hmt.push([_trackEvent, name, click, param]);n _gaq.push([_trackEvent, name, click, param]);n};nn// 針對單擊事件的處理，其他事件可以類似處理n$(body).on(click, [data-event-name][data-event-type="click"], function (e) {n // 拿到事件發生的節點n const target = $(e.target);nn // 獲取事件屬性n const name = target.attr(data-event-name);n const param = target.attr(data-event-param) || ;nn if (!name) {n return;n }nn // 這裡如果是鏈接跳轉，需要走單獨的邏輯n sendEventLog(name, click, param);n});n

上面探討了從 Programmer 進階到 Developer 的方法就是積累，那麼怎麼積累？我行動的基本法則是：做出好的東西先要知道好的東西長啥樣。一方面，多讀經典的書，仔細讀高質量的文章，注意這裡面讀遠比收藏重要，上哪裡去找經典的書和高質量的文章？這需要建立自己的信息篩選機制；另外一方面，遇到問題要學會去搜索，找更多的解決方案，然後比較，融會貫通。

不得不承認，從 Programmer 進階到 Developer 需要非常多的努力和積累才行，但是精進之路永無止境，下面說說第三重境界。

第 3 重境界：把事情做絕

能夠把事情做絕的人，可以稱得上是工程師（Engineer），那麼到底怎麼才算是把事情做絕？以統計埋點為例，能夠洞悉埋點需求的本質，把日誌發送和埋點標記解耦之後，將兩者都做到極致。現實中埋點需求的來源通常是運營和產品經理，所有的變更基本都是由他們驅動，如果能夠給他們提供工具管理頁面中的埋點標記（思路關鍵詞：XPath、微服務、瀏覽器插件，細節不在本文描述），就能把工程師從這種瑣碎需求中解放出來去做更有意義的事情，這樣也就改變了組織中不同員工間的協作方式，提高組織的效率。

想成為前端工程師，要先成為工程師。工程師應該具備怎樣的能力？要回答這個問題，我們不妨仔細思考下什麼是工程，WIKIPEDIA的原文如下：

Engineering is the application of mathematics and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes, solutions, and organizations.

簡單說，工程就是運用知識去設計、創建、維護、改進工具、系統、流程和組織的過程，而工程師是推動這個過程的最主要角色。

工程師，首先要具備很強的學習能力，能掌握完整的知識體系，知識的來源並不重要，可以來自於自學，也可以來自於學校，以及生產實踐的總結，只局限於一門編程語言或特定的幾個工具是遠遠不夠的，讓一個工程師切換到新語言不會有什麼障礙，紮實的計算機科學基礎是基石。具體到前端領域，基本的數據結構和演算法、設計模式和變成範式、網路、JS、CSS、瀏覽器、性能、設計，軟體質量、可維護性、可擴展性，軟體工程化（構建、部署、運維、監控）。

工程師，還要具備良好的抽象思維能力，有了抽象思維能力就能夠快速建立起系統運行機制的思維模型，也能把現實世界的業務問題轉化為了恰當的模型，然後用技術去解決。具體到前端領域，比如前端應用的典型信息架構，狀態機、棧、隊列這些數據結構在前端的應用。

工程師，還要具備良好的溝通能力，溝通能力的好壞決定了你是否能準確理解需求的本質，是否能把自己的的設計方案清晰的展示給同事，而溝通的形式就不那麼重要了，可以是書面文字，可以是白板、思維導圖，甚至是動畫演示。

工程師，還要具備平衡取捨能力，知道在哪些地方只需要做成，哪些地方需要做好，哪些地方要做絕，因為工程的要義就是取捨，在商業和技術之間尋求平衡點，這往往是很多人所忽視的能力。

冰凍三尺非一日之寒，成長為靠譜的前端工程師也不能一蹴而就，需要長時間的積累和沉澱，而到達這個境界之後就結束了么？絕對不是，阻礙人前進的最大障礙就是他的心智，還是那句話，精進永無止境。

One More Thing

本文作者王仕軍，商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。如果你覺得本文對你有幫助，請點贊！如果對文中的內容有任何疑問，歡迎留言討論。想知道我接下來會寫些什麼？歡迎訂閱我的知乎專欄：《前端周刊：讓你在前端領域跟上時代的腳步》。

Happy Hacking