前端工程師是一個無關緊要的職位嗎？

---

沒有無關緊要的職位， 只有無關緊要的人.

醬油的後端也不在少數...

保持競爭力，不要妄自菲薄， 但是也不要抱著那些所謂的前端技能樹自我滿足。

我能想到幾個讓PO主燃起來的例子：

1. 搜一下Threejs，PhiloGL的DEMO, 你應該會感嘆：「前端好牛逼，可以用canvas做這麼炫的東西」. 在振奮之餘， 你要看清的真正起決定性作用的是那些牛牛們的 計算機圖形學基礎和GL的相關經驗. canvas僅僅只是容器， 那些API的學習成本真的無足掛齒。

2. 當你看了D3.js，你會發現， 數據可視化也完全可以在Web前端實現， 我們好牛逼. 但是仍然要潑盆冷水， 建議你去看看D3.js發展的完整歷史.

3. 當你看其它開源使用esprima.js 分析javascript, 或是使用jison來實現自己的解析器、編譯器時，你會發現編譯原理這個看似和前端八竿子打不著的東西， 現在也越來越緊密了起來。但是jison還是bison，它們真的區別不大，僅僅只是使用javascript實現而已。

所以涉及到基礎知識領域區分度要遠大於某個語言或平台。 好在是目前前端能容納的知識領域越來越廣，這將需要由更專業的人來完成工作, 所以我們的路還可以走的很長。

綜上所述，那我們現在就討論前端是不是無關緊要的職位是不是太早了點

---

看了知乎上這麼多討論關於前端這個職位的問題, 什麼關於前端難不難, 好不好找工作, 有沒有用, 好不好學, 好不好轉其他的職位, 待遇好不好等等的問題, 想談談自己對前端的看法.

到底所謂的前端都應該幹些什麼都應該會寫什麼呢? 本人身邊有太多的人會切幾張圖, 會用jQuery做個特效, 會從bootstrap里複製粘貼, 會用html遊戲框架寫個flappy bird, 會在Github里找各種模板自和庫拼拼湊湊, 就口口聲聲大言不慚的稱自己為前端工程師. 說什麼前端好簡單啊, 前端找工作好難啊, 沒有出路啊, 想轉行啊. 甚至有更多的人還不明白什麼是HTML, 就到處問(知乎里尤其多)怎麼開始學前端啊, 前端前景好不好啊. 依照本人的經驗, 什麼東西難不難, 什麼東西好不好, 可不是這樣問出來的. 我相信在這在這種網路信息資源及其豐富的年代, 花個半小時自行搜索一下你應該可以得到你想要的答案.

好了言歸正傳, 前端工程師真的是一個無關緊要的職位么? 我們先來看看前端工程師都要做些什麼, 看看那些稱自己是"所謂"的前端同學們都能走到哪一步.

這裡直接跳過最基本的HTML+CSS+JS, 包括但不僅限於:
- HTML各種element怎麼用什麼時候用?
- Event? EventLitsener? HTML中觸發event以及JS中處理event?
- DOM tree? 添加? 修改? 刪除? 搜索? 遍歷? 選擇? children? parent? sibling?
- 什麼是window? 什麼是document?
- JS基本語法? function? loopcondition? scopeclosure? arrayobject? this?
- CSS 什麼是box modal? position? float? 各種選擇器(*, &>, ~, :nth-child)?

如果看到這裡有任何一項完全沒聽說過沒用過, 或者查各種文檔後"大概"知道怎麼用的同學們, 很遺憾, 你們現在算不上是一個合格的前端工程師. 如果不是, 請繼續.

### 程序員的基本素質和知識

(有些人覺得前端不同於傳統意義上的程序員, 這點我十分不贊同. 或許把前端工程師叫做JS程序員更加貼切, HTML和CSS就好比其他語言中的UI庫)-

- 高數, 基本的概率統計 (連簡單的微分方程都不會解的朋友們就不要稱自己為前端人員了!)
- 基本數據結構 能用JS寫出linked list, stack, queue, (binary)tree, graph, hashtable么?
- 基本演算法 能用JS實現各種search(linear, binary..), 各種sort(bubble, insertion, merge, quick, selection), 以及樹的搜索(Breadth First/Depth First)和遍歷(3種順序)么?
- 設計模式 知道什麼是singleton, factory, strategy, decrator么?
- Git 不要只是停留在把Github當做一個網路儲存器的層面上, 知道branch, diff, merge么?
- 基本的英語能力(不要求聽說, 只用來讀/寫文檔資料)
- 基本的計算機知識 知道位運算, 溢出, thread, lock, concurrency, parallelism么?
- 熟悉unix的基本命令么? 知道ssh public/private key都是幹嘛的么?
- 知道正則么? 能夠熟練的使用么?
- 能寫出詳細的注釋/文檔, 讓閱讀你代碼的人知道你要幹嘛么? 能短時間內快速地讀懂來自你同事或者其他地方(github, blog)的代碼, 知道什麼東西應該寫在什麼地方, 以便迅速地參與其中么?
- 給你一個你從來沒有接觸過的庫/語言, 能能夠在較短的時間內在你的代碼里正確使用么?
- 有一個得心應手用的熟練地編輯器/IDE么? 不要求大家都是vim/emacs大神, 但也不要做什麼都是用滑鼠來點.
- 基本的檢索查詢能力(google, stackoverflow, MDN)
- 單獨思考解決問題的能力, 團隊合作, 與人相處

