我們真的缺前端工程師嗎？

前言

這兩天在好幾個地方都看到了一篇關于為什么整個互聯網行業都缺前端工程師？的文章，文章本身是去年的，中心思想是：其實我們并不缺前端工程師，我們缺的是優秀的前端工程師。我還是比較同意作者觀點的，不過略有意猶未盡的感覺。于是我結合自己的經驗，也來聊一下這個話題：我們真的缺前端工程師嗎？

 These walls are kind of funny like that. First you hate them, then you get used to them.Enough time passed, get so you depend on them. That’s institutionalising.

傳統軟件公司劃分開發者的方式下，在前端部門的程序員永遠不會去讀緩存數據部分的代碼，設計師也不太可能去和開發坐在一起，開發也不知道軟件最終軟件會以何種方式部署在服務器上。

什么是“前端”工程師

我在招聘廣告和辦公室的一些對話中，聽到了一個新的角色：UI Dev，事實上我在知乎上還回答過一個關于ThoughtWorks的UI Dev的問題。簡而言之，UI Dev可以快速的把設計師的作品實現為HTML/CSS/JavaScript代碼。

如果按照這個標準，我覺得UI Dev對自己的要求太低了。畢竟要學會HTML/CSS實現mockup并不困難，但是成為一名前端工程師則需要掌握更多的知識：

• 會用PS來進行圖片的處理（比如切圖，微調等）
• 用HTML/CSS實現mockup（可能還有SASS/LESS等工具）
• 熟悉JavaScript（比如前端的MVVM框架，客戶端模板）
• 前端開發的工作流程（代碼檢查，精簡化，模塊化CSS，LiveReload，調試）
• 編寫測試（靜態檢查，單元測試）
• 跨瀏覽器、跨設備的解決方法（不同分辨率，不同廠商）
• 會根據項目的特點選擇不同的前端技術棧（移動端，Web站點，響應式設計等）

在有了基礎的HTML/CSS/JS技能之后，你會嘗試做的更好：

• 如何更高效的操作DOM
• 如何將CSS寫的更加清晰易懂
• 如何編寫更加易于維護的代碼（更有意義的單元測試）
• 如何組織大型的項目結構，模塊化，組件化等等

這些要求事實上已經不那么容易做到了。它可能會花費你2到3年時間來完全掌握。但是2到3年之后，即便你已經成為了一個“合格的”前端工程師，這也還遠遠不夠。在現實世界中，一個軟件產品除了前端，還有非常廣闊的空間，還有很多有趣的東西值得學習：

• HTTP協議本身（緩存，鑒權）
• Web容器/HTTP服務器如何工作
• 無狀態的Web應用的工作原理（如何讓網站正確地運行在集群上）
• 動態，靜態內容如何分離部署（反向代理配置）
• 安全機制如何配置
• 監控機制如何配置

有了這些，也算是有點端到端的意思了。這時你也已經不是一個“純前端”工程師了，系統中的大部分問題你都可以搞定，不過日常工作中可能更多的職責還是做前端的開發。但是這些還不夠，軟件除了交付之外，還有一些非功能性的需求：

• 端到端測試（UI測試，比如selenium server/web driver）
• devops（比如數據庫環境，測試服務器，CI服務器的自動化provision）
• 基本的UI設計原則（在某些頁面確實的情況下，根據系統的已有UI做設計）
• 數據庫性能優化
• 性能測試

不過這些還只是我對于Web開發這個領域的總結。其他領域，比如大數據，機器學習，GIS，圖像/視頻處理等等。

這時候，你才能算是一個嚴格意義上的“前端”工程師。不從系統的角度來思考，不真正做一些后端開發/配置，并不能算是前端工程師，或者可以被稱為偏前端工程師（partial frontend developer）。但是即使稱為上邊這樣的“前端工程師”，我想這離一個優秀的工程師還是有很大差距的。

我跟一位設計師同事聊過這個問題：

 Dev眼中的世界是這樣的，從墻上（物理的或者電子的）上找到一些卡片（story卡或者需求文檔說明書），然后擼袖子開干，干的過程中有很多自以為是的 理解，同樣有一些自以為是的牛逼實踐（TDD啊，自動化啊），最后功能做完，大功告成，然后接著做下一個卡片。傳統的Dev，或者苦逼屌絲程序員的世界就 是這樣的：需求從哪兒來，不知道；做完之后誰來負責質量，不知道；最終上線的時候怎么發布，不知道；線上有問題了怎么辦，不知道。

