怎樣成為全棧工程師（Full Stack Developer）？

11-24

成為全棧工程師一般的學習路徑是怎樣的?

補充一下Full Stack Developer的定義和標準：What is a Full Stack developer?，這樣大家討論怎樣成為Full Stack Developer時不會偏的太遠。

Is it reasonable to expect mere morals to have mastery over every facet of the development stack? Probably not, but Facebook can ask for it. I was told at OSCON by a Facebook employee that they only hire 『Full Stack』 developers. Well, what does that mean? To me, a Full Stack Developer is someone with familiarity in each layer, if not mastery in many and a genuine interest in all software technology...

既然原文是說，Facebook 工程師說 Facebook 只招 full stack engineer，那我就來說說 Facebook engineer 都是怎樣的人啦。

我覺得任何一方面的具體經驗都不重要，重要的是思維方式和學習能力。首先說思維方式，那就是不為自己設限，不會想著自己是前端工程師，所以後端的東西我就一點也不碰。Facebook 的工程師，級別越高就需要保持越大的影響力。如何創造更大的影響力，就是尋找當前槓桿效應最明顯的問題來解決。有些問題你解決了的話，投入進去的時間每小時能換回來一千美元；有些問題你解決了的話，投入進去的時間每小時能換回來一百萬美元。然而哪些問題更值得解決，這是動態的，往往還存在衰減效應。如果現在性能瓶頸在後端，你做了一個季度兩個季度優化後，瓶頸就已經不在後端了，你再優化下去衰減效應就會越來越明顯。等瓶頸變成前端了，你是不是就說因為你不懂，所以不願意碰？那就相當於寄望於公司有個前端很懂性能優化的人來解決，但如果公司沒有這樣的人那就沒有人來解決了。

Facebook 的眾多海報當中，有一張寫的是「任何一個 Facebook 的問題，都不是別人的問題」。有問題，你就需要去評估是否值得解決。如果值得解決，你就應該著手去解決，而不是假設公司內會有另外一個人比你更合適解決這個問題。這時候很可能你就需要去做你從來沒有做過的事情，需要學習你原本可能完全不懂的技術。如果你是個專門做數學模型的博士，加入 Facebook 原本是打算做搜索結果優化的，結果發現這不是最急需解決的問題，JavaScript 性能才是最需要解決的問題，你怎麼辦？如果你以為 Facebook 需要的是你做數學模型的經驗，那你就錯了。Facebook 需要的是你完成博士學位的學習能力。你從來沒做過 JavaScript 並且覺得 JavaScript 很噁心？正確的做法是立即在網上買幾本 JavaScript 入門的書連夜看完，然後著手分析性能瓶頸並且解決。在你完成手動優化後，你還可以思考一下能否把這做成自動化，例如說在代碼提交時分析 JavaScript 語法樹並且指出可能成為性能瓶頸的地方，又或者說從用戶瀏覽器那裡收集性能數據扔到 Hive 然後再從中分析產生瓶頸的特徵。這些都可能涉及到一些你沒有做過也沒有學過的東西，但問題擺在那裡你就需要去解決，而無論這要求你去鑽研什麼。這就是我所說的學習能力。

這是高級工程師和初級工程師的主要差距。儘管在高級到初級這一維度上，美國工程師和中國工程師是有重疊的，但美國的教育體系和行業傳統使得美國應屆生比一般中國工程師更偏向於高級那一端。美國學生的優勢在於，他們的教育體系讓他們習慣面對開放性問題。一家公司萬千問題當中，此時此刻哪一個最值得解決？這不是中國工程師擅長的問題，因為實在是太開放了。中國教育讓人擅長在給定條件下解決問題，太開放反而不知道從何入手。此外因為絕大多數文獻都是英文的，所以要鑽研什麼對於能讀懂英文的人來說都可以非常成體系的學習，這對於很多拒絕閱讀英文的中國工程師來說很不利。拒絕閱讀英文意味著永遠只能接受別人的二手資料，對於很多概念的理解只能停留在技師的層面，而無法上升到工程師或者科學家的層面。

做這樣一個簡單的 app:
一個天氣應用，乾淨清爽的界面，天氣信息一目了然。它不僅可以精確預測未來 10 天的天氣，還可以顯示某地的歷史天氣信息。它具有自定義提醒功能，支持 web 版本， iOS 版， Android 版。

為什麼想要做這樣一個 App ？因為你喜歡旅行，但沒找到一個天氣 App 可以提供你下個月或者某個特定月份的天氣信息；因為你懶你沒有每天看天氣預報的習慣，你想要在第二天溫度達到 30 度以上或者溫差有 +/-7 度的時候，獲得溫馨提示；因為你要成為一個 Full Stack Engineer ，你必須不斷訓練每個 stack 的能力。

## Web版
你決定用 MySql 來存儲用戶數據，用 NoSql 存儲歷史天氣數據。你用 Redis 作為 cache ，緩存一些最常請求的天氣數據。你用 Python 寫後台，功能簡單，後台不複雜，用戶註冊登錄，抓取返回某城市的天氣數據，某地的歷史天氣數據，很快便搞定。

後台開發並測試好了，接下來是 Web 前端。你十分清楚一個好的 UI 設計對一個 App 的重要性，你也明白 UI 的設計不只是為了美觀，更重要的是提高信息的可讀性和程序的可用性。幸好你平日的積累這次派上用場了。你把之前保存下來的上百個優秀的UI設計作品拿來研究，你從書架上拿出Norman 的那本經典 - The Design of Everyday Things 重新細讀。最終你用白紙黑筆敲定了第一個版本的 UI，簡潔直觀，沒有任何多餘的設計，所有元素的排列間距大小顏色都恰到好處。你相信即使天氣不好，但用戶只要使用這個 App 都會有著愉悅的心情。

那麼開始寫前端吧。啊，別急，都忘了還有 Icon 和 Logo ，可是不會 PS ，不會 AI ，不會 Sketch 怎麼辦呢，學吧。你平日喜歡結交不同領域的朋友，正好幾周前在一個活動上你認識一位朋友做設計的。她花一個下午的時間教你基本的 Sketch 的使用，並對你的 UI 設計給出了一些意見。你請她吃了頓晚飯表示感謝，然後立即回家根據她的一些建議重新調整了 UI ，這次你在 PS 里把 UI 畫了出來，Icons 和 Logo 也順道一起做了。

接下來的一周，你學習 HTML，CSS，以及 Javascript，並漂亮地把前端搞定。

## 發布 App
在朋友圈發了個狀態，找人幫你做 Beta 測試。他們都首先問你是什麼 App，一開始你簡單回答一個天氣的 App。但你發現，這不能提起他們的興趣。你覺得你需要用語言，用故事包裝一下。不光是作為別人「是什麼 App」提問的回答，也是成為 Full stack Engineer 道路上的一個重要技能。

你去看了所有你喜歡的產品的主頁，從他們的文案上獲得一些靈感啟發；你讀了經典的 On Writing Well ，發現好的文案，好的設計，其實和好的代碼很相似，都是重在交流，如何讓他人毫不費勁地明白你要表達的內容。你的故事要吸引人，你的產品介紹要在1分鐘內解釋清楚，並確保你的父母可以毫無壓力聽明白。

一切就緒，產品上線了。反響不錯，用戶持續增加。很多用戶希望有移動版本，於是你立即投入到iOS 版本的開發上。

## iOS 版及後台優化
你花一周不到時間學習了基本的語法和工具使用便投入到 App 的開發中。你知道 Learn by Doing 是最好也是最快的。由於之前學習了設計的基礎，UI ，Icons 很快搞定，不久 iOS 版本便發布了。iOS 的發布帶來了更多的用戶增長，後台伺服器的壓力頗大，你知道是時候優化後台了。

你在 AWS 上多開了 2 台伺服器，並寫了一個 Script 來自動化部署過程。
你改用 uWSGi 協議，用 uwsgi 作為 Application Server。
你使用 Nginx 來做並發，負載均衡 ...
......
......

## 成立公司
用戶持續增長，每天你都會收到十幾二十封用戶的郵件。你很感激這些願意花時間給你寫郵件的用戶，你相信他們是你最重要的用戶，是潛在的付費用戶。如果你把他們像上帝一樣對待，他們同樣也會把你看作是上帝。所以除了睡覺時間的發來的郵件，每一封郵件，你都會在2小時內給予回復。

果然這樣的付出是收穫巨大的，他們不僅驚訝且非常感謝你的快速回復，他們會在app store里給你的評價，他們在社交網站上分享你的app，他們甚至會主動提出捐款給你。

你從快速的用戶增長中嗅到了商機，你開始思考如何賺錢。廣告你是堅決不能允許的，你認為再精確的廣告也會影響用戶體驗。你設計了 2 個不同的付費方案，你打算用 A/B 測試看哪個方案更好。你分別給 200 個用戶發去邀請嘗試付費的郵件，郵件內容你精心打磨過，並在最後寫上：CEO Founder. 通過分析 2 種方案的用戶行為，你決定將使用第一種方案。

接下來，你相信差不多是時候成立個公司了。為了省時間，你花 2000 塊錢找了個園區掛靠並幫你註冊公司。公司的名字讓你頭疼了很久，你不想只是簡單的用這個 App 的名字作為公司名字，你知道公司將來還會做出其他優秀的產品。你希望這個名字簡單易記，同時其含義也是你公司文化的象徵。

公司註冊下來了，但銀行那邊得自己跑。你聯繫了一些媒體編輯，邀請他們來試用你的產品；你重新設計了產品主頁，並開始寫產品的 Blog ；你在各大社交網路都給 App 註冊了賬號，即做社區客服也為宣傳... 這些事大大壓縮你寫代碼的時間。以往你都是以代碼量作為衡量自己當天工作效率的指標，所以這些天你總感覺沒做啥工作。

這樣的發展早已超過你的預期，這個 App 從一個 Side Project 幾乎變成了你生活的全部。你跟你女朋友半個月才出去約會一次，她抱怨不斷；你1個月沒跟朋友出去玩耍喝酒了；你 2 個月都沒鍛煉過身體... 你意識到, YOU CAN NOT DO THIS ALONE，你需要幫手，你需要找人一起把這個做下去。

但你不是要成為 Full Stack Engineer 么？你現在是了么？

## Full Stack Engineer
設計，後台開發，前端開發，移動開發，運營維護，PS，文案... 好像都會了，這算 Full Stack Engineer 了么？

不，這只是踏上成為 Full Stack Engineer 的第一步。你知道目前只是每個 stack 都懂一點，離senior 或者 expert 還差得遠，而要每個 stack 都做到極致，需要大量的時間和精力。精力有限，產品開發緊迫，力不從心啊，這條道路也太孤獨，因為你不需要與任何人進行協作。難道要把一些stack的任務交給別人做么？這樣算是放棄成為 Full Stack Engineer 么？

不！這不是。
什麼是 Engineer？「Engineers are versatile minds who create links between science, technology, and society」。
Engineer 的本質工作是設計，開發出應用於大眾的產品。