如果以上的內容都有所了解(這裡不會強調精通), 恭喜你, 你擁有了成為前端工程師的基礎知識. 繼續.

### 前端專業知識
- 知道什麼是AMD, COMMONJS么? 知道call, apply, bind么? 知道JS中foreach, filter, some, every么? 知道怎麼實現functional JS(curry等)么?
- 知道各種所謂的高級HTML的API(File, Web Audio, WebSocket)么?
- 知道各種CSS Preprocessors么? 能講出他們各自的優點和缺點么? 熟悉並且會用其中的一種么?
- 知道各種CSS框架么? 能講出他們各自的優點和缺點么? 熟悉並且會用其中的一種么?
- 知道canvas, SVG么?
- 知道怎麼把你的東西做成responsive, cross-browser support么?
- 知道什麼是SEO並且怎麼優化么? 知道各種meta data的含義么?
- 知道什麼是Ajax, restful, get, post么? 知道怎麼和後台交互么?
- 知道各種JS框架(Angular, Backbone, Ember, React, Meteor, Knockout...)么? 能講出他們各自的優點和缺點么? 熟悉並且會用其中的一種或多種么?
- 知道什麼是webkit么? 知道怎麼用瀏覽器的各種工具來調試和debug代碼么?
- 知道現在前端一般的工作流程(gulp, grunt, git, svn, npm)么?
- 知道怎麼測試代碼么? 知道BDD, TDD, Unit Test么? 知道怎麼測試你的前端工程么(mocha, sinon, jasmin, qUnit..)?
- 知道前端templating(Mustache, underscore, handlebars)是幹嘛的, 怎麼用么?
- 知道npm, V8, node, express, socket么? (這裡補充一點, 現在越來越多的公司都採用: "前端網頁 -&> 前端後台 -&> 後台"這種構架來搭建東西, 也就是說, 前端工程師不僅要做傳統前端的網頁, 還要寫自己的後台, 來跟真正的後台進行交互, 至於前端的後台用什麼語言來寫, 一般是node/python/ruby, 不太會用到龐大的java, 所以這裡我把node列為前端工程師必須要掌握的技能之一) 知道cache, authentication么?
- (如果要用node)知道route, middleware, cluster, nodemon, pm2, server-side rendering么?
- 另外, 前端這個行業跟傳統的c/c++/java程序員還是有一定的差別的. 由於是新興產業, 所以各種行業標準, 框架, 庫會隨時隨地的產生和更新 (作為一個c程序員, 十年前怎麼寫東西現在還是怎麼寫東西). 今天出了node和react, 明天又出了io和mean. 所以, 積極關注各種前端產品, 跟上變化的節奏, 也是身為一個前端程序員必備的技能之一. 知道ECMAScript 6里怎麼寫class么? 知道react, flux, reflux么? 知道polymer, dart么? 知道meteor么?

(暫時能想到的就這麼多, 待補充..)

在從包括google, facebook, apple等各大公司的面試, 以及周圍做前端小夥伴們的經歷中, 發現現在在美國, 沒刷過3, 4遍cc150和leetcode的同學們都只敢投投簡歷不敢去面試, 因為覺得鐵定過不了...

附上一些之前親身經歷的面試題:

#### Facebook 1:

Puzzle Materials
Given a set of events, render the events on a single day calendar (similar to Outlook, Calendar.app, and Google Calendar). There are several properties of the layout:

1. No events may visually overlap.
2. If two events collide in time, they must have the same width.
3. An event should utilize the maximum width available, but constraint 2) takes precedence over this constraint.

Each event is represented by a JS object with a start and end attribute. The value of these attributes is the number of minutes since 9am. So {start:30, end:90) represents an event from 9:30am to 10:30am. The events should be rendered in a container that is 620px wide (600px + 10px padding on the left/right) and 720px (the day will end at 9pm). The styling of the events should match the attached screenshot.

You may structure your code however you like, but you must implement the following function in the global namespace. The function takes in an array of events and will lay out the events according to the above description.

