全棧工程師的思考 | 步步進階經驗之談

什麼是全棧工程師

在如今這一個時代來講，不會有人掌握全部的編程語言、技能，之後應該會有，可是掌握這些所有技術的不是人類了。因此，其實咱們須要的是懂得多種技術的，並能借些獨立完成產品的人。

當咱們須要作一個移動CMS的時候，咱們就會在不一樣的技術棧以前選擇，或是RequireJS + Backbone + jQuery + Mustache，又或者是 ReactJS + Backbone，固然也有多是AngularJS等等。咱們所須要作的是，從中選出一個最好的方案，而後實施之。

這也就意味着，咱們須要有更好的知識面，也會致使對於某些技術的不夠深刻。二者就是一個很好的對立面，在這兩之間很好地平衡可能就意味着平庸。有時也並不是如此，可是多數時間這這樣的。要麼成爲專家，要麼成爲全棧，要麼就平衡他們。

全棧工程師VS專家

人的大腦如同一間空空的閣樓，要有選擇地把一些傢俱裝進去。

柯南道爾說的話仍是頗有道理的。因爲這個閣樓的大小是有限的，假定他是一個書架。那麼全棧工程師的書架就會充滿各類各樣的技術棧從MySQL、SQLite、MongoDB、Redis等等各類各樣的書籍;而專家的書籍則是MySQL優化、MySQL重構、MySQL權威指南、DBMS等等的專業書籍合集。

若是他們都是一本書，那麼全棧工程師的書是一個索引。專家的書則更多的是內容自己。 因此，每一個人都會去選擇不一樣的存儲方式、不一樣的數據庫。

對於咱們大腦這個數據庫來時，平時咱們存儲的是Key-Value(ps: 咱們只有key，value是Google和書本)，對於專家來講，存儲的是Documents。在一樣的容量大小的狀況下，咱們能夠了解到更多的知識。以下圖所示，左邊的關係數據模型即爲全棧工程師，右邊則爲專家。

Key

曾經迷惑了好久: 爲何對於一些知識點，我須要去Google，而別人能夠獨立地完成的時候。我就意識到我更適合於互聯網企業，聽說在一些電信設備製造商裏是沒網的辦公環境。然而在多數的時候，這並不是一種劣勢。

咱們會更快地方式來解決問題，由於咱們有一些這方面的經驗。不足則是，有時候咱們沒有辦法深刻問題去分析

如何成爲全棧工程師

這是一個有趣的問題，在知乎也有這樣的討論。而我以爲，最重要的是好奇與創造。

• 創造

記得在上大學以前已經有一個明確的目標，儘量地作到能作到的程序——想到的都應該能作到。因而，順着這個目標構建了一個知識體系，又或者說是索引。

當咱們內心有一個想法的時候，我就開始從一個key中進行頭腦風暴，如以前作的地圖搜索。咱們要作的功能即是: 持久化GEO信息，在地圖上顯示座標。

1.首先會在頭腦中列出全部我用過的框架，選擇後臺框架:

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

排除事後就只剩下Django、Flask、NodeJS，接着由於Django內置Geo支持，果斷選擇了Django。

2.接着，對於持久化方案的選擇:

因爲Django內置ORM，因此這一步能夠輕輕鬆鬆地過去。不過，我選的是SQLite3，本地調試方便，還能夠將數據複製到服務器上。

3.而後，對於空間搜索的支持:

就這麼有了兩個搜索引擎和一個數據庫: ElasticSearch、Solr以及MongoDB。由於Django對於MongoDB支持的緣由，想到使用搜索引擎會更容易搜索到結果。接着找到了Haystack，看到Solr須要手動更新索引就選擇了ElastiSearch。

4.到了，移動開發:

要跨平臺支持天然是Cordova，用Hybird仍是Ionic好用。

5.實戰

這一步天然也不是問題，向來是以實戰出真知的。

在不斷創造地過程當中會學到更多的知識，有更多的方案能夠選擇。下一次，將會想着用不一樣的技術棧再實現一遍。有了以前的體系，再橫向深刻也是一個很好的突破點。如，咱們用Python構建一個原型，而後咱們用Java來實現。

• 好奇

與專家不一樣的是，全棧工程師更容易被新的技術吸引。至於，是好是壞我想你們都懂的。

當ReactJS出來的時候，就會試着去玩。

當Ionic還在測試版的時候，就會作一個個Demo。

而有意思的是，同咱們在《技術的本質》中看到的同樣，新的技術都是基於舊的技術產生的。沒有一種技術能夠無中生有。因此要學習一種新的技術必然不難，只是有時候會難以深刻。

全棧程序員進階

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

構架設計

在我打算試着寫一個名爲Echoes的CMS的時候，找到了書架上的幾本書:

《架構之美》
《面向模式的軟件架構》
《領域驅動設計》
《實現領域驅動設計》
《軟件框架設計的藝術》
發現書中說起到的一些模式彷佛已經很常見了，要理解起來已經變得很簡單，看上去那些更像是一個又一個的項目的縮影。

更主要的點還有:

架構師並非最好的程序員，可是知識面必定要廣。
只有有着更多的知識才能決定好方案，若是咱們只深刻一部分知識，那麼咱們沒法總作出正確地決定。因此，也必須也是一個好的成長方向。

成爲專家

我一直不認同木桶理論的一點是，咱們會被最低的木板限制。可是有一天咱們會被最高的那一塊限制到，畢竟咱們都會意識到咱們的短片，咱們會盡可能把全部的木板提到一樣的高度，以保證水的容量。可是，若是最高的那塊木板不是那麼高呢? 那麼，爲何不在一開始的時候，讓它儘量的高?

因而，我想說的是咱們須要在某一部分紅爲專家。當咱們在某一領域成爲專家，要在另一領域成爲專家，也是很容易的一件事。

當我向Senior程序員諮詢一些成長意見的時候(ps: 畢業不到一年)，那麼就是往專家發展。對於一個Java Web程序員來講，成長意見可能就是深刻Spring、探索Tomcat底層、深刻JVM。問題是，他們都寫得複雜，可是咱們又不能放棄這樣的成長機會。咱們還能作的事，從一個更簡單的語言中學會這些原理，再回頭去補充。

對應於Spring，會有Flask、Tornado;對應於Tomcat，咱們是否是能夠深刻Gunicorn;對應於JVM是否是也會有Python VM，不過仍是JVM的書比較多。等咱們在一個更簡單的層級上了解到這些，那麼對於一個臃腫的語言來講不會是難題。