什麼是全棧工程師

全棧工程師（Full-Stack Engineer），是一個在IT行業圈子裏愈來愈熱門的話題，不管是像Facebook這樣的大型公司，仍是剛剛起步的初創公司，都開始招募全棧工程師。聽說，Facebook聲稱：「咱們只招全棧工程師！」

Facebook只招全棧工程師？

「全棧」是一個外來詞，對於中國讀者而言，會以爲它很陌生。當我第一次對某人提到「全棧工程師」時，他一頭霧水：「全棧？您是說全端工程師嗎？」

其實，「全棧」翻譯自英文full-stack，表示爲了完成一個項目，所須要的一系列技術的集合。「棧」是指一系列子模塊的集合。這些軟件子模塊或者組件組合在一塊兒便可實現既定功能，再也不須要其餘模塊。

全棧中的「棧」與計算機數據結構中的「堆棧」不是同一個概念，後者是指先入後出的串行數據結構。順便說下，「隊列」是指先入先出的串行數據結構。

IT行業以外的人其實很難理解Web開發是多麼複雜的工程。人們通常認爲，在計算機公司或者互聯網公司工做的人，就應該可以解決與計算機相關的全部問題：電腦開不了機、應該買什麼型號的手機、家裏上不了網，等等。在他們眼中，計算機行業的從業者天生就帶有「全棧光環」。

可是拿着這本書的您知道，要開發一個Web頁面，工程師須要掌握的知識至少包括：服務器（好比Linux）、數據庫（好比MySQL）、服務器端編程語言（好比PHP）、前端標記語言和腳本語言（HTML、CSS、JavaScript）等。這些技術中的每個，都須要幾年的學習和練習才能達到精通的程度。Web工程是一個如此大的專業類別，以致於IT公司爲每個環節都設置了專門的部門和崗位，來把每個環節作好。

服務器、數據庫、服務器端編程語言、HTML、CSS、JavaScript等組合在一塊兒就是一個「棧」。這個「棧」是用來製做Web站點的，因此又叫Web棧（Web-Stack）。

若是要開發一個在手機中運行的應用，開發者須要的知識包括：服務器、數據庫、服務器端編程語言、iOS或者Android開發技術。這些技術的集合稱爲App棧（App-Stack）。

一個簡單的web棧模型：包含前端技術和後端技術。

咱們知道，前端工程師就是負責頁面瀏覽器端編程的人，後端工程師就是負責服務器端編程的人，那麼什麼纔是全棧工程師呢？

對於全棧工程師，業界並無嚴格的定義，並非說必定要一種都不能少地具有哪幾項知識才能叫作全棧工程師。我傾向於認爲，應該從能力和思惟方式兩方面，來斷定一我的是不是一個合格的全棧工程師。

國外是怎麼定義全棧工程師的呢？在著名的問答網站Quora上有人提出了這個問題。一個得到了高票的回答是：

全棧工程師是指，一個能處理數據庫、服務器、系統工程和客戶端的全部工做的工程師。根據項目的不一樣，客戶須要的多是移動棧、Web棧，或者原生應用程序棧。

基本上，當客戶須要一個全棧工程師的時候，客戶須要的是一個全能的「大神」。簡單來講，全棧工程師就是能夠獨立完成一個產品的人。當客戶讓他去作一些溫馨區以外的工做時，他勇於迎難而上，併成功完成任務。

咱們每個工程師，進入到公司和企業工做以後，就會有一個職位頭銜。個人職位頭銜是「UI工程師」，其餘人的頭銜多是「交互設計師」「PHP開發工程師」，等等。「全棧工程師」不須要頭銜。他既有全面的技術能力，也渴望跨界工做的狀態。

「全棧」好像是一個高不可攀的夢想，因此對於初次瞭解「全棧工程師」這個概念的工程師而言，有可能以爲「難以想象」或者抱着「這不可能」的排斥心理。但若是咱們回頭看看Web開發的歷史，就知道「全棧」其實沒那麼難。

Web開發流程

有人曾開玩笑說，全棧工程師是資本家的陰謀，由於老闆想僱一我的來作三我的的工做。