一個真正的 Full Stack Engineer ，他從生活中發現問題，洞察需求，他設計解決方案，並開發出初始版本的產品。為了達到目標，他願意去學習任何領域的技能和知識。同時他不追求一個人完成所有工作，如果有人可以比他在某方面做得更出色，便會十分熱情的邀請他們加入。

最終他的職位也許不再是 Engineer ，他不再設計 UI ，不再寫代碼 ... 他的工作不再是 design and building an app or product，因為他有更大更重要的任務要做 - design and building a team or a company which builds great products.

而這時，社會給了他們另一個稱呼 - 創業者。儘管眾人已忘記他們 Engineer 的身份，但在他們骨子裡，內心深處，自己始終都是一個 Engineer 。當他們需要從頭再來時，他們毫不猶豫從設計開發產品做起。Nikola Tesla，Ferdinand Porsche，Henry Ford，Jack Dorsey，Mark zuckerberg，Elon Musk ... 細數那些改變了或正改變世界的創業者，他們大多數是 Engineer 背景，熱衷於設計創造。他們學習技能和知識，不是為了成為某個領域的專家；而是因為那些是完成自己目標所需要的。

以上，為我認可的 Full Stack Engineer

---
Peng

Update：
我又合夥創業了。招php基礎的開發者，入門基礎到中級的都收，有意私信。坐標上海，汽車後市場的現代化連鎖化互聯網化改造。
http://www.zhuanchedao.com

如果你目前寫的少基礎還比較差，只要邏輯思維清晰，好學，問題不大，我會帶你的。

另外說一下，開發者的概念。我們要的是開發者而不是程序員，我從入行2000年到轉管理崗07年，之間的工作一直是開發者，尤其朗訊貝爾實驗室，我們根本不管你會什麼語言，我們默認你會所有的語言。就像我曾經接手一個perl的數據轉換腳本的工作，遷移愛立信設備的用戶數據到我們伺服器上。就一周時間，我在班車上邊啃駱駝書上班了邊寫，後面我就開始喜歡上寫perl了。
我一直覺得，代碼專家負責純語言的底層事情，手術刀是用來做業務邏輯的，語言根本不是問題。
Update：
這個回答竟然收到的贊同比我其他所有回答都高，看來我還是轉型灌技術雞湯好了。

補充下，首先我覺得好的開發者，即使不是全棧，也要融會貫通多種技術。我從來不認為一個只專精一種技術的人有可能成為好的開發者，即使是 C，即使是彙編。（當然其實反過來看，那些大神們哪個不會搞點其他的？比如幾個做伺服器端開發的大神居然不懂伺服器管理？）

然後從廣度和深度的組合看，我認為好的開發者大概有兩種類型：
1. 手術刀
2. 代碼專家。
（來自《人月神話》）

手術刀是業務驅動的，最需要全棧的人；他們的核心價值在於：懂業務，技術全面，都能拿的起來，而且能選擇最合適的技術。
代碼專家是技術驅動的，即使不夠全棧也可以用，但是技能樹點的越多當然有好處。

而我提的創業逼出來的全棧，是因為，對於創業團隊而言，手術刀更加重要，代碼專家要依靠各種開源組織的貢獻，或者臨時聘請。

還有幾位講，創業的最大需求技能是整合資源的能力，找合適的人做事的能力。這個我認同，我只是說我自己，我承認我沒能力忽悠一堆技術大牛策劃大牛和我一起沒工資的創業。我也忽悠不到前期種子投資的錢。
所以我說的，是說對於我，種子期，天使期，最重要的都是我自己作為手術刀，而不是資源整合者。

------------------------------------------

全棧工程師不是為了工作本身，是為了方便實現自己的夢。
作為一個標準的全棧工程師來答下，全棧工程師不是培養出來的，是逼出來的~
不是公司逼的，是自己逼自己逼出來的~

因為我要創業，我經濟壓力又大沒法辭職，我沒法忽悠其他人一起免費幹活......而且作為一個寫了13年程序的老程序員（貌似知乎上比我老的程序不會很多了。。。。），本來工作語言就已經用過 Delphi, C++，Java，Perl，PHP，Lua，ObjectiveC，NodeJS，Tcl。這些都是工作中用的，尤其是創業那些年，遇到什麼問題，我就要自己去探路，探出路來需要招聘對應的人再招聘～結果順便把各種語言都學了一圈～

之前創業三年，一開始就我一個技術，所以運維幾十台Linux 伺服器我也順便管了（我之前工作平時就工作在 Solaris 下面，差距不大），我老婆是前端工程師，所以 HTML，CSS，JS 我也一起學了。
所以多學一些語言對我來說真的不是件事情......

做過幾年遊戲製作人（做製作人我也同時每天寫代碼....），策劃，UI 都還有心得。

而且我這十三年怎麼過的呢？別人朝九晚五，我每天工作到半夜2點，周末也很少休息。

誰能做到這樣努力的工作（不是為了「資本家」，而是為了自己為自己工作），並且不是一直專註於一個崗位，我相信都能成為全棧工程師。

回到起點，全棧工程師不是為了工作本身，是為了方便實現自己的夢。

沒錯，如一些答主所說，你各方面都半吊子，我承認。
我之前有一段工作是寫 C++和 Lua。Lua 部分還好，C++要遍歷個 std::map 我到現在記不住，每次現搜索。作為一個 C++程序員我不夠好，只能算是入門，或者說我一直是重視實現功能而非鑽技術細節的人。我不關心技術上多牛，我關心功能的實現。
但我的價值根本不在於是一個 C++程序員，而是我可以從前端到後端到運維提供一攬子方案，視野廣闊，任何點都可以選擇最合適的技術，比如說最終選擇 Lua 實現邏輯。
如果是創業，我可以自己一個人完成這個純應用層面難度的開發的全部工作（當然，我的意思不是我一個人全做掉）。

如果不是創業，我的價值可能也就是個2w 多工資的架構師或者技術經理，這個價格遠遠對不起我這13年的付出。
一個真正的全棧工程師，目標只有一個：創業。

高中的時候喜歡踢球，班上有一個特別厲害的前鋒，用我們對手的話就是：「擋也擋不住，跑也跑不過，絆都絆不倒」。
嗯，我認為的一個「全棧工程師」，不是僅僅能從彙編寫到JavaScript，從PHP寫到Objective-C。更是從代碼到PhotoShop，從產品設計到地推樣樣行，樣樣懂。
從小了說，給他安排個你自己都沒想太明白的任務，他給你一個驚喜。
從大了說，就是既能當CTO，又能當COO，沒有各種CXO，自己也能當CEO。

==============分割線==============
說一個我一個朋友@程一仕的故事吧，我是在大三認識他的。當時我是學校論壇的系統管理員，正在招人接替我畢業後在學校的工作。招了好久沒有入得了我法眼的，這時我師傅說找到一個不錯的。
說實話，第一次見面我對他沒啥好印象，因為這貨抽煙，完全不像是一個搞技術的。後來一起通宵修理伺服器，研究技術，慢慢發現這貨是個挺有意思的人。
以後的日子裡我帶著他一起寫Python，寫C，寫JS。。。我發現他就是那種能不斷給我驚喜的工程師。。。
我們工作室的傳統是，每年暑假大家都在學校做封閉開發，當時我找了個去IBM實習的機會，想讓他替我留校。最後一聊，這貨沒空，暑假要騎自行車去西藏。。。我才發現他還是個文藝青年（當時還不是那麼貶義）
後來，他到了大三，去的支付寶實習，做運維開發。
再後來跟我一樣去了百度，不到三年時間，就升到了T6。。。
有一天無意發現這貨豆瓣竟然有上萬的粉絲，一問才知道，有一天他閑得無聊，寫了篇罵豆瓣的產品的帖子，由於字字鞭辟入裡，連豆瓣的產品同學都直呼罵得好（抖m的既視感），不斷邀請他來豆瓣做產品，直到他亮出T6的身份，對方才作罷。
此人還對人文歷史政治總有很多見解。每每覺得無聊，第一個想到拉他出來吃吃飯，每次都有新收穫。
幾個月前，他跟我說他前幾天被一伙人拉著去融資了，那伙人是想搞雲存儲的，發現他對分散式存儲很有研究，就生生拉上他去壯大陣容。。。
我就問，他們怎麼知道你對這個有研究呢？這貨拿起手中的加冰可樂，33.3°仰望天花板：「因為MooseFS有部分代碼是我寫的」。
後來才知道，這貨已經是百度分散式存儲緩存Topic的負責人了。。。。
就在我為他要在技術的道路上超越我而惶惶不可終日的時候，有一天，他問我有沒有興趣回成都。。。
原來，這段時間他拉著幾個學弟搞了個無節操（約XX）的叫「誰有空」的APP（嘖嘖，這名字。。），拿了幾百萬的融資，開始出任CEO，走向人生巔峰了。。。
他也教會我一件事，遇到比自己厲害的學弟，不要嫉妒，不要嘗試去壓制，因為「有些鳥註定是不會被關在籠子里的，它們的每一片羽毛都閃耀著自由的光輝」。可能有一天你就要去他公司打工呢。

所以，過了這麼久，我最喜歡的一個身份還是
曾經這個全棧工程師的「師傅」。

一年之後，終於可以真正的給這個問題一個答案。現有的高票的答案沒有涉及到怎麼成為全棧工程師。

實戰篇
《GitHub - phodal/growth-in-action: 全棧增長工程師實戰》

你將會看到：

如何去開發一個Web應用（博客）
如何編寫單元測試、功能測試、自動化UI測試
搭建並使用持續集成
添加SEO支持——Sitemap、站長工具和Google Analytics
使用API，製作AutoComplete
開發相應的APP及其API——查看文章、用戶登錄、發表文章
製作單頁面應用
自動化部署

目錄：

Growth In Action Django
- 準備工作和工具
深入淺出Django
- Django簡介
  - Django應用架構
- Django hello,world
  - 安裝Django
  - 創建項目
  - Django後台
  - 第一次提交
Django創建博客應用
- Tasking
- 創建BlogpostAPP
  - 生成APP
  - 創建Model
  - 配置URL
- 創建View
  - 創建博客列表頁
  - 創建博客詳情頁
- 測試
  - 測試首頁
  - 測試詳情頁
功能測試與持續集成
- 編寫自動化測試
  - Selenium與第一個UI測試
- 搭建持續集成
  - Jenkins創建任務
  - 創建shell
更多功能
- 靜態頁面
  - 安裝 flatpages
  - 創建模板
- 評論功能
- Sitemap
  - 站點地圖介紹
  - 創建首頁的Sitemap
  - 創建靜態頁面的Sitemap
  - 創建博客的Sitemap
  - 提交到搜索引擎
前端框架
- 響應式設計
  - 引入前端框架
- 頁面美化
  - 添加導航
  - 添加標語
  - 優化列表
  - 添加footer
API
- 博客列表
  - Django REST Framework
  - 創建博客列表API
  - 測試 API
- 自動完成
  - 搜索API
  - 頁面實現
- 跨域支持
  - 添加跨域支持
移動應用
- hello,world
  - 構建應用
- 博客列表頁
  - 列表頁
  - 詳情頁
- Profile
  - Json Web Tokens
  - Profile
- 創建博客
- TODO
Mobile Web
- 移動設備處理
- MVVM
- UX
部署
- 配置管理
- Fabric

