為什么你應(yīng)該嘗試全棧
程序員看到全棧這個概念，大概會有兩種反應(yīng)
1.臥槽，這個好，碉堡了
2.你懂毛，全棧就是樣樣稀松
以上兩種反應(yīng)其實(shí)都有失偏頗，即使只做一種技術(shù)，做的很菜的多的是，而全棧但是樣樣都做的不錯的也不少，更別說這個世界還存在另外一種爆棧型的程序員，做什么什么精。
全棧學(xué)徒 至少要掌握以下幾種技能
-
Web 前端開發(fā)，至少掌握一種前端框架
-
Server 后端開發(fā)，至少掌握一種后端框架
-
Server 運(yùn)維，掌握 Linux Server 的搭建與維護(hù)
-
客戶端開發(fā)，iOS 和 Android 至少掌握一種
-
數(shù)據(jù)庫，掌握 SQL 和 noSQL 數(shù)據(jù)庫
而獲得 全棧 這個稱謂則應(yīng)該至少獨(dú)當(dāng)一面的一個人完成一款產(chǎn)品的構(gòu)建，并且真的經(jīng)歷過商業(yè)化運(yùn)作，被自己的 愚蠢 坑過無數(shù)次。
由此可見，全棧的門檻還是挺高的，并不是說掌握以上五種技能，就能稱為全棧，至少要加個學(xué)徒來修飾一下，也正是因?yàn)樘鄬W(xué)徒自詡?cè)珬＃艑?dǎo)致第二種反應(yīng)如此廣泛。
不過，這篇文章的題目是 —— 為什么你應(yīng)該 嘗試 全棧，所以討論點(diǎn)并不在要不要做全棧，而是嘗試。
外行與內(nèi)行
過去幾年里，我和不少團(tuán)隊(duì)的人聊過，發(fā)現(xiàn)絕大部分的團(tuán)隊(duì)矛盾都在于——
-
Server 端的不懂客戶端，設(shè)計(jì)出來個 API 后瞎 BB
-
設(shè)計(jì)師不懂客戶端，設(shè)計(jì)個交互瞎 BB
-
客戶端不懂 Server，對著 API 瞎 BB
-
客戶端不懂產(chǎn)品，對著需求瞎 BB
-
產(chǎn)品經(jīng)理不懂需求，對著 Team 瞎 BB
除了***的產(chǎn)品經(jīng)理應(yīng)該被燒死以外，前四個矛盾都還是有救的。
程序員是一個上帝模式的職業(yè)，每天的工作就是創(chuàng)造，這也正是這個職業(yè)看起來很酷的原因。但是正因如此，程序員多少都會有些自負(fù)，自負(fù)的結(jié)果就是以自己有限的知識去揣測別人的工作該怎么做。
如果 Server 端不懂客戶端，那么很容易設(shè)計(jì)出來不符合客戶端機(jī)制的 API，以網(wǎng)頁的思維去理解客戶端，這時候好點(diǎn)的話做客戶端的耐心解釋，每個 API 耽誤一兩天的時間來磨合，不好的話就要吵架了。
但 Server 端并不總是錯的，客戶端希望所有數(shù)據(jù)給出來后不需要再加工，而往往按照客戶端需要的結(jié)構(gòu)給的話，有些查詢可能要耗時一兩秒。客戶端如果不理解服務(wù)端的機(jī)制，一味以 “服務(wù)端就是給客戶端服務(wù)的” 來要求，就又要吵架了。
如果說技術(shù)人之間的爭論是冷兵器戰(zhàn)爭的話，那如果碰到更外行的產(chǎn)品經(jīng)理或者老板，那就要爆發(fā)核戰(zhàn)爭了。
“你就改個網(wǎng)頁，十分鐘能搞定嗎？”
“效果怎么可能很難做，我給你做個”
“明天上線，趕緊的”
“我不管你技術(shù)上有什么難度，反正你就得給我實(shí)現(xiàn)出來”
而這樣的場景，無論是哪家公司，幾乎都在不停上演。
嘗試了解對方的技術(shù)
先聊聊我的技術(shù)軌跡吧，從初中開始使用 Linux，以 Ubuntu 作為自己主力系統(tǒng)，而后切換到 ArchLinux，再回到 Ubuntu，一直使用到大一，這幾年的 Linux 使用經(jīng)驗(yàn)奠定了 Server 架構(gòu)的基礎(chǔ)，大一開始嘗試自己做一款產(chǎn)品。
那時候就琢磨，我應(yīng)該先寫一個網(wǎng)頁版，然后再寫個客戶端。
所以從后端開始，我使用 Django 作為起步，不過很快我轉(zhuǎn)移到了 Rails 陣營，Rails 的敏捷開發(fā)極大的降低了開發(fā)成本，而其的約定習(xí)慣，也使得菜鳥能夠平安飛過很多危險區(qū)域。
開始寫網(wǎng)頁前端的時候，并不知道有前端框架這個東西，直到用 Rails 寫完了后才發(fā)現(xiàn)原來有東西叫 Ember.js，于是開始用 Ember.js 來重寫，一開始的理解還是如何用 Rails 來渲染前端，后來發(fā)現(xiàn)其實(shí)在引入了前端框架后 Rails 的角色已經(jīng)變成了個 API Server 了。
于是由此開始從新的角度去考慮如何設(shè)計(jì) Rails 的 API，閱讀了大量的 API 設(shè)計(jì)的資料，怎么樣設(shè)計(jì)前端才好用，怎么樣降低查詢時間，服務(wù)器緩存，redis，安全等等。
Rails 的自動化幫了不少忙，很多自己并不知道的地方它已經(jīng)幫忙做好，而當(dāng)你想了解的時候，又會發(fā)現(xiàn)其實(shí)現(xiàn)是如此精妙。更別說 Rails 對新技術(shù)的接受程度，使得你總是有新東西可以玩，CoffeeScript 和 Sass 最早就是 Rails 吸收作為自己框架的默認(rèn)前端技術(shù)。。
隨后由 Ember.js 又切換到 Angular.js，用 Angular 重寫一遍，期間又接觸了前端工具 Grunt （前端的變化一日千里，現(xiàn)在用的東西已經(jīng)不是這個了）
***到了 iOS 客戶端，此時 iOS 的界面實(shí)現(xiàn)又與網(wǎng)頁的 HTML 和 CSS 有著很多不同，也因此又花費(fèi)了不少時間去理解 iOS 的 UI 概念，把思維從網(wǎng)頁轉(zhuǎn)換成 iOS 的界面開發(fā)思想。
數(shù)據(jù)庫也在這個期間從 MySQL 換成了 MongoDB，因?yàn)槟菐啄甑某绷饕舱檬沁@個轉(zhuǎn)變。
這個過程里幸好是我一個人，所以沒人可以吵架，不然我想各個階段都是有很多值得爭吵的地方。
項(xiàng)目上線后，隨著運(yùn)維的復(fù)雜程度逐漸提升，也因此接觸了 chef 和 Ansible 這種自動化運(yùn)維方式，再往后 NewRelic 這類的監(jiān)控服務(wù)也上了，為了一個穩(wěn)定的開發(fā)環(huán)境，繼而使用了 Vagrant。
而這一切都只發(fā)生在一年的時間里，不過很有趣的事情是，很多時候我寫著 iOS 突然想明白了 HTML 和 CSS 的實(shí)現(xiàn)原理，做著 Rails 突然想出了更好的 iOS 架構(gòu)方式，不同的技術(shù)之間觸類旁通的感覺在每天都發(fā)生著。
在后來的時間里，這段經(jīng)歷使得我和不同的技術(shù)人溝通都非常輕松，因?yàn)槿ツ?秒視 做濾鏡的原因，我開始研究起 openGL，在重拾了Blender 之后，很多以前似懂非懂的地方，實(shí)現(xiàn)突然變的像 Hello World 一樣簡單，因此也干脆玩起 Unity 來，在這一切的積累之后，Unity 的學(xué)習(xí)變的非常輕松，成為了我晚上的休閑項(xiàng)目，或許不久之后，你會看到一款我做的游戲（可能會是 RPG）。
我并不覺得全棧會使得你全面平庸，每種技術(shù)在做的時候都可以為其他的技術(shù)提供思路，而在你了解各種技術(shù)的前提下，深入其中的某個技術(shù)，時常能夠帶來對其他技術(shù)的反哺。相反，了解的技術(shù)如果非常狹隘，很可能才是限制自己潛能的原因。
尊重與和平
在團(tuán)隊(duì)溝通的時候，對對方技術(shù)的了解能減少非常多的溝通成本，并帶來尊重和和平。
很少見大神在一起爭論誰該來讓步，相反往往都是初窺門徑的人整天吵個沒完，脾氣一點(diǎn)就爆。
雖然很難講整個行業(yè)的水平能很快有質(zhì)的變化，但是我想如果產(chǎn)品需求能夠詳細(xì)的描述清楚，說清楚原因，技術(shù)人員之間能夠在一起相互學(xué)習(xí)，耐心的探討，設(shè)計(jì)師能夠尊重技術(shù)緯度的事情，設(shè)計(jì)出更符合當(dāng)下的原型，那一切就會往者好的方向發(fā)展，這一切就從了解對方的工作開始。
