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

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

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

技術(shù)的革新史

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

CGI

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

當(dāng)時(shí)這種網(wǎng)站的URL類似于： https://www.phodal.com/cgi-bin/getblog

(PS：這個(gè)鏈接是為了講解而存在的，并沒有真實(shí)存在。)

用戶訪問上面的網(wǎng)頁的時(shí)候就會(huì)訪問，cgi-bin的路徑下對(duì)應(yīng)的getblog腳本。你可以用Shell返回這個(gè)網(wǎng)頁：

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

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

這簡(jiǎn)直就是一場(chǎng)惡夢(mèng)。不過，在今天好似那些PHP新手也是這樣寫代碼的。

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

MVC架構(gòu)

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

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

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

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

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

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

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

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

瀑布式

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

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

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

敏捷式

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

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

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

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

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

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

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

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

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

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

專家

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

全棧

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

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

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

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

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

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

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

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

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

[[165116]]

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

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

全棧工程師的未來：無棧

全棧工程師本身不應(yīng)該僅僅局限于前端和后臺(tái)的開發(fā)，而可以嘗試去開拓更廣泛的領(lǐng)域——因?yàn)槿珬１旧硎且蕾囉诠こ處煴旧淼膶W(xué)習(xí)能力，正是這種優(yōu)秀的學(xué)習(xí)能力可以讓他們可以接觸更廣泛的知識(shí)。

全棧的短板

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

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

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

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

無棧

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

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

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

當(dāng)我***次看到全棧工程師這個(gè)名字的時(shí)候，我發(fā)現(xiàn)我已然是一個(gè)全棧工程師。因?yàn)槲业膶W(xué)習(xí)路線比較獨(dú)特：

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

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

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

參考書籍

• 《精益企業(yè)： 高效能組織如何規(guī)?；瘎?chuàng)新》

• 《企業(yè)應(yīng)用架構(gòu)模式》

• 《敏捷軟件開發(fā)》

• 《技術(shù)的本質(zhì)》