理論篇

獻上我寫的電子書《GitHub - phodal/growth-ebook: Growth: 全棧增長工程師指南。Growth: Learning Full Stack》

Growth: 全棧增長工程師指南
- 全棧工程師是未來
  - 技術的革新史
  - 軟體開發的核心難題：溝通
  - 大公司的專家與小公司的全棧
  - 全棧工程師的未來：無棧
基礎知識篇
- 工具只是輔助
  - WebStorm還是Sublime?
  - 語言也是一種工具
- 提高效率的工具
  - 快速啟動軟體
  - IDE
  - DEBUG工具
  - 終端或命令提示符
  - 包管理
- 環境搭建
  - OS X
  - Windows
  - GNU/Linux
- 學好一門語言的藝術
  - 一次語言學習體驗
  - 輸出是最好的輸入
  - 如何應用一門新的技術
- Web編程基礎
  - 從瀏覽器到伺服器
  - 從HTML到頁面顯示
- HTML
  - hello,world
  - 中文？
  - 其他html標記
  - 小結
- CSS
  - 簡介
  - 樣式與目標
  - 選擇器
  - 更有趣的CSS
- JavaScript
  - hello,world
  - JavaScriptFul
  - 面向對象
  - 其他
前端與後台
- 後台語言選擇
  - JavaScript
  - Python
  - Java
  - PHP
  - 其他
- MVC
  - Model
  - View
  - Controller
  - 更多
- 後台即服務
  - API演進史
  - 後台即服務
- 數據持久化
  - 文件存儲
  - 資料庫
  - 搜索引擎
- 前端框架選擇
  - Angular
  - React
  - Vue
  - jQuery系
- 前台與後台交互
  - Ajax
  - JSON
  - WebSocket
編碼
- 編碼過程
- Web應用的構建系統
  - Web應用的構建過程
  - Web應用的構建實戰
- Git與版本控制
  - 版本控制
  - Git
- Tasking
  - 如何Tasking一本書
  - Tasking開發任務
- 寫代碼只是在碼字
- 內置索引與外置引擎
  - 門戶網站
  - 內置索引與外置引擎
- 如何編寫測試
  - 測試金字塔
  - 如何測試
- 測試替身
  - Stub
  - Mock
- 測試驅動開發
  - 紅-綠-重構
  - 測試先行
- 可讀的代碼
  - 命名
  - 函數長度
  - 其他
- 代碼重構
  - 重命名
  - 提取變數
  - 提煉函數
- Intellij Idea重構
  - 提煉函數
  - 內聯函數
  - 查詢取代臨時變數
- 重構到設計模式
  - 過度設計與設計模式
上線
- 隔離與運行環境
  - 隔離硬體：虛擬機
  - 隔離操作系統：容器虛擬化
  - 隔離底層：Servlet容器
  - 隔離依賴版本：虛擬環境
  - 隔離運行環境：語言虛擬機
  - 隔離語言：DSL
- LNMP架構
  - GNU/Linux
  - HTTP伺服器
- Web緩存
  - 資料庫端緩存
  - 應用層緩存
  - 前端緩存
  - 客戶端緩存
  - HTML5離線緩存
- 可配置
  - 環境配置
  - 運行機制
- 功能開關
  - Feature Toggle
- 自動化部署
數據分析
- 數據分析
  - 數據分析的過程
  - Hadoop分析數據
- 用戶數據分析：Google Analytics
  - 受眾群體
  - 流量獲取
  - 移動應用
- 網站監測
- 應用程序性能分析
  - 關於Apdex
  - 博客性能分析
- SEO
  - 爬蟲與索引
  - 什麼樣的網站需要SEO？
  - SEO基礎知識
  - 內容
- 性能優化
- UX
  - 什麼是UX
- UX入門
  - 什麼是簡單？
  - 進階
  - 用戶體驗要素
- 認知設計
  - 流
持續交付
- 持續集成
  - 前提條件
  - 瀑布流式開發
  - 小步前進
- 持續交付
  - 配置管理
  - 持續集成
  - 測試
  - 構建與部署
  - 自動化
- 持續學習
  - 持續閱讀
  - 持續編程
  - 持續寫作
遺留系統與修改代碼
- 遺留代碼
  - 什麼是遺留代碼
  - 遺留代碼的來源
  - 遺留代碼的問題
- 如何修改遺留代碼
  - 守: 找到測試點
  - 破: 打破依賴
  - 離: 修改並重構
- 網站重構
  - 速度優化
  - 功能加強
  - 模塊重構
回顧與架構設計

自我總結
- 吾日三省吾身
Retro
- 四個維度
架構模式
- 預設計式架構
- 演進式架構：擁抱變化
浮現式設計
- 意圖導向
- 重構
- 模式與演進
每個人都是架構師
- 如何構建一個博客系統
- 相關閱讀資料
架構解耦

從MVC與微服務
CQRS
CQRS結合微服務

Full Stack Developer 在國內不被接受的一個主要原因是公司缺乏穩定的 T 線（技術職位晉陞路線）。

太多有才華的人寫了幾年代碼最後都去做了管理。而今天的網路相關技術，聰明又能持續學習的人，在三年之內可以在一個領域做到很高的水準。那麼如果你做五年，十年甚至十五年呢？
我以為你成為 Full Stack Developer 是很自然的選擇，而且可以跟隨最頂尖的技術。這種人並不罕見，我認識的人中 @徐樂樂就是個例子。

相信 Full Stack Developer 的核心並非否定團隊和協作，而是更多的體現在架構設計，快速原型和 TroubleShooting 方面。

隨著今天的分層越來越清晰，平台和語言越來越有特點，更加全面的技術人員可以根據不同的語言搭建整個架構。
數據一致性要求高？那麼使用事務管理久經考驗的 Spring？還要考慮 scale ？那麼放在 Oracle 裡面做還是放在 Application Server 的 Transaction 管理裡面做？簡單請求的高並發？那麼 Node.js 也許不錯。 Web App 快速原型，那麼 Rails 也許不錯。郵件模板和自動發送？ PHP 有現成的東西為什麼不用？前端數據和交互複雜？為什麼不試試 emberjs （ PS ：選前端框架對於架構人員來說簡直像女人逛銀座一樣令人興奮。甚至有人用幾乎所有的框架寫了同樣的 Web App 來供他們試用： TodoMVC）？想繞過蘋果的 App Store 的審查機制頻繁發布？可以考慮在 iOS Apps 裡面嵌入 HTML5 。

Full Stack Developer 在快速原型上也很有優勢，因為省去了大量的管理和溝通成本。而且，這並非就意味著一定在代碼質量或者測試上有縮水。
MVC 前後都可以用。一個寫過 test_helper.rb 的人做前端，一定會搜索 javascript TTD 。同樣，用過 javascipt lint 的人一定可以找到 stylecheck 。語言和平台會變化，聰明的方法和工具都是共通的。懂得基本的字體知識和排版審美難道和 CSS 不是天生一對？

TroubleShooting 方面 Full Stack Developer 同樣優勢巨大。
伺服器壓力太大未必需要通過後端解決，優化個 SQL 寫個 Hint 是選擇，而拿一部分數據和運算到前端也許是更加合理和低成本的選擇。一個系統運行多年，最後遺留的問題很可能需要對業務和技術都有深入理解的人才能解決。

從以上內容可以看出， Full Stack Developer 並非雜而全 - Facebook 也不會雇庸手。他要求的是一種更加全面的深入。一方面，他是技術人員不斷學習的結果。另一方面，他也是對自己事業的一種責任：

技術人員的價值不是指派做了一半的 issue 給隊友，而是更快更好的搞定事情。

現有的答案已經說明了，以一個正常人的精力和學習速度來說，想在 full stack 的每一個層面都達到頂級的精通顯然是很困難的事情。但是做不到這一點就算不上 full stack developer (FSD) 了嗎？其實我希望大家留意題主引用的那段英文的最後一句：a genuine interest in all software technology. （對所有的軟體技術抱有一種真摯的興趣）。

我覺得對於 FSD ，尤其是對於想成為 FSD 的人來說，這個態度才是最重要的事情。即使都是 FSD，每一個人各自的技能加點也肯定會不一樣，有人在前端更擅長一些，有人在伺服器層面更有經驗... 但其實沒有什麼硬性的門檻，需要的是解決任何問題的能力和意願。你要做到的就是不固步自封在一個領域。遇到問題，就去研究，不因為問題不在你的 comfort zone 就放棄或者推給別人。即使一開始的解決方案很笨拙也無所謂，just learn whatever it takes to make it work. 比如說我要做一個網站，我有一些東西沒碰過，但我有足夠的興趣和動力去搞個八九不離十。（這裡自學能力很重要，有好的 mentor 也會幫助很大）當你經歷過一次這個過程以後，你就會有信心去弄明白更複雜的東西，在之前的基礎上進一步去消化、改進、學更多的東西。

另外，我個人覺得這個過程應該是由實際問題驅動的，而不是漫無目的看到什麼東西流行了或者覺得很NB就去學。@庄生的答案里提到絕大部分的網站都活不到或者永遠也達不到10k用戶在線的水平，那種情況下去看 high scalability 的東西有什麼意義？學的東西用來解決或是改進實際遇到的問題，這樣你的整個知識體系覆蓋面和側重點會比較合理。打個比方就是你的技能點有限，所以加點方案得有一個主題，到處亂點的話就廢了。

名詞定義：

FSD = full stack developer
領域專家 = 和FSD相對，表示精通且只精通單一領域的大牛（暫時想不出更好的名字了）
互聯網公司 = 通過互聯網產品本身的運行來產生現金流。例如百度，Dropbox
外包公司 = 根據客戶需求來訂製產品然後整體賣給客戶。項目本身的現金流和公司沒有關係。例如東軟。

首先，反對 @馬宏菩以及其他類似的潑冷水答案，FSD並不需要在每個領域都學到精通的程度，領域專家和FSD是壓根兒就是拿來做不同的事情的。對於互聯網公司來說，一個項目剛開始的時候叫幾個FSD就可以非常快地寫個poc甚至直接發布，流量上去以後再考慮安全或性能隱患，慢慢交予領域專家在後期調整優化。考慮到大部分項目的生命周期和用戶數量，上面這句話的後半部分根本不會發生。引用一句話：the bigger problem isn』t scaling, it』s getting to the point where you have to scale。

不知道馬同學所謂的高水平公司都有哪些，可能都是外包公司吧。因為對於互聯網公司來說，他提到的問題基本都屬於premature optimisation。比如：

建一個VPS還非得精通到怎麼搞機房和數據中心？以現在的硬體條件稍微高配一點的VPS跑一個在線人數10K的網站+DB問題也不大。國內有多少網站在線人數超過10K了？對於大部分的網站要CCNP/CCNA幹嘛？

ORM性能差就要用native sql? 重寫了一遍以後每個request平均能省下多少ms? 你的用戶在乎這點時間嗎？值得那麼多重寫和測試的￥￥么？現在確實native sql確實又開始火了，但本質原因還是方便，根本不是性能問題。

還有很多，不一一反駁了。