function layOutDay(events) {}
This function will be invoked from the console for testing purposes. If it cannot be invoked, the submission will be rejected.

In your submission, please implement the calendar with the following input:

[ {start: 30, end: 150}, {start: 540, end: 600}, {start: 560, end: 620}, {start: 610, end: 670} ];

FAQ
Are frameworks such as JQuery, MooTools, etc. allowed? Yes, but please include the file with your source code.
Is there a maximum bound on the number of events? You can assume a maximum of 100 events for rendering reasons, but your solution should be generalized.
What browsers need to be supported? Your solution should work in all modern standards-compliant browsers.
Does my solution need to match the image pixel for pixel? No, we will not be testing for pixel matching.
How will you be testing my solution? We will be running tests from the browser console by invoking the layOutDay() function. Your solution should not require a local web server (e.g. run from localhost) or have any other dependencies besides your html/css/js.

#### Facebook 2:

Question: How would you flatten an array in JavaScript?

Answer: flatten of an array means, if one or more array elements are also array, you will took out those elements and you will have a plain array. For example, if you if array is like [1, 2, [3, 4], [5, [6, 7]], 8] your flatten array would be [1, 2, 3, 4, 5, 6, 7, 8]

#### APPLE:

Given a node from a DOM tree find the node in the same position from an identical DOM tree.

#### Google 1:

Question: How would you flatten an array in JavaScript?

Answer: flatten of an array means, if one or more array elements are also array, you will took out those elements and you will have a plain array. For example, if you if array is like [1, 2, [3, 4], [5, [6, 7]], 8] your flatten array would be [1, 2, 3, 4, 5, 6, 7, 8]

#### Google 2:

Alex is standing on the top left cell (1,1) of a n*m table. The table has n rows and m columns. Initially, he is facing its right cell. He moves on the table in the following way:

&>He moves one step forward.
&>He turns to his right
&>While moving forward, if he would go out of the table or reach a visited cell, he turns to his right.

He moves in the table as much as he can. Can you find out the number of cells he visits before he stops?

For example, given a 9x9 grid, the following would be his moves. The number on each cell represents the step he would land on that particular cell.
1 2 55 54 51 50 47 46 45
4 3 56 53 52 49 48 43 44
5 6 57 58 79 78 77 42 41
8 7 60 59 80 75 76 39 40
9 10 61 62 81 74 73 38 37
12 11 64 63 68 69 72 35 36
13 14 65 66 67 70 71 34 33
16 15 20 21 24 25 28 29 32
17 18 19 22 23 26 27 30 31

Input:
The first line of the input contains two integer numbers n and m.
n and m are between 1 and 100.

Output:
Print an integer to the output being the answer of the test.

Sample input #00:
3 3

Sample output #00:
9

Sample input #01:
7 4

Sample output #01:
18

從這些面試題可以看出的是, 前端工程師也是程序員, 面試同樣逃不出各種演算法和數據結構的問題, 同時還會被問很多前端專業領域的東西, 引用Facebook HR給我發的一封郵件中的一句話:

The primary technical focus of these interviews will be JavaScript, HTML, and CSS, but at Facebook we are software engineers first, and web specialists second. This means that there may be a sufficient amount of focus on general computer science concepts like algorithms, design patterns, data structures, etc.

(翻譯: 技術面試的主要會集中在JS, HTML和CSS. 但是在Facebook, 我們首先應該是一個軟體工程師, 其次才是web的專業人員, 這意味著相當大的一部分面試會涉及到cs的知識比如演算法, 設計模式和數據結構等等.)

另外想到一個之前面試Amazon的一道題, 覺得特別好. 寫出來跟大家分享(大神們見笑了~):

問題: swap two integers without temp (交換兩個整數, 不能用任何臨時變數)

一般答案是這樣的:

function swapNumb(a, b){
console.log("before swap: ","a: ", a, "b: ", b);
b = b - a;
a = a + b;
b = a - b;
console.log("after swap: ","a: ", a, "b: ", b);
}

&> swapNumb(2, 3);
a: 2 and b: 3
a: 3 and b: 2


如果你這麼寫面試官會喜歡你:

function swapNumb(a, b){
console.log("a: " + a + " and b: " + b);
a = a ^ b;
b = a ^ b;
a = a ^ b;
console.log("a: " + a + " and b: " + b);
}

&> swapNumb(2, 3);
a: 2 and b: 3
a: 3 and b: 2


