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

同時，由于公司組織結(jié)構(gòu)的變遷，也決定了賦予每個人的職責(zé)將會越來越多。盡管我們看到工廠化生產(chǎn)帶來的優(yōu)勢，但是我們也看到了精益思想帶來的變革。正是這種變革讓越來越多的專家走向全棧，讓組織內(nèi)部有更好的交流。

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

技術(shù)的革新史

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

CGI

二十年前的網(wǎng)站以靜態(tài)的形式出現(xiàn)，這樣的網(wǎng)站并不需要太多的人去維護、管理。接著，人們發(fā)明了CGI（通用網(wǎng)關(guān)接口，英語：Common Gateway Interface）來實現(xiàn)動態(tài)的網(wǎng)站。下圖是一個早期網(wǎng)站的架構(gòu)圖：

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

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

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

MVC架構(gòu)

我有理由相信Martin Fowler的《企業(yè)應(yīng)用架構(gòu)模式》在當(dāng)時一定非常受歡迎。代碼從上面的耦合狀態(tài)變成了：

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

后臺服務(wù)化與前端一致化架構(gòu)

后臺在不知不覺中已經(jīng)被服務(wù)化了，即只提供API接口和服務(wù)。前端在這時已經(jīng)盡量地和APP端在結(jié)合，使得他們可以保持一致。

軟件開發(fā)的核心難題：溝通

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

在這其中的每一個過程實質(zhì)上都是為了解決溝通的問題。從瀑布到敏捷是為了解決組織內(nèi)溝通的問題，從敏捷到精益不僅僅優(yōu)化了組織內(nèi)的溝通問題，還強化了與外部的關(guān)系。換句話說，精益結(jié)合了一部分的互聯(lián)網(wǎng)思維。

瀑布式

在最開始的時候，我們預(yù)先設(shè)計好我們的功能，然后編碼，在適當(dāng)?shù)臅r候發(fā)布我們的軟件：

然而這種開發(fā)方式很難應(yīng)對市場的變化——當(dāng)我們花費了幾年的時間開發(fā)出了一個軟件，而這個軟件是幾年前人們才需要的。同時，由于軟件開發(fā)本身的復(fù)雜度的限制，復(fù)制的系統(tǒng)在后期需要大量的系統(tǒng)集成工作。這樣的集成工作可能要花費上大量的時間——幾星期、幾個月。

當(dāng)人們意識到這個問題的時候，開始改進工作流程。出現(xiàn)了敏捷軟件開發(fā)，這可以解釋為什么產(chǎn)品經(jīng)理會經(jīng)常改需求。如果一個功能本身是沒必要出現(xiàn)的話，那么為什么要花功夫去開發(fā)。但是如果一個功能在設(shè)計的初期就沒有好好設(shè)計，那么改需求也是必然的。

敏捷式

現(xiàn)有的互聯(lián)網(wǎng)公司的工作流程和敏捷軟件開發(fā)在很多部分上是相似的，都有迭代、分析等等的過程：

但是據(jù)我的所知：國內(nèi)的多數(shù)互聯(lián)網(wǎng)公司是不寫測試的、沒有Code Review等等。當(dāng)然，這也不是一篇關(guān)于如何實踐敏捷的文章。敏捷與瀑布式開發(fā)在很大的區(qū)別就是：溝通問題。傳統(tǒng)的軟件開發(fā)在調(diào)研完畢后就是分析、開發(fā)等等。而敏捷開發(fā)則會強調(diào)這個過程中的溝通問題：

在整個過程中都不斷地強調(diào)溝通問題，然而這時還存在一個問題：組織結(jié)構(gòu)本身的問題。這樣的組織結(jié)構(gòu)，如下圖所示：

如果市場部門/產(chǎn)品經(jīng)理沒有與研發(fā)團隊坐一起來分析問題，那么問題就多了。當(dāng)一個需求在實現(xiàn)的過程中遇到問題，到底是哪個部門的問題？

同樣的如果我們的研發(fā)部門是這樣子的結(jié)構(gòu)：

那么在研發(fā)、上線的過程中仍然會遇到各種的溝通問題。

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

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

如果你經(jīng)?？匆恍╆P(guān)于全棧和專家的技術(shù)文章的時候，你就會發(fā)現(xiàn)不同的人在強調(diào)不同的方向。大公司的文章喜歡強調(diào)成為某個領(lǐng)域的專家，小公司喜歡小而美的團隊——全棧工程師。

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

