摘要：全棧工程師專家人的大腦如同一間空空的閣樓，要有選擇地把一些家具裝進(jìn)去。如果他們都是一本書，那么全棧工程師的書是一個(gè)索引。如下圖所示，左邊的關(guān)系數(shù)據(jù)模型即為全棧工程師，右邊則為專家。好奇與專家不同的是，全棧工程師更容易被新的技術(shù)吸引。

什么是全棧工程師

在現(xiàn)在這一個(gè)時(shí)代來說，不會(huì)有人掌握所有的編程語言、技能，以后應(yīng)該會(huì)有，但是掌握這些全部技術(shù)的不是人類了。所以，其實(shí)我們需要的是懂得多種技術(shù)的，并能借些獨(dú)立完成產(chǎn)品的人。

當(dāng)我們需要做一個(gè)移動(dòng)CMS的時(shí)候，我們就會(huì)在不同的技術(shù)棧之前選擇，或是RequireJS + Backbone + jQuery + Mustache，又或者是 ReactJS + Backbone，當(dāng)然也有可能是AngularJS等等。我們所需要做的是，從中選出一個(gè)最好的方案，然后實(shí)施之。

這也就意味著，我們需要有更好的知識(shí)面，也會(huì)導(dǎo)致對于某些技術(shù)的不夠深入。兩者就是一個(gè)很好的對立面，在這兩之間很好地平衡可能就意味著平庸。有時(shí)也并非如此，但是多數(shù)時(shí)間這這樣的。要么成為專家，要么成為全棧，要么就平衡他們。

全棧工程師VS專家

  
人的大腦如同一間空空的閣樓，要有選擇地把一些家具裝進(jìn)去。

柯南道爾說的話還是很有道理的。由于這個(gè)閣樓的大小是有限的，假定他是一個(gè)書架。那么全棧工程師的書架就會(huì)充滿各種各樣的技術(shù)棧從MySQL、SQLite、MongoDB、Redis等等各種各樣的書籍;而專家的書籍則是MySQL優(yōu)化、MySQL重構(gòu)、MySQL權(quán)威指南、DBMS等等的專業(yè)書籍合集。

  
如果他們都是一本書，那么全棧工程師的書是一個(gè)索引。專家的書則更多的是內(nèi)容本身。 所以，每個(gè)人都會(huì)去選擇不同的存儲(chǔ)方式、不同的數(shù)據(jù)庫。

對于我們大腦這個(gè)數(shù)據(jù)庫來時(shí)，平時(shí)我們存儲(chǔ)的是Key-Value(ps: 我們只有key，value是Google和書本)，對于專家來說，存儲(chǔ)的是Documents。在同樣的容量大小的情況下，我們可以了解到更多的知識(shí)。如下圖所示，左邊的關(guān)系數(shù)據(jù)模型即為全棧工程師，右邊則為專家。

Key

曾經(jīng)迷惑了很久: 為什么對于一些知識(shí)點(diǎn)，我需要去Google，而別人可以獨(dú)立地完成的時(shí)候。我就意識(shí)到我更適合于互聯(lián)網(wǎng)企業(yè)，據(jù)說在一些電信設(shè)備制造商里是沒網(wǎng)的辦公環(huán)境。然而在多數(shù)的時(shí)候，這并非一種劣勢。

我們會(huì)更快地方式來解決問題，因?yàn)槲覀冇幸恍┻@方面的經(jīng)驗(yàn)。不足則是，有時(shí)候我們沒有辦法深入問題去分析

如何成為全棧工程師

這是一個(gè)有趣的問題，在知乎也有這樣的討論。而我覺得，最重要的是好奇與創(chuàng)造。

創(chuàng)造

記得在上大學(xué)之前已經(jīng)有一個(gè)明確的目標(biāo)，盡可能地做到能做到的程序——想到的都應(yīng)該能做到。于是，順著這個(gè)目標(biāo)構(gòu)建了一個(gè)知識(shí)體系，又或者說是索引。

當(dāng)我們心里有一個(gè)想法的時(shí)候，我就開始從一個(gè)key中進(jìn)行頭腦風(fēng)暴，如之前做的地圖搜索。我們要做的功能便是: 持久化GEO信息，在地圖上顯示坐標(biāo)。

1.首先會(huì)在頭腦中列出所有我用過的框架，選擇后臺(tái)框架:

Django(Python)、Flask(Python)、Ruby On Rails(Ruby)、Sinatra(Ruby)、NodeJS、Laravel(PHP)、Spring(Java)

排除過后就只剩下Django、Flask、NodeJS，接著因?yàn)镈jango內(nèi)置Geo支持，果斷選擇了Django。