所以, 那些成天"所謂"的前端工程師們(只是針對某些朋友), 請不要再誤導即將或者想要跨入這個行業的新同學們了. 那些想要涉及前端行業的同學們, 首先不要覺得跟其他語言程序員相比前端的門檻低, 更不要覺得前端是一個可有可無的存在. 前端(程序員)掙得多待遇好, 因為我們值這個價錢. 如果羨慕或有興趣就請努力學習思考然後加入這個圈子裡來.連一個花10秒鐘google(baidu)一下就能知道答案的問題都要拿到知乎上來問的朋友們, 請不要毀了知乎這麼好的一個平台, 另外那些什麼東西都"大概明白"的朋友們, 請不要在以一個前端工程師的視角來說一些"毫無意義"的話.

咦, 氣氛突然嚴肅了, 哈哈哈, 以上內容不針對任何人, 隨便吐槽兩句, 如果有不對的地方和不妥當的內容請指正, 謝謝!

---

看你做什麼產品了唄。

所謂無關緊要，就是隨時能找到替代者唄。很多時候不在於能不能找到，而在於隨時。

你做 vs code/gmail/office online 這樣的產品，那我覺得你團隊裡面每一個應該都挺寶貴的，畢竟失去了一個不是隨便就能找到替代者的，又得有技術，又得快速理解業務和代碼。

當然我舉的可能是比較極端的例子，可是現在市面上很多應用的前端都很重啊。你說石墨文檔的前端復不複雜，厲不厲害？teamabition 的前端復不複雜，厲不厲害？

或者還有些單個功能點看起來可能沒那麼難的產品，比如bat這種大業務，那麼多，變化那麼快，不保持一個強有力的團隊，怎麼可能跟得上？這樣的團隊絕對不是臨時搭的草台班子能勝任的。這不是說我現在有一百個人，走一個就無所謂，一個高速運轉的團隊，少一個人可能真的會產生很不好的影響。

在大公司工作的人最近肯定有體會，現在社招挺不容易的，物色一年，其實也沒多少人能達標又願意跳槽的。所以世界沒那麼大，如果找人的節奏跟不上產品迭代的節奏，那這個團隊對業務來說就很寶貴了。這不是技術含量決定的，可能一個更難的工作，找到替代者更容易。

---

如果我說是，你會信嗎？前端其實既不是「非要不可」也不是「可有可無」。

P.S. 其實這跟問「顏值是不是無關緊要」差不多，大多數人都不能僅僅靠顏值吃飯，但又肯定是顏值越高越有優勢。

---

How dare you!

---

就我的理解而言，前端的重要性並不在於 @haochuan 所提到的各種知識棧，因為細枝末節地說起來，每個技術崗位總有各種難點，不足為證。況且難和重要之間，我總覺得還是有些差距的。

在我看來，「前端」——不精確地可以定義為所有直接和用戶打交道的關節，是用戶感知到這個網站對自己誠意的直觀反映。

就像一個人長得漂亮，你或許就願意多看兩眼。慢慢聊著覺得原來這人太膚淺，是個銀樣蠟槍頭。但反過來，如果這人長得很醜，即使擁有一顆美麗的心，恐怕願意去了解的人也實在是需要一些慧眼的。
所以，前端工程師做的事，就是用有誠意的第一印象，儘可能多地給用戶了解網站更多內涵的機會。
要嚴格追究起來，當然每個職業都重要，否則也不存在這個職業了，這麼討論就沒意思了。我這裡說前端重要，是說它的確值得被關注被重視。

網頁剛剛誕生的年代，用戶只關心內容。後來，網頁樣式作為輔助有效閱讀的工具被採納，用戶覺得「哦，加粗的地方是站長想強調的」，但他們並不在意網頁有多「好看」。再後來，平面設計師把他們的經驗借鑒進來，用戶驚訝地發現原來網頁也可以有品味的差別。網頁設計風格亦如巴黎當季服裝設計風格那樣潮起潮落，人們開始把「現在流行 material design 啊」這樣的話掛在嘴邊。不僅如此，隨著 T 台上一次次奇裝異服的發布會，觀眾開始意識到衣服可以有聲音，可以有味道，我們的網頁也終於變得幾乎無所不能。
這是一個從原始人吃生食，到發現了火，吃上熟食，再慢慢學會用佐料進行烹飪的過程。在吃不飽飯的年代，當然沒人在意豆腐腦是甜的還是鹹的好吃。然而人類這種永遠不會滿足的生物，吃飽了撐的自然要對飲食提出更高要求，進行更多探索。
近年來「前端工程師」越來越受到重視，難道不正是這種「倉廩實而知禮節，衣食足而知榮辱」的進階追求嗎？

至於說優秀的前端工程師難找，我想說（來找我啊~）不是因為低頭寫代碼的人太多，抬頭望星空的人太少；而是這兩件事都做的人太少。

