為什麼說全棧工程師是未來？| 長文多圖

謹以此文獻給每一個為成為優秀全棧工程師奮鬥的人。

節選自《Growth: 全棧工程師學習手冊》

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

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

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

技術的革新史

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

 CGI

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

當時這種網站的URL類似於：

https://www.phodal.com/cgi-bin/getblog

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

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

#!/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——義大利語：你好！

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

 無棧

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

1. 這個世界充滿了未解的迷，但是我只想解開我感興趣的部分。

2. 沒有探索，哪來的真愛？你都沒有探索過世界，你就說這是你最喜歡的領域。

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

中小學：程式語言 -> 高中：作業系統、核心、遊戲程式設計 -> 大學： 硬體、Web開發 -> 工作：後端 + 前端

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

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

參考書籍

• 《精益企業： 高效能組織如何規模化創新》

• 《企業應用架構模式》

• 《敏捷軟體開發》

• 《技術的本質》

更多精彩內容歡迎關注我的微信公眾號(Phodal)