下面回到樓主的問題，我認為成為FSD的想法非常好。因為成為FSD意味著具備了單人創業的能力。而且隨著框架越來越強，互聯網創業團隊(包括intraprenuer)越來越小，FSD的前景其實遠遠超過領域專家。（這句話是個人觀點，5年以後再回來看）

那麼如何成為FSD呢？很簡單也很難：自己去做一個網站，並維護它。

折騰之魂永不停息的人，最後就容易變成 full stack.

另外，在學校里寫東西，找人巨難，這造就了一批 full stack 小夥伴. 有一次搞一個 html5 的比賽，到後來快要deadline時，前端明顯要搞不完了，作為一個野生前端，怒刷了一天 js 後開始填坑.
有時候因為找不著人，還可以臨時變身美攻（當然你也可以叫設計濕），然後客串一下 ios 客戶端開發，設計個資料庫…… 最後小夥伴們所有東西都搞完，你再從頭到尾把他們搞的東西擦一遍屁股，然後需要宣傳/比賽的話，海報/視頻/演講/slides/文檔都是你的事，最後就成了 full stack 了.

你看，full stack 都是苦逼的人（你看這還只是學校里的 full stack，要是工作上成了 full stack 那就不定啥樣了）. 想想好像沒必要匿…，就不匿了吧.

看到已經有很多小夥伴分享了成為全棧工程師的答案，小編特在此貢獻一篇全棧架構師的內容，以供大夥擴展：
老曹眼中的全棧架構師-博客-雲棲社區-阿里雲

看一下工程師和架構師的區別，簡單地，工程師關注的是功能和代碼性能，而架構師關注的是業務和系統的性能等非功能性約束。全棧不是全能，只要覆蓋了所使用的技術棧就是全棧，例如LNMP，Linux＋Nginx＋Mysql＋PHP。全棧架構師關注的是業務所採納的全部技術棧，以及技術棧所涉及的系統性能、安全，高可用等諸多因素。

全棧（full stack developer）好像起源於facebook中對工程師的一種稱謂，全棧架構師估計是老曹的杜撰。全棧的出現大概有4個方面：系統的性能瓶頸定位，團隊間的溝通障礙，業務的救火滅火，以及團隊的資源緊張。尤其的小型創業團隊，戰力的有限會導致全棧的產生。

和習武一樣，我想試圖探討一下全棧的套路，很多能力不是通過當頭棒喝產生的。郭大俠需要降龍十八掌，令狐沖以無招勝有招也需要獨孤九劍。我覺得全棧的技術棧可以主要分為3個切面：技能，性能和效率。下面逐一簡要闡述：

工其事必利其器，環境在效率中是第一位的。具體可看《老曹眼中的開發學習環境》，不在贅述。

全棧應該掌握4種編程語言：Java，Objc/C/C++, Python，JavaScript。語言沒有優劣，不同語言有各自的勝場。

每個人都不是一個人在戰鬥，團隊敏捷是整體效率的關鍵。可以使用Trello或worktile之類的工具做協同，以Jinkens等工具支持CI或者CD，了解Scrum中什麼是backlog，什麼是UserStory，如何控制sprint。同時，敏捷不是以質量的喪失為代價的。

再進一步，就是devops了，可以參考《DevOps 全棧必備雙刃劍》

從下向上看一下全棧的所需技能，第一個就是操作系統，可參考《老曹眼中的Linux基礎》。

數據是系統的核心，必須要了解文件系統，對象存儲和關係型資料庫，只有NoSQL至少要關注redis和mongodb，更多可以可參考《NoSQL與大數據》。

網路是一個覆蓋更廣的領域，至少要了解七層協議模型，DNS，TCP/IP，HTTP，以及網路類型對網路編程的影響，會上只有簡單舉例，以後擇機仔細探討一下。

框架和庫使用與所採用的語言是息息相關的，不同語言又有著不同的框架與庫，簡直是浩如煙海，對框架與庫的選擇主要從面相領域和面向場景入手，有比較才能有選擇。

安全是個與非門，沒事一切都好，有事就是大事。基本上，可以從傳輸，網路，代碼和數據四個層面掌握有關安全的基礎知識。

至於架構方法，現在最熱的莫過於微服務架構了。服務的劃分與業務密切相關，服務獨立後要考慮服務的發現和服務間的通信，最後是服務治理，可以從這四個方面專研相關的技術。

雲服務的出現使得小團隊可以做大事情，關於混合雲的解釋可參考老曹的舊文《理解一下混合雲》。

從趨勢來看，大數據必將成為工程師團隊的重要戰力，包括專業知識，數學演算法，計算環境三個方面。就計算環境而言，涵蓋了Hadoop的生態圈，如果只有一個必備技能，老曹覺得就應該是Spark了，可以參考《架構大數據應用》舊文。

個人以為，性能在諸多非功能性約束中第一重要，直接影響用戶體驗。首先要從業務和代碼層面保障性能，而單元測試是一個必要條件。正像PingCAP CTO 黃東旭所說的，「talk is cheap， show me the tests."

接下來是運行時調優，或者認為是單機性能。從載入和依賴開始，到 JVM調優，再到Linux 內核參數調優。 對於 JVM 調優，給朋友做個廣告，中生代技術群中的江南白衣（公眾號：春天的旁邊）有一篇乾貨文章，特別向大家推薦。

資料庫是整個系統中的慢性子，關注系統的性能，日誌分析比不可少，LEK可能是第一首選。數據訪問必須是高可用的，數據連接池的選擇和使用都是考驗功夫的。

緩存是減少負載，提高系統性的必備技術。可以從客戶端，網路側，服務端三個環節對緩存進行分類，具體可以參考《老曹眼中的緩存技術》。

負載均衡同樣是一種以空間換時間的技術，具體可參考《老曹眼中的負載均衡》。

傳輸的性能可以依靠消息隊列來提升，ZeroMQ可以用在系統內，而ActiveMQ是Java 程序猿的福音，對於高並發和高容錯而言，RabbitMQ可能是不錯的選擇，Kafka是大量數據的傳輸必備。

啰哩啰嗦，只是想探討一下全棧的套路，也許這本身就是一個偽命題。
延展閱讀：
為什麼未來是全棧工程師的世界？-博客-雲棲社區-阿里雲

技術在過去的幾十年里進步很快，也將在未來的幾十年里發展得更快。今天技術的門檻下降得越來越快，原本需要一個團隊做出來的Web應用，現在只需要一兩個人就可以了。

同時，由於公司組織結構的變遷，也決定了賦予每個人的職責將會越來越多。儘管我們看到工廠化生產帶來的優勢，但是我們也看到了精益思想帶來的變革。正是這種變革讓越來越多的專家走向全棧，讓組織內部有更好的交流。

你還將看到專家和全棧的兩種不同的學習模式，以及全棧工程師的未來。

技術的革新史

從開始的CGI到MVC模式，再到前後端分離的架構模式，都在不斷地降低技術的門檻。而這些門檻的降低，已經足以讓一兩個人來完成大部分的工作了。

CGI

二十年前的網站以靜態的形式出現，這樣的網站並不需要太多的人去維護、管理。接著，人們發明了CGI(通用網關介面，英語：Common Gateway Interface)來實現動態的網站。下圖是一個早期網站的架構圖：

　　當時這種網站的URL類似於： https://www.phodal.com/cgi-bin/getblog

(PS：這個鏈接是為了講解而存在的，並沒有真實存在。)

用戶訪問上面的網頁的時候就會訪問，cgi-bin的路徑下對應的getblog腳本。你可以用Shell返回這個網頁：

123 #!/bin/sh echo Content-type: text/plain echo hello,world

Blabla，各種代碼混亂地夾雜在一起。不得不說一句：這樣的代碼在2012年，我也看了有一些。簡單地來說，這個時代的代碼結構就是這樣的：

　　這簡直就是一場惡夢。不過，在今天好似那些PHP新手也是這樣寫代碼的。

好了，這時候我們就可以討論討論MVC模式了。

MVC架構

我有理由相信Martin Fowler的《企業應用架構模式》在當時一定非常受歡迎。代碼從上面的耦合狀態變成了：

　　相似大家也已經對這樣的架構很熟悉了，我們就不多解釋了。如果你還不是非常了解的話，可以看看這本書後面的部分。

後台服務化與前端一致化架構

在今天看來，我們可以看到如下圖所示的架構：

　　後台在不知不覺中已經被服務化了，即只提供API介面和服務。前端在這時已經盡量地和APP端在結合，使得他們可以保持一致。

軟體開發的核心難題：溝通

軟體開發在過去的幾十年里都是大公司的專利，小公司根本沒有足夠的能力去做這樣的事。在計算機發明後的幾十年里，開發軟體是大公司才能做得起的。一般的非技術公司無法定製自己的軟體系統，只能去購買現有的軟體。而隨著技術成本的下降，到了今天一般的小公司也可以僱傭一兩個人來做同樣的事。這樣的演進過程還真是有意思：

　　在這其中的每一個過程實質上都是為了解決溝通的問題。從瀑布到敏捷是為了解決組織內溝通的問題，從敏捷到精益不僅僅優化了組織內的溝通問題，還強化了與外部的關係。換句話說，精益結合了一部分的互聯網思維。

瀑布式

在最開始的時候，我們預先設計好我們的功能，然後編碼，在適當的時候發布我們的軟體：

　　然而這種開發方式很難應對市場的變化——當我們花費了幾年的時間開發出了一個軟體，而這個軟體是幾年前人們才需要的。同時，由於軟體開發本身的複雜度的限制，複製的系統在後期需要大量的系統集成工作。這樣的集成工作可能要花費上大量的時間——幾星期、幾個月。

　　當人們意識到這個問題的時候，開始改進工作流程。出現了敏捷軟體開發，這可以解釋為什麼產品經理會經常改需求。如果一個功能本身是沒必要出現的話，那麼為什麼要花功夫去開發。但是如果一個功能在設計的初期就沒有好好設計，那麼改需求也是必然的。

敏捷式

現有的互聯網公司的工作流程和敏捷軟體開發在很多部分上是相似的，都有迭代、分析等等的過程：

　　但是據我的所知：國內的多數互聯網公司是不寫測試的、沒有Code Review等等。當然，這也不是一篇關於如何實踐敏捷的文章。敏捷與瀑布式開發在很大的區別就是：溝通問題。傳統的軟體開發在調研完畢後就是分析、開發等等。而敏捷開發則會強調這個過程中的溝通問題：

　　在整個過程中都不斷地強調溝通問題，然而這時還存在一個問題：組織結構本身的問題。這樣的組織結構，如下圖所示：

　　如果市場部門/產品經理沒有與研發團隊坐一起來分析問題，那麼問題就多了。當一個需求在實現的過程中遇到問題，到底是哪個部門的問題？

同樣的如果我們的研發部門是這樣子的結構：

　　那麼在研發、上線的過程中仍然會遇到各種的溝通問題。

現在，讓我們回過頭來看看大公司的專家與小公司的全棧。

大公司的專家與小公司的全棧

如果你經常看一些關於全棧和專家的技術文章的時候，你就會發現不同的人在強調不同的方向。大公司的文章喜歡強調成為某個領域的專家，小公司喜歡小而美的團隊——全棧工程師。