或許每個行業的人都會把自己做的事說得很重要是一個不爭的事實，更何況程序員又格外偏好「改變世界」那一套（雖然作為道家思想擁護者的我是很反對的）。
前端很重要，它決定了用戶看不看；網站內容本身更重要，它決定了用戶看多久。把前端說成是網站的「包裝」或許有些自降身價，但我覺得倒也不失為一個很好的比喻：
只有當你的產品本身是高大上的，恰到好處的包裝才會讓其錦上添花；反之，如果產品本身是個空殼子，卻妄圖通過包裝令其脫胎換骨，那麼，

或許前端是沒什麼用吧？

---

從0到0.1
從0.9到1

前端工程師都能幫你滿足

---

我一直說前端low是因為後端工資高。
到你這裡怎麼就變成無關緊要了？
你老闆是誰啊，喜歡給無關緊要的人每個月開那麼多工資，我想推薦幾個無關緊要的人來混吃混喝行不行？

---

作為一枚前端工程師，試答一下。

個人覺得程序員是 **連接虛擬數字世界和現實世界的橋樑** 。 而前端工程師是程序員在工作細分過程中， 直接負責對接用戶的一環。前端工程師的目標就是將虛擬世界的數據更好地呈現給普通用戶。 因此我們會考慮： 頁面秒開率，用戶體驗， 數據可視化，用戶留存等等內容。

想想老版本的終端命令行式交互吧， 它將與虛擬世界交互的權利限定在了精通計算機知識的一小批精英人群手中。

而現在， 哪怕是給任何一個小孩兒一部iPad，他也能點點感興趣的網頁， 自己玩兒的很歡。

打一個比方， 如果程序員是在努力構建一棟數據世界的大廈 ， 那麼前端工程師就是在負責這棟大廈的整體的裝修工作， 我們會考慮用戶如何進入大廈更便捷， 採用什麼樣的色調讓用戶覺得更溫馨， 各類開關設置在何處用戶使用起來更方便。 我們和交互設計師一起，精心實現這棟建築的內外裝飾, 讓用戶可以在合適的地方得到想要的服務。

如果拋去目前分工狀態下前端的工作，用戶進入的僅僅是一棟還未裝修的毛坯建築。

---

既然存在就有必要，因為相應的，後端工程師會依賴你的工作，期待你的成果能夠讓他專註於業務與存儲邏輯的實現；設計師會與你溝通，詢問某某效果能否實現，期望你的成果能助力他們的設計。

但是假如項目很小、公司不大，依賴文藝復興工程師們的自由發揮，區分前後端工程師就毫無意義了。

拋開情境討論問題真是沒意思啊…

---

後端工程師是一個無關緊要的職位嗎？

演算法工程師是一個無關緊要的職位嗎？

設計師是一個無關緊要的職位嗎？

產品經理是一個無關緊要的職位嗎？

別人覺得你的工作無關緊要又怎樣，最後還是要給你工資，別人可以無限鄙視你的工作，但工資一分錢不能少，要是薪水給的不讓你滿意，你就換一個覺得你緊要的公司來工作，就這麼簡單。

---

一個職位重要不重要，更合理的判斷是看這個職位的產出，對於產品當前的目標達成有多大的貢獻。這個判斷對於任何職位都適用。
哪怕是同一個公司、同一個產品，在不同的發展階段，職位的重要性也是會變化的。
所以，最關鍵的是自己在做職業發展抉擇時，找到最能夠發揮和體現自身價值，能夠幫助產品達成關鍵目標的職位。

---

給題主分享一篇一位從「前端」走出去的同學，嘗試做「無線研發工程師」的感想。他說，摘掉「前端」這個title的人，不是老闆，而是這個時代。Title已經不再重要，時間會證明一切。

作者：岑安

以下為分享全文：

開始著手寫這個文章的時候，心生感概，好像終於在業務上階段性的理順了一些事情和代碼。可以擠出那麼一點點時間寫寫自己這一兩個月以來的感受了。

前段時間一直在業務壓力中，熟悉代碼，改代碼，堆代碼。甚至都沒來得及好好的想想業務的加分項，包括可做的更有價值的事情。
原因就是因為組織架構的調整，我們從前端職能走出去，接手了一整塊業務。從前到後，從客戶端到服務端。
而我個人作為團隊的領跑者，作為從「前端」走出去的同學，一定是要先行在跨端跨棧這件事情上的。以便給團隊同學鋪好路，讓大家都能更輕更快的過度到新的「業務職能」中去。

回頭翻我在組織架構調整後第一周的周報，有這麼一段感慨：

「英雄不問出處」，我們是無線研發工程師