其實在2000年第一次互聯網泡沫破裂以前，那時候的Web工程師也許符合「全棧工程師」的簡單定義：一人包攬整個網站的構建。

那時的Web工程師們所面臨的挑戰比今天小不少，他們可能只是製做一些靜態的頁面，不會面對現在富交互的Web應用程序。那時網站可能包含數據庫和一些HTML表單，但僅此而已，甚至只須要將一些靜態頁發佈到服務器上。在網站的前端無需視覺設計和交互設計，由於網站屈指可數，市場競爭很小，工程師僅用一些基本的HTML標籤和閃亮的GIF圖片就能夠吸引網民的目光。同時，網站訪問量都比較小，前端資源的體積也不大，無需關注服務器壓力和CDN，網民對加載速度的容忍度比較高，也不須要過多考慮用戶體驗。

但隨着技術的發展、用戶量的增長、客戶端種類變多，每個小小的細節都須要優化和考慮。在海量的訪問量面前，也許改變一個按鈕的位置和顏色就能影響上千萬的訂單。現在的互聯網產品已不是以一己之力就能夠完成的樂高積木了，Web開發須要以某種可控的方式來管理。

因而，全部認真對待互聯網產品的大公司都引入了流水線開發流程，在這條流水線上誕生了多個很是專業的職位。

產品經理：產品經理實際上是對一個產品負根本責任的管理者。他一般的工做包括制訂產品規劃、協調多方資源、把控產品方向和質量細節，等等。有時候，他會從頭策劃一個新的產品，而更多的時候，他是在優化已有產品的一個部分。總之，在流水線中，產品經理須要從策劃跟進到發佈，是一個很是重要的角色。

用戶研究員：用戶研究員的工做是研究用戶行爲，有時候他會從宏觀的角度分析數據，有時候也從微觀的角度分解用戶場景，有時候會召集一些用戶專門來訪談，或者觀察用戶對產品的使用狀況。從輸出品的角度來講，用戶研究員通常輸出用戶研究報告來交付給產品經理和交互設計師，做爲產品設計的目標參考。

交互設計師：交互設計師常被簡稱爲「交互」。他與視覺設計師最大的區別是，交互設計師更多着眼於如何優化用戶界面的信息分佈和操做流程。交互設計師的輸出品通常是描述用戶與網站「交互」過程的流程圖，以及描述頁面信息結構的線框圖。輸出的線框圖會交付給視覺設計師。

視覺設計師：在細分交互設計師和視覺設計師的大公司，視覺設計師根據交互設計師輸出的線框圖來作一些潤色和設計，輸出最終的產品視覺稿以後將視覺稿交付給前端工程師。在一些不細分交互設計師和視覺設計師的小公司，兩者被統稱爲「設計師」，他們的職責就是負責整個用戶界面的設計。

前端工程師：產品視覺稿在獲得產品經理和交互設計師等多方確認以後，會交給前端工程師，由前端工程師製做頁面，實現視覺稿以及交互功能。從頭銜上的變化就能夠看出，這時候才真正開始編碼。前端工程師須要很是熟悉HTML、CSS和JavaScript，以及性能、語義化、多瀏覽器兼容、SEO、自動化工具等普遍的知識。

後臺工程師：使用服務器編程語言，進行服務器功能的開發。在編程語言的選擇上，不少公司都會出於團隊已有成員的知識儲備、程序員的供給量或者語言性能方面來進行選擇。在這一方面，後臺語言的選擇是相對自由的一件事，不像前端工程師，爲了頁面兼容性，必須使用HTML和CSS。若是關注各大公司招聘信息的話，您就會了解，不一樣公司使用不一樣的後臺語言，好比傳統的C#和C++、Java、PHP，或者新潮的RoR和Python。小公司的後臺工程師除了負責功能開發，可能還會負責服務器的配置和調試、數據庫的配置和管理等工做。在大公司，這些工做會分別委派給後臺工程師、運維工程師、數據庫管理員（DBA）等崗位。

運維工程師：運維工程師是跟服務器打交道的人，他會關注服務器的性能、壓力、成本和安全等信息。

測試工程師：顧名思義，測試工程師保證產品的可用性，即便在小公司，這一職位也是不可或缺的。