以及

 在ThoughtWorks，Dev的工作有了很大的變化，一個最明顯的變化是邊界的模糊。比如很多項目都不設QA角色，所有人都對質量負責，都做測試， 也有OPs角色，但是大部分非生產環境都是Dev自己發布。也就是說，軟件/項目生命周期中的大部分實踐我們都能涉足，而且可以帶來改進，提升效率。但是 這只是往下游（從開發，到測試，到部署，到運維），反過來看上游，比如需求從哪兒來，Dev還是不知道。這毫無疑問是一個令人沮喪的事實，因為這需求的產 生才是核心，也就是我昨天跟你聊的：一個idea如何變成一個可視化的原型，然后進一步演進為項目原型？

開發工作不應該僅僅局限在編碼上，作為開發者/工程師，應該盡可能的多了解一些上下文：比如我們的項目最終是給誰用的，需求從何而來，項目是如何部署在線上的等等。

簡而言之，開發者視野應該放開開闊一些。不要將自己局限在某種角色上，不但不要局限在前端/后端開發上，壓根就不要局限在開發這種角色本身上，你在 系統中，可以是設計師，還可以是業務分析師。雖然不一定最終要你去轉行做BA，或者UX，但是更廣闊的視野可以使你更加高效的發揮自己的作用，也可以在和 別的角色互動式，快速的了解上下文。

我所理解的，前端不一定要熟知所有這些知識和技能，但是一定不要認為自己做好了前端的一畝三分地就足夠了，不要給自己設限。跨界會給你帶來難以估量的好處，一個角色做久了，難免會產生一些盲點。這時候，換個視角，從其他角色的角度來看待你的工作，又會有很多新的發現。而且不僅如此，很可能你會發現之前很麻煩，很難搞定的事情，在新的方法/視角下變得很容易。

我的故事

其實，我是一名后端開發

工作之后，我在很長一段時間是專注于“非前端”的領域。和很多剛入行的新人一樣，我對計算機能觸及的幾乎一切領域都感興趣：語言解釋器，人工智能 （遺傳算法，隱式馬爾科夫模型，自動糾錯，模式識別），嵌入式開發，圖形處理，操作系統的進程調度，進程間通信，多線程模型，各種腳本語言 （python，ruby，JavaScript等等），另外，日常開發流程中的一些工具的定制化也會花去我很多的時間，比如如何配置vim，寫幾個小腳 本來和編輯器做集成等等。更別說那些令人一聽就覺得激動的編程范式：面向對象，基于消息總線，函數式編程等等。如果你感興趣，可以看看我幾年前的博客。

我的上一家公司的產品是一個省級電網的收費/計費系統（電其實和我們在超市里購買的其他生活用品一樣，也是一種商品）。我在那里工作了差不多兩年， 日常的開發方式就是ssh登陸到RHEL（Redhat Enterprise Linux）服務器上，用vim（當然有一堆的vim插件）開發C代碼，調試器是gdb（對，就是那個很牛逼，但是對新手特別不友好的gdb）。

我們用C語言給Apache的httpd寫了一個擴展module，大約相當于現在rack里的中間件，這個module要和后端的一個要復雜的多 的模塊通信，其中不但涉及網絡通信，還有*nix管道，緩沖，并發等等考慮。在這兩年里，我幾乎沒有碰過任何的Web界面上的東西（除了用php寫了一兩 百行的頁面之外）。

在加入這家公司之前，我在一家用Java做報表的公司工作，技術棧為J2EE。其中有一些前端的工作，但是并不很多，而且說實話，我當時有些看不太上這些技術。HTML/CSS在我心目中的地位比線程池，語言解析等差遠了，所以我也沒有認真地去系統學習。

在加入ThoughtWorks之前，在“前端”方面，唯一算是比較擅長的也不過是寫JavaScript，而且對于前端的MVVM框架，雙向綁 定，模塊化等高級貨都沒聽過。且不能論HTML/CSS的最佳實踐，連根據設計稿做出一個靜態頁面的的能力也不具備。我之前有一點JSP/HTML經驗， 而CSS經驗也并沒有超出如何畫一個細線表格的范疇。換句話說，我的前端（特別是HTML/CSS）是最近才學會的。

ThoughtWorks的開發