如我們所見的：大公司和小公司都在解決不同類型的問題。大公司要解決性能問題，小公司都活下去需要依賴於近乎全能的人。並且，大公司和小公司都在加班。如果從這種意義上來說，我們可以發現其實大公司是在剝削勞動力。

專家

我們所見到的那些關於技術人員應該成為專家的文章，多數是已經成為某個技術領域裡的專家寫的文章。並且我們可以發現很有意思的一點是：他們都是管理者。管理者出於招聘的動機，因此更需要細分領域的專家來幫助他們解決問題。

全棧

相似的，我們所看到的那些關於成為全棧工程師的文章，多數是初創公司的CTO寫的。而這些初創公司的CTO也多數是全棧工程師，他們需要招聘全棧工程師來幫助他們解決問題。

兩種不同的學習模型

而不知你是否也注意到一點：專家們也在強調「一專多長」。因為單純依靠於一個領域的技術而存在的專家已經很少了，技術專家們不得不依據於公司的需求去開拓不同的領域。畢竟「公司是指全部資本由股東出資構成，以營利為目的而依法設立的一種企業組織形式；」，管理人們假設技術本身是相通的，既然你在技術領域裡有相當高的長板，那麼進入一個新的技術也不是一件難的事。

作為一個技術人員，我們是這個領域中的某個子領域專家。而作為這樣一個專家，我們要擴展向另外一個領域的學習也不是一件很難的事。借鑒於我們先前的學習經驗，我們可以很快的掌握這個新子域的知識。如我們所見，我們可以很快地補齊圖中的短板：

　　在近來的探索中發現有一點非常有意思：如果依賴於20/80法則的話，那麼成為專家和全棧的學習時間是相當的。在最開始的時候，我們要在我們的全棧工程和專家都在某個技術領域達到80分的水平。

那麼專家，還需要80%的時間去深入這個技術領域。而全棧工程師，則可以依賴於這80%的時候去開拓四個新的領域：

　　儘管理論上是如此，但是專家存在跨領域的學習障礙——套用現有模式。而全棧也存在學習障礙——如何成為專家，但是懂得如何學習新的領域。

解決問題的思路：不同的方式

有意思的是——成為專家還是成為全棧，取決於人的天性，這也是兩種不同的性格決定的。成為管理者還是技術人員看上去就像一種簡單的劃分，而在技術人員里成為專家還是全棧就是另外一種劃分。這取決於人們對於一個問題的思考方式：這件事情是藉由外部來解決，還是由內部解決。下面這張圖剛好可以表達我的想法：

　　而這種思維依據於不同的事情可能會發生一些差異，但是總體上來說是相似的。當遇到一個需要創輪子的問題時，我們就會看到兩種不同的方式。

對於全棧工程師來說，他們喜歡依賴於外部的思維，用於產生顛覆式思維。如Angular.js這樣的框架便是例子，前端結合後端開發語言Java的思維而產生。而專家則依賴於內部的條件，創造出不一樣的適應式創新。如之前流行的Backbone框架，適應當時的情況而產生。

全棧工程師的未來：無棧

全棧工程師本身不應該僅僅局限於前端和後台的開發，而可以嘗試去開拓更廣泛的領域——因為全棧本身是依賴於工程師本身的學習能力，正是這種優秀的學習能力可以讓他們可以接觸更廣泛的知識。

全棧的短板

如果你也嘗試過面試過全棧工程師，你會怎麼去面試他們呢？把你知道的所有的不同領域的問題都拿出來問一遍。是的，這就是那些招聘全棧工程師的公司會問你的問題。

人們以為全棧工程師什麼都會，這是一個明顯的誤區——然而要改變這個誤區很難。最後，導致的結果是大家覺得全棧工程師的水平也就那樣。換句來說，人們根本不知道什麼是全棧工程師。在平時的工作里，你的隊伍都知道你在不同領域有豐富的知識。而在那些不了解你的人的印象里，就是猜測你什麼都會。

因此，這就會變成一個罵名，也是一個在目前看來很難改變的問題。在這方面只能儘可能地去了解一些通用的問題，並不能去了解所有的問題。在一次被面試全棧工程師的過程中，有一個面試官準備了幾個不同語言（Javascript、Java、Python、Ruby)的問題來問我，我只想說Ciao——義大利語：你好！

除了這個問題——人們不了解什麼是全棧工程師。還有一個問題，就是剛才我們說的成為專家的老大難問題。

無棧

讓我毫不猶豫地選擇當全棧工程師有兩個原因：

這個世界充滿了未解的迷，但是我只想解開我感興趣的部分。
沒有探索，哪來的真愛？你都沒有探索過世界，你就說這是你最喜歡的領域。

當我第一次看到全棧工程師這個名字的時候，我發現我已然是一個全棧工程師。因為我的學習路線比較獨特：

中小學：編程語言 -&> 高中：操作系統、內核、遊戲編程 -&> 大學：硬體、Web開發 -&> 工作：後端 + 前端

而在當時我對SEO非常感興趣，我發現這分析和Marketing似乎做得還可以。然後便往Growth Hacking發展了：

而這就是全棧學習帶來的優勢，學過的東西多，學習能力就變強。學習能力往上提的同時，你就更容易進入一個新的領域。

程序員：如何成為一個全棧的工程師？-博客-雲棲社區-阿里雲

全棧工程師，英文 Full Stack developer，是指那些掌握多種技能，並能利用多種技能獨立完成產品的人。當然，現在「全棧工程師」很吃香，非常吃香！這是因為在移動互聯網時代，IT 系統變得愈加複雜，需要擁有全局思維的工程師來搞定各種「疑難雜症」。不僅要玩得轉前端，還要搞得定後端，總之各種技術都懂，所以其重要性可見一斑。

近日，移動開發精英俱樂部圍繞「如何成為一個全棧的工程師？」進行了討論，主持人是優才學院的創始人伍星老師，讓我們一起看看大神們的精彩言論吧！（本文系國內 ITOM 管理領軍企業 OneAPM 工程師整理）

程序員眼中的「全棧」

伍星-優才創始人：全棧，最早來自於 Facebook 的「我們只招全棧工程師」，從表面看是指技術棧，是完成一套產品所面要的全部技術和技能。谷歌在它的書中也提出，它們只招創意型人才，其實這是一致的、相通的！

饒培澤：全棧，在我看來是一種態度，無路遇到何種問題都能積極的去解決。全棧，也不是說會什麼，而是因為有好奇心與驅動力，所以什麼都想搞明白，學習起來自然能快速上手。

iOS小碼哥：全棧，也可以說「我是一塊磚，哪兒需要我，我就往哪兒填。」代表著快速學習的能力和超強的適應能力。

夢航：全棧，在一定程度上能更好的做出架構，減少維護成本。

卓競勁：我支持思想和知識層面的「全棧」，而非刻意技能上的全棧。

饒培澤：其實，能從前端寫到後端的人不少，但是能專職來做嗎？這麼說吧，很多公司的後端都能寫前端，但可不敢讓他們寫產品級別的代碼。如果後端人才如果能去了解前端的知識點，合理去進行整合互補，這樣是我們所鼓勵的。

葯交匯：全棧圍繞產品服務，重點是考慮問題的角度、廣度。個人理解也可以看成責任感的一種體現，前端、後端都可以也不代表全棧。只不過是圍繞著問題的解決方案，其根本還是本著對一件事情負責的態度，展開全方面的跟蹤。

伍星-優才創始人：從谷歌對創意型人才的描述可以看出，這更多體現在能夠主動地承擔工作和解決問題。比如谷歌講過一個例子，Adwords 是幾個非相關工程師主動解決了小問題帶來大收益的。

Facebook 的人才培養一開始是不分工的，「新兵營」之後才分工，並且輪崗很多，這中間暗含了：學習能力要相當強，我想學什麼，都能學什麼，需要我做什麼，都能勝任。

所以我們對全棧提出如下見解。首先要技術全面，作為全棧工程師，其技術當然要比較全面。從前端到後端、從運維到優化、從 PC 到移動都難不倒。但又有自己比較精通的一方面。也就是說，作為全棧工程師既要有「專深」，同樣也要有「廣博」，這樣才能在解決問題時不受局限，才能融會貫通。

第二就是思維和心態。全棧工程師以積極主動的姿態來面對和解決工作中的問題。以全局的觀點來看待自己所從事的項目，而不只是自己負責的一小部分。以做成產品、做成一件事的觀點來看待整個開發流程，而不僅僅是技術實現。因為只能這樣的心態和觀點，他才會積極主動地去學習其他技術，用其他技術解決問題

第三是上升能力，全棧工程師並不意味著全能，什麼都會。但是全棧工程師有良好的基礎技能。這個技能，既包括計算機科學的基礎，也包括英語基礎，有了這個基礎，加上積極的態度，開放的心胸，就能快速地學習所需要的技術，比如像 Swift 語言，那都不是事兒。並應用在所需要的開發工作中。

第四就是職業價值，像 Facebook 說，他們只喜歡全棧工程師，創業公司也會說，我們需要全棧工程師。無論是在大公司，還是創業公司，全棧工程師都將成為搶手人才！那是因為，全棧工程師不但技能全面，而且心態積極，學習能力強！

伍星-優才創始人：所以全棧不是一種技能，而是一種能力。學習能力，開放心態是優先的！

李睿君：其實後面有段時間覺得全棧需要一方面熟悉自己本身專業的領域，另一方面需要關注另一段的技術，這樣在需要另一端技術，或是溝通時都能有幫助

著建彬：對感興趣的東西不要當成「工作」來做，其實興趣才是最大的動力。我覺得全棧應該是由「興趣」驅動的。

伍星-優才創始人：即使是領域專家，他對別的也會有了解和研究的。優秀的技術人員，對所有的技術應該有一種天然的好奇心和折騰勁

葯交匯：我前端和後端都經歷過，其實，在前期人員不全的情況下，結合業務並外出調研梳理了產品線框圖、PRD、流程圖，到制定了設計規範，到協調資源，然後制定研發周期，最後到輸出...... 曾一度以為這就是全棧，但是後來思考，這些只不過是本著對事情負責的態度，才驅動做了很多研發之外的事。就算一個人的技術全棧精通也要服務於根本產品。

伍星-優才創始人：項目進度和管理，比全棧本身要難。因為技術還是死的，人是活的，而且多種多樣的。就像業務架構師，本身曾經技術應該不錯，即使學新技術，應該也是有特殊長處和見解的，不過不學不寫罷了。這種人是標準的技術 leader ，技術能力並不一定是以某特定語言的寫碼能力而界定。

一般而言，全棧工程師在產品和溝通這塊都有優勢，由於技術全面，他能和各方溝通的比較愉快。甚至和產品經理也溝通好。我也算是一個全棧，此前和各個產品經理溝通都很愉快。因為他不理解的地方，我會和他講清楚，分析清楚，為什麼這個不能做，為什麼那樣做不好，那樣做更好，有理有據，其實，產品經理也是講道理的，不像我們在網路上經常「吐槽」的那樣。如果再加上本身的技術聲望和良好溝通的方式，程序員和產品經理相處其實會很和諧的。

