共 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>複製程式碼或者在 JS 中埋點：
// 需要傳送統計的時候
_hmt.push([`_trackEvent`, `checkout`, `click`]);複製程式碼接下來由於業務需要，相同的統計，需要往 Google Analytics 發一份，最簡單粗暴的解決方案如下：
<a onclick="_hmt.push([`_trackEvent`, `checkout`, `click`]);
_gaq.push([`_trackEvent`, `checkout`, `click`]);">購買</a>複製程式碼JS 中也需要做同樣的修改：
// 需要傳送統計的時候
_hmt.push([`_trackEvent`, `checkout`, `click`]);
_gaq.push([`_trackEvent`, `checkout`, `click`]);複製程式碼如果網站的頁面規模、統計事件量小，變更埋點可能會比較輕鬆，但當頁面和事件數量隨著業務發展激增，估計程式設計師會埋點埋到手抽筋了。這個時候 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`>購買複製程式碼然後，在頁面級別監聽那些埋點的節點，並且恰當的時機傳送統計程式碼，簡化版如下：
// 相同的引數傳送給所有已接入的統計平臺，如果平臺不同，適配工作也在這裡做
const sendEventLog = (name, type, param) => {
_hmt.push([`_trackEvent`, name, `click`, param]);
_gaq.push([`_trackEvent`, name, `click`, param]);
};
// 針對單擊事件的處理，其他事件可以類似處理
$(body).on(`click`, `[data-event-name][data-event-type="click"]`, function (e) {
// 拿到事件發生的節點
const target = $(e.target);
// 獲取事件屬性
const name = target.attr(`data-event-name`);
const param = target.attr(`data-event-param`) || ``;
if (!name) {
return;
}
// 這裡如果是連結跳轉，需要走單獨的邏輯
sendEventLog(name, `click`, param);
});複製程式碼上面探討了從 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