在ThoughtWorks，很多團隊是按照feature團隊來組建的。相對于傳統的component團隊（按部門劃分，比如研發組，測試組， 設計組等，每個組還有可能會再細分成如用戶調研，流程設計，視覺設計等等），feature團隊里配備了軟件開發過程中需要的幾乎所有角色：業務分析，測 試工程師，開發工程師，設計師（設計師一般不會常駐），有的團隊還有項目經理的角色。

在feature團隊里，你可以很容易看到不同的角色是如何工作的，很多時候，開發會和設計師一起來調整顏色，排版，布局，也可能和測試一起編寫自 動化測試用例，showcase等。也就是說，角色之間的藩籬在淡化，而就開發這一種角色而言，對于前端/后端的區分也會顯得非常模糊，因為需求劃分之后 的story（敏捷開發中的一個術語，其實就是需求的一種展現方式）是端到端的，比如一個商品列表展示的story，會包括

• 數據庫的表結構
• 訪問數據庫的ORM部分，
• 使用ORM的業務邏輯service
• 響應客戶端的controller（消費JSON或者XML的HTTP接口）
• 發送請求，處理響應的JavaScript代碼
• 和設計稿一致的CSS樣式

而且在這個過程中還會涉及到一些外圍的工具

• 虛擬機環境準備
• 數據庫連接
• 自動化測試（單元測試，集成測試，可能還有UI測試）
• 數據庫遷移腳本

在這個過程中，開發者需要掌握和開發過程相關的一切實踐中的一切工具.

在我的ThoughtWorks的第一個項目中，我是以Java開發工程師角色加入的，下項目的時候，我學會了自動化provision，cucumber測試工具，Rails，gradle（沒錯，我之前用Java都是用IDE構建的，在Linux世界我用make），jasmine測試工具，Backbone.js，haml.js。

第二個項目的時候，我是以前端工程師角色加入，下項目的時候，我學會了nginx配置緩存、負載均衡服務器，gatling測試工具，Hadoop/Spark等的集群配置，還有一些和項目相關的GIS（地理信息系統）的技術棧，前后端分離策略等。

第三個項目我是以Java開發工程師角色加入的，下項目的時候，我學會了如何做性能測試，如何建立一個漂亮的Dashboard（可以用來展現CI等），而且在業余時間系統的學習了CSS3和HTML5，將之前零敲碎打的那些知識串起來，這些總結做了幾次內部培訓后，還整理成了一本電子書。

第四個項目我又變成了一個前端工程師，但是這個項目有意思的地方是跟mobile相關，于是頁面性能，體驗又變成了一個重點，下項目的時候，我對無狀態的Web應用，session的持久化，CSS3的動畫，用Backbone.js組織多頁面的方式等等又有了新的理解。

如果這些經歷造成了你覺得我很牛的錯覺，那我應該道歉。我覺得自己勉強可以算是個合格的程序員：對學習保持著熱情，對解決問題保持著熱情，僅此而 已。在項目上，如果我發現了問題，我就想辦法解決，如果屬于知識欠缺，那我就會去學習。我還遠遠沒有到達精通這些技術的地步，但是在工程實踐領域，根據80/20原則，這些粗淺的知識足以解決80%的問題，而另外的20%，我們才真正需要一個專家來幫忙。也就是說，團隊里需要有一個能解決20%的問題的前端工程師，而其他的80%的前端工作，應該可以被其他所有的開發完成，對于后端開發也是一樣。

嘗試從系統級別去解決一個問題，而不是將問題拋給另外一個角色（后端工程師，UX或者QA）

我是一個Dev，但是花了一些時間來學習界面設計，這里是我從設計到實現的兩個小頁面：

總結

我們缺的從來都不是前端/后端工程師，而是工程師(或者那些會系統思考，并總是想著解決問題的人)。角色劃分在大的機構內可能是有意義的，就像歷史上工廠里，工人被分為車工，鉗工，木工，電工。但是這種模式在軟件開發中未必好用，具體而微的 小團隊可能更具競爭力。而在一個個的小團隊中，再細分前端后端就顯得比較滑稽了。團隊中的每個成員都應該具備基本的端到端能力（不僅僅是開發，更應該是具 有業務上下文，即每個人都清楚我們要交付的最終產品是什么，以及這個產品是如何幫助最終用戶的），每個成員也都需要為最終的交付物負責，而不是為自己的職 責負責。

來自：http://icodeit.org/2015/06/do-we-really-short-for-front-end-developer/