在我把博客的標語修改了以後,當然只是一個某方面的測試。生活是一個有趣的循環,當我們試着往圍城外走的時候,我們又被拉到圍城裏。
##什麼是全棧工程師
在現在這一個時代來說,不會有人掌握所有的編程語言、技能,以後應該會有,但是掌握這些全部技術的不是人類了。所以,其實我們需要的是懂得多種技術的,並能借些獨立完成產品的人。
當我們需要做一個移動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的書比較多。等我們在一個更簡單的層級上瞭解到這些,那麼對於一個臃腫的語言來說不會是難題。
##總結
我們總在成長,至於成長的方向是我們能決定的~~。
###其他
全棧程序員成長路線可以參照: Web Developer路線圖
QQ交流羣: 321689806
微博: @phodal