這次組織架構調整，前端團隊垂直到業務線，更多的不應該是人從一個大的前端團隊劃分成好幾塊，匯到業務線上做小的前端團隊，那一點意義都沒有。而應該是團隊形態，職能，人的心態一起的變革與升級，技術取向從業務出發，技能拓展從人出發。

「前端」這個詞在這次調整之後，對於我個人，對於團隊而言，都不再那麼重要了 。我自己到今天為止，做了將近6年的「前端」了，說沒有情結，或多或少都有一些。我也自認在「前端」這個領域上有一些認知和沉澱，然而時不我待，無線時代的迅速崛起，端側越來越重的體驗和功能，都在開始挑戰著當下的技術分工。

我說，要求我們走出單一職責，甚至摘掉「前端」這個title的人，不是老闆，而是這個時代。

Web2.0在PC的時代，一個網站，所有的業務幾乎都承載在瀏覽器上，泛泛而談，技術上無非兩種人，「前端」和「後端」，基本就能Cover掉整個業務的實現。
然而無線的時代，移動設備App的崛起，OS和平台的差異，導致同樣一個業務，簡單的看，需要四種技術人才來支撐，「IOS開發」，「Android開發」，「前端開發」，「後端開發」。

且不說時間成本，人力資源成本從2個變成4個都會是一個巨大的包袱和挑戰。集團不是說我們的人才策略從「平凡人做非凡事」變成「非凡人，平常心，做非凡事」了么，既然我們自命「非凡」，那必然要求我們可以承擔的更多，所以，技術棧的拓展，無論從時代還是集團策略來看，已經是必然。

挑戰往往也預示著機遇，我本來還有些偏執，說趁著這次的調整，乾脆把自己和團隊的職能titile摘掉，不再是「前端工程師」，而是「無線研發工程師」。

然而轉念，英雄不問出處，路是要靠自己走出來的，團隊的轉型也不是我一個人的轉型，整個大的無線技術團隊也都需要做「端」的融合這件事情。在「事」的維度我們已然做了不少嘗試了，Hybrid，Weex等等，是時候在「人」的維度做些「融合」的努力了。

Title已經不再重要，時間會證明一切。

到今天為止，總算也是完成了在IOS，Android客戶端一個完整的功能性需求的迭代，服務端能力也隨著業務的bugfix，feature的更新有新的迭代和發布。至此，我上周在周報裡面說，終於標誌著我們從前端走出去的小團隊有了完整的無線技術棧研發能力。

回頭看IOS和Android

不得不說，頂著壓力學習的過程是痛並快樂著，這跨年的一個多月以來，我經常說自己有好長時間時間沒有過這種每天都看得見自己技能和知識的成長的這種充實的過程了。
每天都有新的輸入，有新的知識入賬。這是以前做「前端」已經好長一段時間無法得到的體驗了。

然而痛苦的點是我在得到這種知識輸入的快感時是頂著業務風險和壓力的，在我不熟悉的領域，我會像一個新人一樣對一個需求能做到什麼程度，需要多少時間沒譜... 同時作為一個業務的技術owner，還不得不背負業務需要快速迭代，使勁往前跑的責任。

這是我巨大的壓力所在。

所幸通過一個月時間的磨礪，通過一個完整業務需求的迭代，基本算是理順了包括IOS，Android在內的業務代碼和研發流程。
對端上技術這個領域似乎也有了更廣度的認知。

從前端的角度來看，客戶端IOS，和Android也有很多看似相似的地方，年前在做技術大團隊的「前端技術棧培養」課程的時候，我大概理了一下端上方案的一些共性：

不得不說編程，或者是UI構建，在某種程度上都是通的。甚至讓我想起了在學校時代做MFC編程，原來UI的世界都是這樣八九不離十，瞬間讓我覺得端側技術的世界變得好小...

同時也會發現，前端的世界和客戶端比起來，有太多美好的地方，但是也有太多糟糕的地方：

• 前端的同學們拼死拼活做工程化這件事情，做到今天，感覺頗成規模，但是對比起IOS環境，完善度和規範度瞬間感覺是戰5渣
• 前端同學們拼死拼活做的各種組件化方案，基於React也好，基於Vue也好，感覺終於可以做到聲明式，可嵌套，內聚解耦... 但是Android的layout和組件方案似乎天生就有這種feature...

前端的不足讓「前端」這個領域在一步步往「軟體工程」這個方向走的更近。

然而前端在UI構建調試的即時性是客戶端開發同學們心裡永遠的痛。

• 保存即更新，保存即可見，這在Web領域已經是常態。然而在客戶端，特指「手淘」這個龐然大物背景下。每次代碼的更新和調試都是心裡的傷。尤其是Android...
• 我經常開玩笑說在Android做業務的同學，估計有一半的時間花在了打包上面 。 大家可以想像改一行代碼需要打包2~3分鐘才可見可調 這種感受么？

