為什么未來是全棧工程師的世界？
技術在過去的幾十年里進步很快，也將在未來的幾十年里發展得更快。今天技術的門檻下降得越來越快，原本需要一個團隊做出來的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模式了。
我有理由相信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發展了：
而這就是全棧學習帶來的優勢，學過的東西多，學習能力就變強。學習能力往上提的同時，你就更容易進入一個新的領域。
參考書籍
-
《精益企業： 高效能組織如何規模化創新》
-
《企業應用架構模式》
-
《敏捷軟件開發》
-
《技術的本質》