如果成為一個全棧工程師？程序員：如何成為一個全棧的工程師？-博客-雲棲社區-阿里雲

王威：我的理解是，不僅自己領域的精通，然後其他部分也應該快速學習。在我看來，如果想成為全棧的話，還得靠上項目了。在普通公司的話，一般每個人只關注自己的領域，對跨領域的項目一般不會碰，可以自己利用業餘時間來寫，比如原本做APP的，有空可以寫一下後端的東西，其實開始那一步比較困難。

張洋：全棧不只是技術，還需要心態、責任等方方面面。

江月：我覺得 facebook 要求全棧，並不是希望程序員技術全面但不精通。而是至少有一個領域精通，而且可以快速研究另外一個領域的技術點。

伍星-優才創始人：能成為全棧，意味著技術能達到一定高度，而高度，肯定是以長處見知的。我個人更傾向於認為，一專多能。

王威：成為全棧的話，還得靠上項目了。。。在普通公司的話，一般每個人只關注自己的領域，對跨領域的項目一般不會碰，自己私下來寫，比如原本做 APP 的，自己私下寫後端的東西，其實開始那一步比較困難。

葯交匯：關鍵是責任感的轉變，由「被動」到「主動」，才能實現自我超越。

拯救與逍遙：我個人看法，不是先有了「我要成為全棧」的目標，而是對技術的好奇和追求，以及積極應對當前業務發展的不斷挑戰，最終才能鍛鍊出了全棧。

薄建業：我覺得，最好的方法就是項目驅動；從另一方面也說明，說為全棧，在一定程度上，也是被逼出來的。

王威：我比較贊成項目驅動型。比如 APP 端的，例如做個類似於雲筆記的軟體，那麼後端數據該怎麼保存，介面該怎麼定，該用哪種語言來實現後端，在分析你想要的目標的時候就能找到該用哪種技術該學哪種技術。比如後端用 PhP 寫，這時候就會推動自己去學 PHP，比如自己是做安卓，那麼語言銜接上，有可能選擇 JAVA 做後端，這時候就學 J2EE 的東西，圍繞這個需求來實現，然後學資料庫......其實說到底還是得有」目標項目」來進行推動。

林曦：後端概念太泛了，不同業務需求和規模需要的技術支撐完全不同。

王威：比如做高並發，可以 NodeJs 、 Golang 、 Erlang ，或者乾脆用 Java、PHP 等等。其實做項目的第一步，後端寫出業務服務介面，在業務量上來之後考慮比如性能優化，比如負載均衡，或者再比如後端架構分層等等。

文彥峰：其實，接入也有很多要做的，一般要和終端一起做，路由、負載、流量控制、安全、監控、旁路、優化 TCP 協議棧、內核參數再到硬體的支持等等。做業務，比如網關、鑒權、微服務框架、服務治理、緩存、消息中間件；存儲，單機房如何保證數據不丟，多機房是單向同步，雙向同步，出了異常怎麼通過日誌恢復，數據的檢查，靜態檢查點的選擇。怎麼做分片，怎麼擴容不影響原來的分片？

王威：所以說到底還是得有這個項目需求，圍繞著需求來分析需要的技術，然後再研究技術了。感覺純按照興趣來學新的技術，作為對這一個技術有個優缺點簡要了解，在需要的時候能快速學習。我個人還是覺得，想成為一個「全棧」，就找一個想法並實現它。

周淵：比如，你覺得 NBA 好看，想要做一個 APP 能提醒比賽，那麼每天下班後，沒事寫幾個小時代碼，三個月後，你就會發現做成了。

林曦：我覺得做個「入門型」的全棧比較容易，真正能做到都有一定深入的了解很難，融會貫通更難。

拯救與逍遙：先自學基礎入門，進階的話，可以隨公司項目，初期不能直接參与，但是我們可以主動思考技術方案，然後參照其他同事最後落地的方案，對比總結。能力慢慢提升，真正上手的機會總會有的！

周淵：最重要就是，Just Do It ！

林曦：不過大公司相對有一個好處，就是能遇到「牛人」的概率也比較高，所以開發過程中，某一個部分遇到瓶頸的時候想要找人討論或者請教，找他們也是比較好找的。

周淵：高人點撥，確實重要，但是建立在你入門的基礎上。

拯救與逍遙：很多時候，我們不能做最想做的事情，而且要停下來推動一下，阻礙我們繼續前行的事情。但是，有些坑，有些歷練是必須的，別人說一萬遍，我們還是得自己歷練。而且很多技術選型，都是在真正落地之後，才暴露出問題。

王威：采坑是必然的！運氣好的話，采坑的代價低，運氣不好的話，采坑代價可能毀掉整個項目。不過有些坑，有可能是在技術選型的時候就會暗含的，這個時候確實不好找。

王威：我們業務在往圖數據遷移的時候也踩了很多坑，因為我們是社交軟體，所以很多需求是基於用戶關係的，比如喜歡、不喜歡、好友等等。。。最開始覺得 neo4j 挺方便的，導入數據的時候發現，免費版就是個坑爹的玩具。。。收費版貌似5千刀一個月還說多少，巨貴。。。

王威：創業有這個好處就是人少，一個人當多個人用，這個時候就有很多機會去摸新的東西，不過缺點就是沒人帶，自己摸石頭采坑。。。

王威：不過對於我來說收益大於采坑風險。。。所以還是得圍繞這個需求，一圈一圈的挖掘更好的解決方式，這個是一種學習的過程。尤其是在風險可控範圍內，絕對鼓勵大家嘗試新的東西。

到最後你的選擇很多時候依賴你團隊的水平，怎麼把這些人水平帶起來，你這些才能做細

最好的成長就是在業務中成長

林曦：架構也是活的，需要不斷生長，不斷修改。不過，前期埋的坑也只有後期加班吞了，沒有一勞永逸的架構！

董飛：我覺得重要的還是分享，別人幫你填了坑，你也可以幫別人填坑。而媒介就是博客，大家可以互幫互助。

王威：說到寫博客，我覺得可以把思維給規範化，把想法記錄下來的同時還能注意到以前沒注意到得細節，絕對是學習新姿勢最必要的補充。

伍星-優才創始人：曾經，我就主動地提出來幫公司承擔一些的運維方面的事情。然後就自己學習，請教，後來很自然地就成為全棧了。當然，全棧並不意味著上班學別的，我們上班時間把公司的事情做好，這才是成為全棧的前提。

伍星-優才創始人：還有一點，就是我們在寫代碼的過程中，要考慮怎麼優化，怎麼寫得更快更好，而不是像「搬磚」似的，簡單的重複。「搬磚」工作很快就會被淘汰掉，積累核心競爭力才是發展的根本。

王威：比如做APP，在寫從服務端拉取數據的時候，就可以考慮一下他們為什麼要提供這樣的數據結構？這樣的介面如何進行實現的？有這些疑問的時候，就會促進自己去看看去了解一下相關的知識，這樣才能不斷通向全棧之路。

當然，完成是一碼事兒，完成好是另一碼事兒。全棧的意義不是全都泛泛地去做，而是在做深自己的領域同時，也能借鑒其他的技術，至少在團隊開發時候溝通成本會減少很多。

趙建彬：其實，產品並不會關心你代碼怎麼寫，關鍵自己要寫出讓自己覺得滿意的、高質量的代碼。

薄建業：全站人才可以站在更高的視角，提供「一攬子」的解決方案，避免踩深坑！

文彥峰：熱衷於技術，成全棧是早晚的事兒，技術全面某方面又比較深入，自然能解決別人解決不了的問題，能做別人做不了的事情，團隊中的影響力，行業中的影響力，也自然就有了，形成正向循環，還是挺不錯的！

伍星-優才創始人：就像羅輯思維跨年公開課說的那樣，核心競爭力，就是你的不可替代性。我們不能單純地說「全棧」好，很多初學者會被誤導，是因為他們不了解什麼是全棧，怎麼才能成為全棧。就像武功也有練「走火入魔」的。

其實，加入一個快速成長的團隊創業。是成為全棧的最快捷途徑。這個團隊，也可能是大公司內部創業團隊。也可能是大家都把工作當作創業的團隊。而沒有好奇心，沒有折騰勁，沒有學習能力，沒有開放心態，是不可能成為全棧的！

http://quanzhan.ucai.cn/intro （本文是優才學院創始人伍星對全棧的理解，發布後2014年4月份，到現在也沒有改變，歡迎大家閱讀。）

UPDATE：這篇答案寫在問題添加了「補充說明」說明之前，對於「Full Stack Developer」的定義是我根據自己的理解來寫的，現在看來我（以及另外一些朋友）的理解和補充說明裡引用的那一段是不同的。所以這個答案與題目描述並不相符，僅供參考，請大家注意。

簡單來說我以下所說的 FSD 可能更像是「全才大牛」，對任何一個領域的了解都達到了該領域的專業人士的平均程度，更像是 Engineer × N ；而補充說明以及庄生（抱歉由於重名太多不知道該at哪一個）、@尤雨溪等朋友所說的 FSD 則是各領域都有一定的了解（但不必達到該領域的專業人士的水平），足夠獨立完成一個項目的各個方面，強調了解新領域的勇氣和能力（前提自然是有充分的興趣）。

對於後一種 FSD ，我是十分贊同將其作為一個目標而奮鬥的，理由和方法其他幾位也說了很多的（我很贊同獨自完成一個項目，途中了解些感興趣/有用到的、但之前不了解的新領域，永遠保持一顆好奇心，真的受益匪淺）。

而對於前一種 FSD （也是我下面即將講到的），先聲明我絕對不是也不想「裝逼」，做以下幾點說明：

對於各個領域來說，我所舉的那些例子都是我在對該領域「簡單了解」之後接觸到的很有限的一些概念、技術，是一些例子而已。該領域的大部分專業人士所能夠做到的，但絕不是說懂了這些就是專業人士，也更談不上「炫耀」（我自己也不會啊，所以有錯誤肯定在所難免，還望指正）。
這種各領域都達到專業水平的全能大牛（至少在我看來如此）真的存在么？是的，我見過一些。他們的知識廣度和深度讓我由衷佩服。而他們中的很多其實在工作中也只是某個領域的專業工程師而已。
以我有限的知識水平和學習經歷來看，能夠做到這個程度需要付出極大的努力。而所謂的「給大家潑冷水」其實倒不如說是給自己潑冷水——我也一度覺得似乎能一個人搞定一個項目（就像下面即將談到的那個「反例」一樣）就是什麼都行的 FSD 了，但遇到了他們之後，我真的意識到差距真的不是一般大。因而我才產生了疑問：在我短暫的大學生涯里，把這樣的「全棧」當成奮鬥目標真的可行、值得么？是不是先把一件事情做好更好呢？
最後，下面的回答是以「基於 Web 」的全棧「開發者」例的，所以有些朋友吐槽怎麼不說 native app 、怎麼不說 PS 、畫畫之類的……好吧，可能是我太年輕了。

====================

竊以為 full stack 不是那麼簡單的事情。當然，不同的地方可能有不同的標準，且聽我慢慢道來。

既然大家都在以 Web 為例，那我也說 Web 好了。不過事實上 full stack 也有可能是其他方面的。

