全棧工程師的思考

文/黃峰達

在我把博客的標語修改了以后，當然只是一個某方面的測試。生活是一個有趣的循環，當我們試著往圍城外走的時候，我們又被拉到圍城里。

什么是全棧工程師

在現在這一個時代來說，不會有人掌握所有的編程語言、技能，以后應該會有，但是掌握這些全部技術的不是人類了。所以，其實我們需要的是懂得多種技術的，并能借些獨立完成產品的人。

當我們需要做一個移動 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 的書比較多。等我們在一個更簡單的層級上了解到這些，那么對于一個臃腫的語言來說不會是難題。

總結

我們總在成長，至于成長的方向是我們能決定的~~。