流水線的優點

因爲有了流水線，其中每一個職位的可用工做時間都會做爲「資源」來管理，所以須要一位項目經理來把控項目進度，並對人力資源進行調控。好比一個項目立項時，就要預定好這個週期版本須要實現哪些優先級較高的特性，而把優先級不那麼高的特性推遲。對於肯定在這一週期要實現的特性，就要安排本週進行設計、下週完成開發、下下週進行測試等。

在項目管理中，常常會用到甘特圖。甘特圖（Gantt Chart）是柱狀圖的一種，顯示項目、子項目、進度以及其餘與時間相關的系統的進展狀況。

流水線在大公司的任何一個嚴謹的大型項目裏都是必不可少的，由於不管是Web產品仍是App產品，它的複雜性都已經超出了單個工程師能夠控制的程度。經過把複雜度分解到各個組件，每個組件就能夠進行很好的質量控制。

用於項目管理的甘特圖。

Web頁面的生成和傳遞須要經歷複雜的過程，所以容錯能力就是首當其衝要考慮的問題。數據從位於深圳某個機房裏的服務器傳輸到用戶手機瀏覽器頁面上進行運算和渲染，這個過程當中的每一個環節均可能出錯，因此每一步都要作好容錯處理。若是服務器出現錯誤，是否能在30秒內切換到備用機？後臺數據異常時返回什麼結果給前端，等等。

Web頁面能夠在無數種設備上顯示。兼容性在此時成爲了前端工程師須要考慮的一個重要問題。不一樣的用戶在不一樣手機上瀏覽頁面，顯示的方法會有些許不一樣，甚至要考慮到若是瀏覽器不支持JavaScript，則須要給出特定的提示。模塊化的Web開發流程在很大程度上提升了服務的可靠性和可用性，讓咱們對每個環節都能單獨進行測試。這讓大型Web開發真正變得可管理、可控制、質量可評估。

模塊化的Web開發流程在很大程度上提升了服務的可靠性和可用性，讓咱們對每個環節都能單獨進行測試。這讓大型Web開發真正變得可管理、可控制、質量可評估。

流水線帶來的另一個好處是，產品以團隊的方式來運做和生產，公司不會過於依賴某一個工程師。團隊即便失去某個工程師，其餘人也能夠接手他的工做，快速理解他負責的那一部分工做內容。對於有些經理來講，寧肯僱用多個可管理的普通工程師，也不肯意聘請一個不可管理的天才工程師。

因此到如今，咱們能夠看到大部分互聯網公司都會招聘不少專門的工程師，好比前端工程師、交互設計師，還有一些具體到實現語言的工程師（好比PHP程序員），這都是爲了提升可靠性、可用性和可管理性。

剛纔咱們說到，一個基本的Web棧由服務器、數據庫、服務器端編程語言、HTML、CSS、JavaScript構成；一個基本的App棧由服務器、數據庫、服務器端編程語言、手機客戶端編程語言等技術構成。您可能已經注意到，App棧跟Web棧在後臺技術上幾乎是徹底相同的，只有在跟用戶最接近的那一端採用了不一樣的技術——要麼使用HTML製做用戶界面，要麼使用客戶端編程語言製做用戶界面。

這是由於，不管是Web仍是App，本質上都是軟件，它的架構方法是相似的。服務器端接收數據和發送數據，它無需關注客戶端採起何種技術製做用戶界面。客戶端處理用戶交互以及顯示數據，它不關心服務器使用的是Java仍是PHP。若是說開發一款軟件就像製造一輛汽車，那麼服務器端就像動力系統，客戶端就像汽車的車身，不一樣的動力系統和車身能夠自由組合搭配（我不太熟悉汽車的製造過程，這裏只是做個比喻）。

服務器和客戶端之間經過HTTP協議傳遞信息。正是由於HTTP協議的通用性，使得服務器端和客戶端得以實現徹底的技術分離。不管是開發Web服務仍是手機裏運行的App，一套後臺開發技術，能夠爲全部的前端展示方式實現軟件的商業邏輯。

