[淘寶玉伯]說說全棧工程師

全棧工程師（Full Stack Developer）好像突然就火了，知乎、微博上都有討論。這個概念在 2012 年時就有提出：What is a Full Stack Developer?，主要觀點是：

有這么一批人，他們對軟件開發的很多層未必精通，但對每一層都很熟悉，他們對軟件技術充滿熱情，這種人就是所謂的全棧工程師。

對每一層都熟悉，究竟包含哪些層呢？作者的觀點是：

1. 服務器、網絡、運維。
2. 數據模型。
3. 業務邏輯。
4. API 層、Action 層、MVC。
5. UI 層。
6. 用戶體驗。
7. 理解用戶與商業需求。

如果對以上七層都很熟悉，同時精通一二，就是全棧工程師了。

這樣來看其實并不難。比如對 Java 開發來說，第 3 層是工作重點，稍微有點追求的工程師，對 1、2、4、5 層也都會有一定的熟悉。對前端工程師來說，第 5 層是工作重點，然后對 3、4、6、7 層也會有一定熟悉度。其他職位，運維、DBA、測試等，也都有精通點，同時對周邊的層會有熟悉度。

也就是說，大部分有點追求的工程師已經是四分之三棧工程師。反而單棧工程師很少很少，甚至不可能存在。

回到全棧工程師的定義，可以分解為三點：

1. 精通若干層。
2. 熟悉所有層。
3. 對軟件技術充滿熱情。

第 3 點很重要。未必要刻意去讓自己熟悉所有層，如果能「對軟件技術充滿熱情」，那么遇到陌生領域時，一個優秀的工程師會有能力去快速學習，從而慢慢地自然而然地就熟悉所有層，就莫名其妙成為全棧工程師了。

全棧工程師是不給自己設限，是永遠保持激情和學習欲望的一批人。

另外想說一點，全棧工程師并不違背《國富論》提到的社會分工。在軟件開發領域，分工依舊是提高效率的重要手段。但分工后，還有影響效率的一個重要因素：

分工是否合理，是否已達成讓合適的人做合適的事。

從分工合理性的角度去考慮，會發現一些傳統的分工未必是合適的。比如第 4 層 MVC 中的 View 和 Controller 層，Java 開發工程師真的是最合適的人選嗎？這一層或許可以細化為：

4.1、Service、API、Model 層。
4.2、View、Router 等處理。

這樣，4.1 依舊是后端開發擅長的領域，4.2 則很可能交給前端工程師來負責更合理。再次分工、分工合理性的判定，經常就需要跨界了解，需要全棧工程師的視角。

如果 4.2 交給前端來負責，Node 很可能就是當下更合適的技術選型。基于 Node 可以達成更合理的分工，有如 NCZ 的想法：

全棧視角可以讓我們重新去審視、去思考各個角色最合適去做什么，從而有可能促進更合理的分工協作。一旦發現了更合理的分工、需要對分工做出調整時， 全棧就是一種自然而然的要求。比如基于 Node 的前后端分工協作，就需要前端工程師勇敢地去承擔原來只是熟悉卻并不精通的領域。如果能承擔下來，無論對前端還是后端，效率上都會有提升，甚至帶來一系列 研發交付方式的變革。

全棧的背后，是自由，是分工的更細化，是分工的更專業。

（完）

原文鏈接：https://github.com/lifesinger/lifesinger.github.com/issues/185