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