HTTP協議相似於汽車組裝過程當中的一個通用標準，動力系統和車身都要採用這個統一的標準來實現纔可能完美對接。

用戶量的大小、服務器承受壓力的能力、軟件對服務器計算量的要求、對服務器響應速度的要求……諸多因素會影響開發者決定使用哪種後臺技術。汽車的動力性能主要由發動機來決定，汽車廠商也會根據市場需求、消費者定位和制形成本等綜合考慮使用哪種發動機。

而前端技術是根據產品所面向的用戶來選擇，這要看用戶是更喜歡用瀏覽器仍是手機應用來使用服務。就好像汽車的造型要考慮消費者喜歡什麼樣式的外觀。

若是兩者功能分離得當，後臺服務跟前臺服務通常能夠自由搭配，互不干涉。

若是服務器邏輯和客戶端邏輯分離得當，兩者能夠自由搭配。

「各司其職」的弊端

雖然流水線式的職業劃分和工程管理有不少優勢，可是它就像一把雙刃劍，在帶來高可控性、可用性和可管理性的同時，也給工程師帶來了一些困境。

工程師職責不清致使效率低

由於分工太細，因此在不一樣職業的交接處每每會有一些既不屬於上游，也不屬於下游的「灰色地帶」。

這部分工做沒有明確規定由誰去作，因此有時候時間會浪費在溝通上。員工會認爲本身的頭銜表明了本身的責任邊界。好比，一個前端工程師可能會不加思考地實現視覺設計稿，由於他的崗位說明裏規定了本身的職責，這其中不包括質疑設計稿，因此他忽視了本身的最終目標：讓產品更好。

在一個開放平等的環境中，他實際上能夠對影響可用性和性能的設計提出本身的想法。甚至若是他很熟悉這個項目的話，對設計的一致性和一些交互細節均可以說出本身的見解。

工程師缺少主人感致使產品質量差

流水線工做流程對專精工程師的要求是，能很好地執行動做或者執行任務，而不須要對產品的目標有很好的理解。其實在工程師的初級階段，執行任務的能力是必需的，由於他尚未能力把握產品的目標，並且也須要更多的練習來提高專業能力。但隨着經驗的積累，若是工程師還不能對產品總體有本身的理解和貢獻，就很容易缺少主人感，要麼他會跳槽，要麼產品自己缺少亮點而致使失敗。

工程師缺少全局的視野影響我的成長

當工程師但願晉升到更高級的職位，如高級工程師或者管理崗位時，公司對他的大局觀會有更高的要求，這就不只僅是作好「份內」的工做就行的。

高級工程師須要有對設計的理解、對後臺知識的瞭解，以及有跨團隊推進項目的能力。長期研究專精的專業知識會讓一我的視野變窄，變成「學術派」，而不是「實踐派」。

更多角色致使項目效率低下

軟件工程項目與工業中的標準流程化項目有一個很大的區別：標準流程化項目中每個流程所接受的輸入都是同樣的，所須要的輸出也都是徹底相同的。

好比，一個汽車生產流水線，將「造汽車」這個任務分解成「造輪胎」「造方向盤」等。流程拆分得越細，每個工人或者機器人就能作得越快，整個流水線就會運轉得越快。可是在軟件工程項目中，咱們把任務拆分給多個角色，每個角色須要一樣多的時間去理解需求，在上下游時間的安排中也每每會增長一些緩衝時間，好比周一安排設計，可是爲了防止延期風險，會安排週三再製做前端頁面。每個角色的工做時間都會變長，並且交接也增長了緩衝時間，這樣整個項目的時間就會被延長。

全棧工程師登上舞臺

由於各司其職的工做流程有效率低下、成本高的缺點，因此不少創業公司都不會配備齊全的流水線，而是但願採用更靈活的方式來組建團隊，全棧工程師也所以成爲了理想的選擇。可是全棧工程師的興起還離不開這兩個重要因素：技術的發展，以及提供PaaS服務的平臺愈來愈多。

根據StackOverflow在2015年進行的開發者問卷調查，有32.4%的開發者是全棧工程師，這一比例連續三年來逐年上升。

您是哪種類型的開發者？截圖來自2015年StackOverflow開發者調查。