能力最大，責任越大

業務職能垂直化這件事情，我相信我們正走在一條對的路上。對於我們過往的「前端同學」，是一個挑戰，也同樣是一個機會。

當我們拋開了職能的概念，當我們具備了業務所需的所有研發能力。那我們對於業務會有更好的判斷和歸屬。有更順更合理的方式做新的嘗試和創新。

當我們從技術上能整個Own一塊業務的時候，我們要想的就不再是怎麼去支撐PD或者PM同學的需求了，而是怎麼讓這塊業務跑的更快更好。並且我們也有了能力和責任去讓他跑的更快更好。

回頭再來看 「無線研發工程師」 這個Title，忽然覺得好有使命感和厚重感。在當今移動大時代的背後，我希望有一天我自己和我團隊里的同學都能順理成章的贏得這個Title。

而這一天，我看著，正在到來！

原文地址：http://click.aliyun.com/m/32801/

---

說點別的，何必把自己局限在"前端"二字里，另外，又何必過分糾結"前端"的邊界，需要的不過是各種限制因素下作權衡把事情解決的儲備罷了。

---

你問了一個哲學問題，我沒法從前端技術的角度回答你。

但這讓我想起一位「前端工程師」 ，T. J. Cobden-Sanderson。一名 19 世紀的印刷匠、書籍裝幀師，Doves 字體的創造者。我一直都覺得前端工程師與排版工作者很相似，只是應用場景不一樣的另一種稱呼吧。

在 1916 年的 8 月到 1917 年的 1 月這段時間，Cobden-Sanderson 持續地在哈默史密斯橋（Hammersmith Bridge）西側丟棄 Doves 字模。 他只在黃昏後進行這項活動——從酒館半英里外的裝訂所出發，前後花了約 170 次，丟棄的金屬活字總量多達 1 噸。起初，他將整頁的活字矩陣投入河裡。漸漸地，他像喂鳥一般將字模從口袋裡一個一個丟出。後來，他找到了一個帶滑蓋的小木盒，自己用膠帶做了把手，能很好地將活字撒入水中，同時又不易被路人察覺。

這個犯罪般的舉動，一方面出於私人怨恨—— Cobden-Sanderson 不想讓字體落入 Walker (他的搭檔) 的手中；另一方面則出於他對手工藝的熱愛之情——使用 Doves 的書可能不再是自己精心印製的，只要想像一下這種情況他就十分痛苦——這同樣也因為他對當時的新技術及生產變革非常厭惡。Cobden-Sanderson 痛恨機器化的工業生產方式，在日記中也曾寫下：只有將字體交給泰晤士河，它們才永遠不會被「不用人的手和胳膊印刷的出版社」所使用。[1]

對於多數人來說，不曾聽說過這套字體，也辨認不出字體間的區別。在他們眼裡，Cobden-Sanderson 所作作為，是無關緊要的。可對於 Cobden-Sanderson 本人，那是他智慧的灌輸，努力用系統知識所創造的美好事物。

前端工程師是無關緊要的職位嗎？更多時候是非此領域內的人得出的評價，他們的眼裡不過是一個頁面，一堆可點擊的超鏈接。可是在一位職業的前端工程師眼裡，文字排版中所運用「音階」、「節拍」等韻律，以及為了更快的載入時間，所進行的性能壓榨。其中的樂趣，不為外人所感受，僅有自身沉浸在其中。

所以無關緊要，其實取決於你是否用智慧灌輸，並努力用系統知識創造美好事物。

[1]: 「鴿子」：出版社、字體和復刻

---

是啊，前端一點都不重要，缺了前端公司馬上可以再找一個，不就是一個月一萬兩萬的成本而已嗎？

有錢拿就夠了，還要爭寵，挺招人煩的。就好像明明都結婚了，還天天問你愛不愛我。

如果你 boss 說前端不重要你是要辭職還是咋地。

好好做事，變成重要的人，跟你是不是前端毫無關係。別整天守著你那前端一畝三分地。

公司的 CEO 重要，你去當 CEO 唄，前提是你有那個本事呀。

---

這麼說吧，前端的概念目前正在擴展，現在慢慢已經變成了所有和用戶端呈現和展示相關的開發的集合。
所以實際上無論是pc客戶端(比如qq現在把一個程序分成了前端qq.exe和後端ts.exe兩個部分)，web前端的ria spa這些概念，android ios上用的後台服務進程和展示分離，都是在加強和獨立前端的職能。
不過由於前後不分離對於小項目成本很低，越大的公司才越需要前端，題主如果不是很開心現在的工作，可以考慮跳槽

---

簡單的答案是不是。