2.接著，對于持久化方案的選擇:

由于Django內(nèi)置ORM，所以這一步可以輕輕松松地過去。不過，我選的是SQLite3，本地調(diào)試方便，還可以將數(shù)據(jù)復(fù)制到服務(wù)器上。

3.然后，對于空間搜索的支持:

就這么有了兩個(gè)搜索引擎和一個(gè)數(shù)據(jù)庫: ElasticSearch、Solr以及MongoDB。因?yàn)镈jango對于MongoDB支持的原因，想到使用搜索引擎會(huì)更容易搜索到結(jié)果。接著找到了Haystack，看到Solr需要手動(dòng)更新索引就選擇了ElastiSearch。

4.到了，移動(dòng)開發(fā):

要跨平臺(tái)支持自然是Cordova，用Hybird還是Ionic好用。

5.實(shí)戰(zhàn)

這一步自然也不是問題，向來是以實(shí)戰(zhàn)出真知的。

在不斷創(chuàng)造地過程中會(huì)學(xué)到更多的知識(shí)，有更多的方案可以選擇。下一次，將會(huì)想著用不同的技術(shù)棧再實(shí)現(xiàn)一遍。有了之前的體系，再橫向深入也是一個(gè)很好的突破點(diǎn)。如，我們用Python構(gòu)建一個(gè)原型，然后我們用Java來實(shí)現(xiàn)。

好奇

與專家不同的是，全棧工程師更容易被新的技術(shù)吸引。至于，是好是壞我想大家都懂的。

當(dāng)ReactJS出來的時(shí)候，就會(huì)試著去玩。

當(dāng)Ionic還在測試版的時(shí)候，就會(huì)做一個(gè)個(gè)Demo。

而有意思的是，同我們在《技術(shù)的本質(zhì)》中看到的一樣，新的技術(shù)都是基于舊的技術(shù)產(chǎn)生的。沒有一種技術(shù)可以無中生有。所以要學(xué)習(xí)一種新的技術(shù)必然不難，只是有時(shí)候會(huì)難以深入。

全棧程序員進(jìn)階

在思考過一些日子后，我明白了更多的東西。也似乎找到了兩條更有意思的成長路線:

構(gòu)架設(shè)計(jì)

在我打算試著寫一個(gè)名為Echoes的CMS的時(shí)候，找到了書架上的幾本書:

《架構(gòu)之美》
《面向模式的軟件架構(gòu)》
《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》
《實(shí)現(xiàn)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》
《軟件框架設(shè)計(jì)的藝術(shù)》
發(fā)現(xiàn)書中提及到的一些模式似乎已經(jīng)很常見了，要理解起來已經(jīng)變得很簡單，看上去那些更像是一個(gè)又一個(gè)的項(xiàng)目的縮影。

更主要的點(diǎn)還有:

架構(gòu)師并不是最好的程序員，但是知識(shí)面一定要廣。
只有有著更多的知識(shí)才能決定好方案，如果我們只深入一部分知識(shí)，那么我們無法總做出正確地決定。所以，也必須也是一個(gè)好的成長方向。

成為專家

我一直不認(rèn)同木桶理論的一點(diǎn)是，我們會(huì)被最低的木板限制。但是有一天我們會(huì)被最高的那一塊限制到，畢竟我們都會(huì)意識(shí)到我們的短片，我們會(huì)盡量把所有的木板提到同樣的高度，以保證水的容量。但是，如果最高的那塊木板不是那么高呢? 那么，為什么不在一開始的時(shí)候，讓它盡可能的高?

于是，我想說的是我們需要在某一部分成為專家。當(dāng)我們在某一領(lǐng)域成為專家，要在另外一領(lǐng)域成為專家，也是很容易的一件事。

當(dāng)我向Senior程序員咨詢一些成長意見的時(shí)候(ps: 畢業(yè)不到一年)，那么就是往專家發(fā)展。對于一個(gè)Java Web程序員來說，成長意見可能就是深入Spring、探索Tomcat底層、深入JVM。問題是，他們都寫得復(fù)雜，但是我們又不能放棄這樣的成長機(jī)會(huì)。我們還能做的事，從一個(gè)更簡單的語言中學(xué)會(huì)這些原理，再回頭去補(bǔ)充。

對應(yīng)于Spring，會(huì)有Flask、Tornado;對應(yīng)于Tomcat，我們是不是可以深入Gunicorn;對應(yīng)于JVM是不是也會(huì)有Python VM，不過還是JVM的書比較多。等我們在一個(gè)更簡單的層級(jí)上了解到這些，那么對于一個(gè)臃腫的語言來說不會(huì)是難題。