技術的發展

提到全棧技術，不得不提一個表明性的全棧框架——MEAN，它是MongoDB-Express-AngularJs-Node.js的縮寫，是從數據庫、服務器到前端頁面的一個完整技術棧。

MongoDB是一個面向文檔的、NoSQL類型的數據庫。MongoDB顛覆了傳統的基於表的數據存儲方式，而採起了相似JSON的文檔結構來存儲數據，於是它在儲存數據時能夠更加靈活。

Express是一個Node.js框架，能夠建立靈活的Web服務，好比單頁面應用程序、多頁面應用程序和混合型App。

AngularJS是一個開源的JavaScript框架，由Google和開源社區共同維護，它用來建立單頁面應用程序。它的目標是使用model-view-controller模式來規範Web應用程序，讓開發和測試富交互的單頁面應用程序變得更加輕鬆。

Node.js是一個運行在服務器端的JavaScript運行環境，它的底層是基於Chrome的JavaScript運行環境——V8引擎。Node.js能夠做爲服務器端語言，用來建立快速、可擴展的應用程序。Node.js也能夠在本機運行，作一些本地操做，好比加速本地開發流程，或者實現一鍵發佈。

MEAN能夠說是傳統的LAMP方案的有力競爭者。由於從服務器端到頁面端都採用一樣的語言（JavaScript）和一樣的架構模式（MVC），因此一個擅長JavaScript的工程師能夠兼顧先後端的開發，而且前端模板代碼和後臺模板代碼是能夠複用的。

提供PaaS服務的平臺愈來愈多

隨着Web技術的發展和開源社區的積極努力，有不少公司提供便宜又方便的一條龍服務，能夠解決獨立開發者的大量麻煩。

好比Amazon提供的PaaS（Platform as a Service，平臺即服務），就可讓創業公司的開發者省去架設和維護服務器的麻煩。

而GitHub在2012年得到了一億美圓融資，也能夠看出市場對代碼託管市場的信心。能夠預期，將來可能會出現愈來愈多爲開發者提供服務的公司。之後，小公司也能夠用更低廉的價格得到世界級的IT服務支持，毫無疑問，更多的IT服務將託管在第三方的服務器上。

VPS（Virtual Private Server，虛擬專用服務器）是把一臺物理服務器虛擬成多個虛擬專用服務器的服務。每一個VPS均可分配獨立的公網IP地址，運行獨立的操做系統，擁有獨立的磁盤空間、內存、CPU資源、進程和系統配置，模擬出「獨佔」使用計算資源的體驗。

EngineYard爲開發者提供一條龍服務（截圖來自www.engineyard.com）。

全棧工程師的發展前景

紀錄片「壽司之神」講述了86歲的頂級壽司製做者小野二郎的故事。小野二郎心懷追求極致的匠人心態，終其一輩子，他都在握壽司，永遠以最高標準要求本身跟學徒，觀察客人的用餐情況，微調壽司，確保客人享受到究極美味。他的壽司店只有10個座位，上廁所都須要去店外的公共場所，可是這樣一間小店得到了米其林三星的頂級評價，這意味着僅僅爲了享受美食就專程來到這個國家都是值得的。我想小野二郎就是專精工程師的表明，他日復一日地磨練和提升本身的技藝，他不會想要上市或者在全國開滿連鎖店，也不去追逐更大的商業回報，只爲了本身心裏對完美的追求。

確實，全棧工程師不是惟一成功的方式，也不是全部工程師的最終歸宿。不管您是渴求成就感，仍是物質回報，都有不少路徑能夠達到。若是能在任何專精的職業中努力作到名列前茅，就能得到巨大的回報，就像頂級的壽司製做者小野二郎。

而我推崇的全棧工程師則是與專精工程師不一樣的另外一條道路。全棧工程師除了在一個專精知識領域有深刻研究以外，還以知識廣博和解決問題能力強著稱。因此我認爲有志成爲全棧工程師的學習者，要有這樣幾個覺悟。

一專多長