如果需要讓這個答案更詳細，需要弄明白前端工程師的界限在哪裡。首先任何一個工程師的首要職分不是炫技，也不是為了記住這些細節知識而通過面試，而是為了完成工作。為了完成工作不要求你懂得一切語言細節，懂得一切語言細節也無法讓你成為『合格的』前端工程師。就像雇一個殺手的最終目的是要去殺人，而不是精通一個很長的列表上的所有武器。譬如你是個使用狙擊槍的高手，但是你正坐在你暗殺對象的對面，而你的手邊有一隻削尖的鉛筆，你也知道該怎麼做。

我做過三年的fullstack engineer，但是終於因為自己的精力不能夠勝任所有環節的開發，我需要把我所認為的和用戶交互的部分交給另一個人做（是的，所以我正在找前端工程師）。那麼我首先希望這個人有工程師的基本素養（一切工程師都應該有的，土木，機械，一切。）

1. 能夠把一項工作描述清楚。一個人對自然語言的駕馭能力決定了寫代碼能力的高度。

2. 知道自己不知道什麼。不知道不要緊，可以用的時候再查，但是要知道到哪裡才能查到。你需要有自己的專業知識資源庫（可以把它稱作mind-set或是knowledge portfolio），你需要的東西並不太多。緩存的工作原理是基於一個叫做theory of locality，即CPU在90%的時間裡訪問著整個存儲系統中10%的數據和代碼，這是為什麼緩存可大大提升計算機性能。同樣，你在90%的時間裡會使用你10%的知識和技能，用的時候再查，不必全都記住。

3. 知道怎麼去查。首先最好能比較精通英文，並且使用Google。Google的優點是會在搜索結果中替換英文的同義詞，所以下一次搜索時你就可以使用被替換的同義詞。總體來說獲取知識的重要環節是反覆修正自己的問題。只有提出精確的問題才能得到精確的答案。另外每次搜索，你要看前十頁的內容，如果覺得內容多，是因為閱讀速度不夠快。這需要下功夫。

4. 能夠估計項目每個環節的時間，和各種可能的不確定因素，這也是有了足夠多的實踐經驗後才會擁有的技能。

5. 寫可以維護的代碼。模塊化，用精確恰當的函數名/變數名/參數名/對象名。任務拆分恰當。你不一定看過《設計模式》的書，但是最終你會發現自己摸索出來的可維護性最好的代碼規範和《設計模式》講得差不多。

確認了工程師的基本質素之後，前端工程師要承擔以下工作：

1. 完成和後端的交互。在這部分需要考慮的是數據的延遲，譬如要用模版，還是用jQuery動態載入DOM，以及其他可能的方案。

2. 前端本身的業務邏輯。譬如我做的是WebGL，從後端得到的是模型的數據描述，但是展現在前端的是一個3D模型，中間發生的一切要前端工程師來做。或者應該這麼說，如果業務邏輯是在客戶端，即使你是某個專門的工程師，譬如像我是做WebGL的，也算作是前端工程師。

3. 完成和用戶的交互。前端工程師要考慮如何完成信息的最後一次變化，確保展現在屏幕上的信息可被用戶正確理解。比如要保證每個按鈕，組件觸發的動作符合它本身的描述（就是所謂的Rule of least surprise），或是讓屏幕上的組件分布符合信息組織的規律（尚不討論美學層面），這都是前端工程師分內的工作。

4. 如果你自己做美工，那會涉及到一些CSS的細節。如果你不做美工，而是和一個美工合作，那麼你需要把一個參數化的CSS切出來，讓與你合作的美工不必與這些技術細節打交道。當然你自己也至少要懂一些配色與布局的基本原則。

一言以蔽之，前端工程師完成從數據到可被用戶理解（最好是帶著愉悅的心情理解）的信息這樣變化的流程。在項目中非常關鍵，也是很辛苦也需要經驗積累的工作。如果你是懷著希望能進一步提高用戶對信息的理解和體驗的願望，那麼作為前端工程師還有很多東西可以做，請加油！

---

前端不重要，用戶體驗不重要，數據安全性穩定性不重要，高性能不重要，內容不重要，錢不重要

只有吃的是永恆的！

---

有人刺激到自己，讓自己受傷，說自己其實一點也不重要的時候，我就會聽歌，當然選擇是原諒他啦！

聽見冬天的離開

我在某年某月醒過來

我想我等我期待

未來卻不能因此安排

陰天傍晚車窗外

未來有一個人在等待

向左向右向前看

愛要拐幾個彎才來

我遇見誰會有怎樣的對白

我等的人他在多遠的未來

我聽見風來自地鐵和人海

我排著隊拿著愛的號碼牌

...

---

推薦閱讀：