租個 VPS ，從裝系統配環境開始，然後拿個 PHP Python Ruby Nodejs 什麼的寫個後端（少不了用一些框架吧，後端框架多如牛毛，不說 PHP ， Python 用個 django 、 Ruby 弄個 rails ，都挺方便吧），再給它擼個好看的頁面（表現層多半也會用個 bootstrap 之類的，如果設計能力強一點的話就用一些更輕便的 helper frame 然後主要自己手寫；邏輯控制層高端一點弄個 backbone 甚至 angular 之類搞個重 AJAX 、帶前端模板及路由的新潮 HTML5 應用）。弄好以後上線，性能出問題了，看看日誌 Google 一番調調參數，甚至多買一兩台 VPS 來弄個負載均衡什麼的。再要不，我們換成實體機，然後順便玩玩網路和虛擬化什麼的？

這樣算不算 full stack 呢？也許在一些小公司（不過現在很多互聯網創業公司水平都很高，所以也不能完全看大小）可以算是了。但在真正高水平的公司，以上的任何一點都達不到相應領域「工程師」的標準。

裝個系統調調參數甚至弄個簡單的負載均衡就叫運維了？你確定這不是網管？從幾台機器到成百上千台機器是有一個量變到質變的（雖然經過這個質變以後，對於運維工程師來說兩者就差別不大了），更別說弄個機房，搞個異地數據中心什麼的。不說CCNP，CCNA總該有吧？再者，如果不說這麼大（這麼大了可能就涉及到「架構師」了），往小一點說，也有很多可深挖的：性能調優只是根據網上的文章隨便調調參數？我見過不少牛逼的 Web 運維都讀過 Apache 和 nginx 甚至部分 kernel 代碼。沒有自動化的監控程序和運維工具難道得死死守在機器前一遍遍地敲命令？合格的運維不但熟練使用已有的工具，還會根據需要自己寫腳本、工具，因為現實情況太複雜通用工具不一定適合。很多公司里，運維還要兼顧安全問題，那麼又是一個大坑。備份、冗餘、風控個個門道都很深。

再說後端。會用 django 或者 RoR 寫點東西很厲害？這些本來都是 RAD 框架，就是拿來快速開發、快速上手的，降低了門檻。但不同的程序員編程功底和代碼質量還是會對最終成果造成很大影響。濫用 ORM 導致性能低下的例子我就不多說了。明明用了這樣的框架還能寫出帶有 SQL 注入的程序也不少見，有的甚至還存在邏輯安全漏洞，至於什麼加鹽、防 CSRF 、 XSS 、 replay attack 、 session fix 、應用層 DoS 等等，多少人都是只聽說過名字知道個大概然後用一個「厲害」的框架就以為一勞永逸？不知道原理也沒看過框架代碼，不知道框架到底是怎麼實現的、是否有一定局限……再說軟體工程方面。寫幾個測試數據就叫單元測試了？提前寫測試數據再開發就成 TDD 了？三天兩頭重構就叫敏捷了？ QA 、版本控制、協作、文檔，都不是那麼簡單的事吧。

然後說前端。 HTML CSS 本來就是以方便表示內容和布局樣式而開發的，只是「會寫」應該不算什麼難事吧？何況還有各種布局、排版庫。 JS 靈活得很，有一點 C 語法基礎的人學起來也很快，感謝 jQuery ，就算是不知道什麼是閉包、不知道 JS 原型繼承等等的三腳貓功夫也能實現大多數需求了。那麼這樣就是前端工程師？真是這樣的話為何前幾天知乎還有人問好的前端工程師為什麼這麼難找？能寫出在所有瀏覽器表現一致並且方便維護的樣式需要不少經驗積累和勤奮實踐，對瀏覽器渲染原理的了解也不可少。這還只是第一步，加上 JS 這玩意兒以後複雜度其實陡然上升了。在一個真正的大項目里，要保證各個組件正常運行不是一件容易的事， JS 本來就缺乏一些「軟體工程」特性，導致大型代碼組織不便，糟糕的 JS 程序很容易就污染了命名空間、搞錯了作用域、漏掉了異常、弄錯了類型、在非同步和回調之中迷失……一不小心，就搞掛了頁面，調起來還麻煩（就算現在有了 Chrome ）。這還沒算上性能、兼容性、安全等等問題呢。這也是為什麼前端工具/技術特別多的原因之一。好的前端工程師不但緊跟技術前沿，還樂於知道這些牛逼的技術都是怎麼實現的，然後靈活運用。

可能有人會說人的精力有限， full stack 有了廣度自然要犧牲一下深度。那麼我想說，再怎麼犧牲深度，如果各領域都像上文舉的反例那樣，那肯定是不夠的。那樣可能只算是一個愛折騰的 geek 而不是工程師。我一個大二學生就能很好地完成開頭提到的情景，並且還可以再深一點（比方網路方面有個差不多CCNA的水平和一些經驗， PHP 自認為還是比較紮實的= =，對於安全、性能優化、分散式等方面也有一些了解……），但我也只覺得自己大多數時候還只是「折騰」而已，還有太多不足和有待提高之處。事實上，上述任何一個領域中的真正的工程師都肯定能憑藉自己的學習能力和極客精神輕鬆地在業餘時間完成開頭所說的那個例子：看看 github 上那些有趣的個人開源項目和搭建起來的 demo 吧，大部分作者的本職應該都只是前端、後端或其他等等的其中之一。更不用說還有很多工程師的博客也是自己寫（我是指寫一個博客系統）、自己搭的。

full stack 一定是很難的。其實我自己作為一個互聯網領域的學徒，也面臨著這樣的困惑：我發現自己什麼都會一點、什麼都不算精（按照某些標準大概已經算是一個「full stack」了吧）。到底以後應該怎樣呢？是朝真正的 full stack 努力還是好好專精一個？看了不少招聘要求，現在就算是創業小團隊也很少會直接招 full stack 的，所以覺得大概是先做好一個性價比高一些？不知道題主為何想要成為一個 full stack 呢，是因為已經是某一領域的工程師想要做做其他方面么（這個也會影響到「怎樣成為」這個問題）？

不好意思，似乎跑題了。到最後自己還反倒提了個問。只是希望拋磚引玉，更踏實的回答多一些，不要太浮躁，把全棧說得太過輕易。

手機打字，如有差錯還望指出，謝謝。

受蘇格拉底大神的啟迪，我也來談談全棧。
禪師：成為全棧工程師，這個問題等於如何成為全才，有可能嗎
碼農：有可能，不過可能性比較低，因為達芬奇這類人畢竟是百年一遇的奇才。不過，因為我熱愛這個行業，也有一定天賦，所以只做好軟體全棧的話我想還是可能的
禪師：你玩過三國志這個遊戲嗎
碼農：我還開發過
禪師：你喜歡什麼樣的武將，諸葛亮怎麼樣？
碼農：不錯，雖然他武力只有20，不過智力有100，不過遊戲出戰不是單打獨鬥，我可以給他搭配武力100，智力20的呂布，在戰場上所向披靡
禪師：對於一個武力65，智力65的武將，你怎麼處理
碼農：砍頭或讓他下野，浪費軍糧和黃金
禪師：但是他很全面啊，兩項能力綜合130分，比諸葛亮和呂布的綜合分還要高
碼農：話雖如此但他還是太平庸，無法獨擋一面
禪師：趙雲怎麼樣
碼農：這是我最喜歡的武將之一，武力97，智力80，還有一個姜維也是，武力91，智力91，這是我心中全才的標準
禪師：首先，請把一個能力發展到90，如果你還有餘力把另一個能力發展到90，再稱呼自己全棧吧，否則你只是一個全面發展又全面平庸的廢材。
碼農：我明白了，我想facebook和google標榜的全棧，也肯定不是一個c++，java，ios，php，blabla都只會編寫hello world的全棧。

最近招人，碰到有些人的簡歷里突出自己是是全棧工程師，用的是高亮「全棧」的字眼，生怕別人看不見，但是過來面試就不行了，基礎知識都不懂。感覺「全棧」害人不淺啊，搞的現在的技術人員相當浮躁。

所以我的建議是，不要在乎自己是不是全棧工程師，起碼首先應該有一門深入的技術吧？由深到廣，這是一個知識學習積累的過程，不是個Title。

去創業

我感覺大家討論的熱火朝天，卻有幾個關鍵的問題都沒有定義清楚
1）什麼是全棧工程師？
有的人說是精通前端，精通後端，精通底端
------按照這個標準，地球上估計都找不出一個「全棧工程師」；
有的人說是懂前端，懂後端
------按照這個標準，我估計大部分目前做後端都可以稱為「全棧工程師」，畢竟哪個寫後台的一個頁面都沒寫啊？大部分目前做app的也可以算「全棧工程師」，畢竟哪個做app的完全不知道後端怎麼寫啊？但如果這就是「全棧工程師」了，未免有點誇張了；

所以，如何定義「全棧工程師」就是一個很難的問題。我個人傾向於所謂的「全棧工程師」，應該是「精某端，懂另外一端」，「精」自然就是精通，能夠玩各種花樣，熟悉各種機制；「懂」就是知道怎麼一回事，知道能夠完成什麼工作，知道常見的功能如何完成。

2）什麼情況下需要「全棧工程師」？
有的人說以後全部都只要「全棧工程師」，我覺得這完全是胡扯！分工合作是人類社會進步的一個很大的推動力，難道軟體業發展到今天，反而要反其道而行之了么？肯定不可能。術業有專攻，分工合作才能促進整體效率的提升。

所以，「全棧工程師」真正能夠發揮很大作用的，一個應該是如很多人所說的「創業」，自己創業，剛開始沒那麼多人那麼多錢，要儘快做出產品，那麼」全棧「就是一個必備的條件了；另外一個是」做原型「，比如說有了新產品想法，不太可能一下子撲100個人上去搞，很多時候都是先投3~5個人先試試，這個時候」全棧「也是很有優勢的。

但無論是創業，還是新產品，一旦上了規模，必然要開始分工合作，全棧可能就慢慢退出，或者轉型為類似產品的角色，起到一個膠水的作用

3）你要成為」全棧工程師「么？
我覺得看個人興趣，畢竟前端和後端或者底端差異很大，不是想成為就成為的。
前端偏向於藝術，後端偏向於工程，底端偏向於數學，一個人很難同時具備這三種截然不同的素質。比如說像我這種碼農，完全沒有審美觀，顏色分辨不超過10種，讓我做前端，做出來的只能說能用，遠遠達不到美觀的要求。

但保持適當的興趣還是有必要的，做不出美觀的前端，能作出能用的，一開始也不錯
所以我覺得每個人都可以去嘗試一下。

應該來點具體的東西啊，上圖，

Github地址 https://github.com/geekcompany/full-stack-tree

個人感覺「寬度」很重要，「深度」更重要，尤其是現在這個高度專業化的社會，分工非常具體。

對於開發者來說，很多時候coding真的只是一種樂趣，而可能做出一個活生生的產品，就更樂不可言了。而且一般喜歡coding的人，好奇心肯定不小，一旦鑽進了開發的領域，會被各種不同領域的技術亮瞎眼睛：-）