我跟一位行業專家討論過全棧工程師的話題，他不是很贊同全棧工程師這個方向。他認爲，工程師應該有專精的技能和目標，若是初學者貪圖大而全，反而樣樣不精。我理解他的擔憂，若是一個工程師沒有堅實的基礎（好比專業理論知識，對經常使用設計模式的理解，或者特定職業的基礎知識），那麼瞭解的非本專業技能越多，越容易迷失。

因此我認爲，全棧工程師首先要「一專多長」。

一專多長的意思是，工程師首先有一個專精的方向，在這個方向上足夠精通以後（高級工程師級別），以此爲突破點去學習更多的知識，增長本身的長處。若是尚未得到某個方向上足夠深刻的理解，就不要囫圇吞棗地去學習其餘領域的知識。

全棧工程師最好「一專多長」。

有些知識須要時間的積累，並非快速閱讀就能夠掌握的。「全棧工程師」這個名詞可能會引發讀者的誤解。勿在浮沙築高臺，「全棧」是一個長期積累的過程，是專精型工程師在不斷解決問題的過程當中積累知識和經驗所造成的能力，而不是一蹴而就的過程。

解決問題，而不是醉心技術

公司存在的意義就是解決問題，公司要解決用戶的問題，而員工要解決公司的問題。

公司的問題多是下降成本、擴大用戶羣、增長成交量、優化性能，等等。不一樣的問題優先級不同，投入一樣的時間，有的項目能爲公司增長上百萬的收入，而有的項目卻只能增長几萬。

互聯網領域發展很快，問題的優先級永遠都是在動態變化的，因此團隊每每每半年或者三個月就要回顧一下當前形勢，並制定新的工做計劃。若是新計劃不是您擅長的，怎麼辦？您應該立刻開始學習新的技術，這就是我說的關注問題，而不是醉心技術。

不管我的的目標和興趣是創業，仍是單純但願學習更多的技術，或者學習項目管理，全棧工程師都是一個不錯的努力目標。而隨之而來的收益也是很是大的。

在大公司，程序員逐漸由初級工程師成長爲高級工程師後，在專業技術能力上不斷接近極限，公司對工程師的要求也逐漸提升，特別是要求他擴大「影響力」。如何創造更大的影響力？影響力就是跨界解決問題。高級工程師能夠選擇往上下游去擴展本身的能力，並承擔更多的責任，給公司帶來更大的收益，也給本身帶來更大的成長空間。

在創業公司作工程師會因爲「形勢所迫」不得不作不少不熟悉的工做，也就是「溫馨區以外」的工做。雖說小公司沒錢聘請更多員工是最直接的外在因素，可是全棧工程師的成長並非靠外力，而是自我驅動。程序員在小公司裏主動去承擔更多責任，本身跟公司都會得到相應的成長。假如公司上市擴張，本身能得到鉅額的回報，即便公司失敗，本身也能得到鍛鍊。

在自由職業市場，全棧工程師是最閃耀的明星。由於全棧工程師能獨立創做產品，因此很容易被市場接納。好比WordPress主題設計、App開發、網站開發，等等。全棧工程師也能輕鬆搭建本身的做品網站，而不像後臺工程師的做品那樣，不太容易展現的後臺組件。

全棧工程師仍是天生的創業者，由於本身能夠獨立完成一個產品模型，因此能夠用最快的速度去測試本身的想法。從工做中鍛煉出來的發現問題、洞察需求、設計解決方案並開發出初始版本產品的能力，是全棧工程師最大的優點。也許這就是爲何有些創業者說「咱們就差一個程序員了」的時候，程序員們都會把他當成一個笑話。

總之，全棧工程師是一個可以在全部場合發光發熱、實現我的價值的職業。在將來，中國也會涌現出愈來愈多優秀的全棧工程師。

最後，關於上文中提到的「Facebook只招全棧工程師」是一條謠傳。從公司文化的角度來說，Facebook鼓勵員工以開放的心態解決問題，不由於本身的頭銜給本身設限。他們仍然招聘各類職位，您能夠在官方網站上找到正在招聘的職位。我在Facebook參觀的時候，看到一面牆上貼着寫有「DONE IS BETTER THAN PERFECT」3的海報，在此與君共勉。

 

來自 <http://blog.csdn.net/liushu_it/article/details/48229849>