專家

我們所見到的那些關(guān)于技術(shù)人員應(yīng)該成為專家的文章，多數(shù)是已經(jīng)成為某個技術(shù)領(lǐng)域里的專家寫的文章。并且我們可以發(fā)現(xiàn)很有意思的一點是：他們都是管理者。管理者出于招聘的動機，因此更需要細分領(lǐng)域的專家來幫助他們解決問題。

全棧

相似的，我們所看到的那些關(guān)于成為全棧工程師的文章，多數(shù)是初創(chuàng)公司的CTO寫的。而這些初創(chuàng)公司的CTO也多數(shù)是全棧工程師，他們需要招聘全棧工程師來幫助他們解決問題。

兩種不同的學(xué)習(xí)模型

而不知你是否也注意到一點：專家們也在強調(diào)“一專多長”。因為單純依靠于一個領(lǐng)域的技術(shù)而存在的專家已經(jīng)很少了，技術(shù)專家們不得不依據(jù)于公司的需求去開拓不同的領(lǐng)域。畢竟“公司是指全部資本由股東出資構(gòu)成，以營利為目的而依法設(shè)立的一種企業(yè)組織形式；”，管理人們假設(shè)技術(shù)本身是相通的，既然你在技術(shù)領(lǐng)域里有相當(dāng)高的長板，那么進入一個新的技術(shù)也不是一件難的事。

作為一個技術(shù)人員，我們是這個領(lǐng)域中的某個子領(lǐng)域?qū)＜?。而作為這樣一個專家，我們要擴展向另外一個領(lǐng)域的學(xué)習(xí)也不是一件很難的事。借鑒于我們先前的學(xué)習(xí)經(jīng)驗，我們可以很快的掌握這個新子域的知識。如我們所見，我們可以很快地補齊圖中的短板：

在近來的探索中發(fā)現(xiàn)有一點非常有意思：如果依賴于20/80法則的話，那么成為專家和全棧的學(xué)習(xí)時間是相當(dāng)?shù)?。在最開始的時候，我們要在我們的全棧工程和專家都在某個技術(shù)領(lǐng)域達到80分的水平。

那么專家，還需要80%的時間去深入這個技術(shù)領(lǐng)域。而全棧工程師，則可以依賴于這80%的時候去開拓四個新的領(lǐng)域：

盡管理論上是如此，但是專家存在跨領(lǐng)域的學(xué)習(xí)障礙——套用現(xiàn)有模式。而全棧也存在學(xué)習(xí)障礙——如何成為專家，但是懂得如何學(xué)習(xí)新的領(lǐng)域。

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

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

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

對于全棧工程師來說，他們喜歡依賴于外部的思維，用于產(chǎn)生顛覆式思維。如Angular.js這樣的框架便是例子，前端結(jié)合后端開發(fā)語言Java的思維而產(chǎn)生。而專家則依賴于內(nèi)部的條件，創(chuàng)造出不一樣的適應(yīng)式創(chuàng)新。如之前流行的Backbone框架，適應(yīng)當(dāng)時的情況而產(chǎn)生。

全棧工程師的未來：無棧

全棧工程師本身不應(yīng)該僅僅局限于前端和后臺的開發(fā)，而可以嘗試去開拓更廣泛的領(lǐng)域——因為全棧本身是依賴于工程師本身的學(xué)習(xí)能力，正是這種優(yōu)秀的學(xué)習(xí)能力可以讓他們可以接觸更廣泛的知識。

全棧的短板

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

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

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

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

無棧

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

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

沒有探索，哪來的真愛？你都沒有探索過世界，你就說這是你最喜歡的領(lǐng)域。

當(dāng)我第一次看到全棧工程師這個名字的時候，我發(fā)現(xiàn)我已然是一個全棧工程師。因為我的學(xué)習(xí)路線比較獨特：

中小學(xué)：編程語言 -》 高中：操作系統(tǒng)、內(nèi)核、游戲編程 -》 大學(xué)： 硬件、Web開發(fā) -》 工作：后端 + 前端

而在當(dāng)時我對SEO非常感興趣，我發(fā)現(xiàn)這分析和Marketing似乎做得還可以。然后便往Growth Hacking發(fā)展了：

而這就是全棧學(xué)習(xí)帶來的優(yōu)勢，學(xué)過的東西多，學(xué)習(xí)能力就變強。學(xué)習(xí)能力往上提的同時，你就更容易進入一個新的領(lǐng)域。