我個人比較菜，屬於典型的蜻蜓點水式學習，當然這是之前，目前正在形成一套自己的學習機制。本科專業是機械，感覺很無趣，骨子裡對「計算機」感興趣，所以就各種去自學。先是從C語言開始，Turbo C敲個a+b就樂壞了，那時候沉浸在自己井底之蛙的世界裡，事後想想真的略傻！之後不知輕重地跑去參加ACM，整演算法，結果鼻青臉腫。大一下開始玩Linux，心靈得到一些慰藉。

之後進入一個團隊，先學Java，沒怎麼學好；後來進入了嵌入式組，在這裡泡了一年，多少對ARM，DSP，嵌入式Linux，甚至CPLD，FPGA之類有過了了解，還十分大膽地寫了幾行Verilog代碼，而在那裡面最讓我著迷的無疑是嵌入式Linux了。然後大四整一年參加了一個比賽，做控制，寫uCOS之上的機器人控制代碼，偶爾也會寫底層的驅動（不過整個系統採用的是DSP + FPGA，大部分驅動是負責FPGA的隊友寫的）。

閑暇之餘，自己還對Web開發十分熱衷，CSS和JS的世界也別樣精彩，但也只是會皮毛罷了。

所以總結來看，凡是作為一個開發者，你就有可能接觸到各種開發技術，因為你太長時間在計算機的世界裡面，很多辭彙耳濡目染。什麼前端（Front End），後端（Back End），桌面（Desktop），移動客戶端（Android，iOS），Web，嵌入式（Embedded），工具鏈（Tool Chain），伺服器（Server），資料庫（Database），用戶體驗（UX），等等。

可以參考之前的回答，如果一個開發者啥都會，但是又做不出什麼實際有價值的東西，那還是相當於啥都不會；待你的寬度和視野足夠了，能夠宏觀看待技術學習的時候，但是深入學習某一個你最感興趣的技術的時候了。貪多求全，必死無疑！

再回到Full Stack Developer，看了那個鏈接，基本贊同作者試圖傳達的觀點，但是可以把技術層面的東西再從其他方面分類。我個人對Full Stack的理解，從底層到上層，應該包含操作系統，工具鏈，資料庫，分散式系統，用戶態的桌面應用程序開發，移動客戶端應用開發，基於瀏覽器的互聯網產品，針對專用系統的演算法開發等等。即是從操作系統一路到應用層面，不在於你會多少工具，而在於你掌握了多少核心思想。很多東西確實是相通的，人最重要的是能思考，有解決問題的能力，能夠舉一反三。

對於操作系統（比如Linux）來說，我覺得讀內核的源代碼可能不是必須的，但是對操作系統每一個關鍵模塊工作原理的理解是必須的；而對工具鏈（比如gcc）來說，了解他們之後你對自己的源代碼如何被轉換成及機器代碼就會更深的理解，就可能會更加嚴謹地編程，也能利用工具鏈的某些特性提高你的程序性能，發現bug後的除錯可能也會相對容易；對於伺服器這邊，高可用，高並發是比較核心的問題，能夠工作的伺服器現在很容易搞到，但是高性能的伺服器（不是靠硬體，靠優化配置）就比較考驗人了，同理對於資料庫產品來說，可能最核心的是scheme設計和性能優化，緩存之類的，學習的時候了解了基本的SQL，就要去深入了解資料庫的原理了；前端的東西是直接更用戶打交道，這個時候就要有足夠的敏銳度，發現用戶的痛點，才能夠做出體驗良好的產品；移動客戶端稍顯特殊，但是本質無異，先了解一下Android的整體架構，為什麼選用Java作為第三方開發語言之類的問題會對之後的產品開發有不少幫助。

上面啰嗦了這麼多，我想表達的就是，全棧的開發者不在於「會用」多少技術，而在於「懂」多少技術；只有掌握了技術的原理，才能說是「會」了這個技術。

因此我建議大家一定要多看原理性的東西，並且多實踐，這樣才能朝著Full Stack Developer一步一步邁進，同時鍛煉自己的思維能力，解決問題的能力，還有溝通能力（和客戶）。

最近看書比較多，也在不停地思考一些東西，跟大家共勉。

贊同上面@Cat Chen 的說法。
我覺得Full Stack關鍵不在於你已經會什麼，以及你已經會的東西有多深刻。而是在於，你能夠會什麼。
當一個可以隨意切換自己角色並且順利適應各種技術甚至不是技術的挑戰的工程師，那就可以稱得上是一個Full Stack了。
這需要的不僅僅是熱情，更需要適合自己的方法和強大的學習能力以及近乎不要臉的抗失敗打擊能力。
一家拙見。

從全棧工程師到全棧員工，軟體吞噬世界的步伐又進了一步。以下是 Chris Messina的文章

在我離開 Google快兩年之後，我開始意識到職業環境正在發生的變化。傳統的管理紀律正在漸漸瓦解。要想在職場上成功，需要的技能比以往更加多樣而難以定義。如今，要想在職場上有所成就，你必須成為一個真正的博學者，成為一名全能全棧員工。

什麼是全棧員工（full-stack employee）？

就像「全棧工程師（full-stack engineer）」和「全棧創業（full-stack startup）」一樣，全棧員工（full-stack employee）擁有超強的綜合技能，有著無法估量的價值。他們可以在快速演進、變革的技術浪潮中如魚得水。他們可以在事實稀缺、觀點橫飛的過剩信息中憑直覺做決定。全棧員工能夠熟練運用設計語言，明白使用卡通字體無異於犯罪行為，輕車熟路地嘲弄Keynote、Sketch抑或是Skitch。他們清楚用戶界面（UI）和用戶體驗（UX）的區別。

他們可以和人討論工程問題，能搞清楚演算法、編程，也能理解前端的等級和後端的等級根本不是一回事。雖然他們可能並不親自編程，但他們知道GitHub、StackOverflow都是做什麼的。如果必要，他們會暴力破解一段「複製粘貼」的腳本，在CSV文件中進行基礎分析。

他們是最新銳的社交應用的用戶，深諳自我推廣之道。他們既可以在聽眾面前循循善誘地耐心講故事，也可以在看了3分鐘kickstarter視頻後就能指出：亮明要點的時間不能長於一段Instagram、Vine短視頻。注意力就是這個時代的硬通貨。

全棧員工對新的想法、最棒的實現路徑、提升生產力和與愉悅度的事情有著「貪得無厭」的胃口。他們對世界及其運轉規則充滿好奇心，想知道如何留下自己的印記。正是這一點使他們與過去時代的人們區分開來。開始一份工作時，全棧員工不會戴上「眼罩」埋頭苦幹，而是始終與行業的發展保持同步，因為他們清楚：變革往往出現在邊緣地帶，不能只盯著腳下的一畝三分地。

一名全棧員工是什麼樣子的？

有了24小時在線的移動設備，工作和非工作之間的界限正在模糊，既然工作正在變得碎片化，全棧員工要清楚地意識到自己的生活方式也要隨之變化，比如使用整體式單色衣櫃、功能明確的廚具。

成為全棧員工意味著要在兩極之間來回切換。他們既要適應單兵作戰，自給自足（比如自己安排時間，使用自己的設備工作），也要能和團隊高效協作。過去，在大型團隊中，往往需要有一名 IT經理來決定使用何種技術。如今，隨著人們越來越多地使用個人設備工作，員工需要自己來搞定跨設備、跨平台溝通等問題。就拿企業協作工具來說。Slack可以整合所有東西，而微軟卻只對自己平台上的工具開放特權。如果你不能接入其他人的 API，你已經落後於時代了。全棧員工也是如此——他們至少應該熟知所有最新的應用，這樣才不會落伍出局。

全棧員工必須要在自己的領域有深刻的洞見，同時也要機動地應對優先事項的轉換，勝任不同的安排。組織的扁平化已經不是新現象，變革的動力可能來自頂層，也可能來自底層，有時候需要個體來決定事情的優先順序。現場服務工程師（FSE，Field Service Engineer）應該遍布組織內部，卻又不能分布的過於稀疏。即使不用監控每一位員工，他們也應該知道每一個人在做什麼，保證他們在不熟悉的事情上不會手足無措。

要成為一名全棧員工不是一件容易的事，回報卻也很豐厚。首先，他們可以更自由地按照自己的方式、在自己喜歡的地方（Teleport等服務可以幫助他們找到價廉的工作地點）、喜歡的時間工作。他們可以使用最新的工具，自給自足，自我管理。由於他們的工作涉及多領域、多學科之間的協作，會帶來更寬廣的視野，更豐富多彩的經歷。在組織內部，他們的影響力也會不斷上升，對組織的成敗也將擔負起更大的責任，團隊的成功與否更加休戚相關。

這對僱主和管理者意味著什麼？

對於企業和管理者來說，在人力市場上爭奪全棧員工意味著很多準備工作。首先，你們做好準備來吸引、留住這些人才了嗎？其次，你們團隊的工作風格是否明確，你們對遠程辦公的支持如何？再次，你們允許的工作時間，支持員工自主安排工作計劃嗎？最後，你們會給他們留出健身、養生、陪伴家人的時間嗎？

Google雖然充分考慮到了員工的健康、精神需求，但反過來也要求員工高度負責。 Google的員工可以以任何方式在任何時間、任何地點工作，只要能最大程度發揮創造力。但它同時希望員工能夠隨時參加一場臨時安排的快速議事會。你的團隊準備好了嗎？

如果你還沒有嘗試過，不妨一試，來感受下」全棧員工「的工作環境是什麼樣子的。不同背景的人們在一個公共空間內彼此協作。他們一直在線，通過Slack等協作對話平台交流。大多數全員協作空間都是臨時搭建，多種實體、虛擬的工具混合使用（白板、投影儀、會議室、視頻會議設備等）。

對於職員和管理者來說，最需要培養的是」同理心「——員工和管理者都要對彼此有一種「同情的理解」，在彼此溝通、協作、要求時能夠提出具體的需求。因為未來的工作需要高度的靈活性和自主性，但這並不意味著每個人給自己下達工作命令、工作指標。管理者的角色依然是必要的。

未來的工作是什麼樣子的？

說未來的職場將由全棧員工引領，無疑有些誇張，但這是一個顯而易見的趨勢。毫無疑問，工作的定義正在發生變化，員工的最大價值是應對不確定性，能夠從海量的信息中提煉出有效的戰略、戰術。

而且，在工作機器人大規模「入侵」之前，我們只有10年的時間。他們正在取代體育新聞、駕駛、快遞等重複性工作，人們要重新思考適合自己的角色。感知和綜合的能力將是第一位的，而語言、辨析力和同感力在進行複雜、敏感的任務是都是必備技能。全棧員工將幫助我們向未來過渡，將成為新的混合經濟中的關鍵角色。

我覺得所謂「全棧工程師」是自我設限，是格局小的表現。

應該把這個概念升格為「全棧人」。這是一種什麼樣的人呢？他們自己思考產品方案，自己設計交互，自己開發(管他什麼前端後端左端右端呢，全包！)，自己給自己提bug，自己運維上線，自己運營找市場，自己做客服聽客戶罵。總之就是脫離了低級趣味的、全能的人。