程序員看到全棧這個概念，大概會有兩種反應

1.臥槽，這個好，碉堡了

2.你懂毛，全棧就是樣樣稀松

以上兩種反應其實都有失偏頗，即使只做一種技術，做的很菜的多的是，而全棧但是樣樣都做的不錯的也不少，更別說這個世界還存在另外一種爆棧型的程序員，做什么什么精。

全棧學徒 至少要掌握以下幾種技能

Web 前端開發(fā)，至少掌握一種前端框架

Server 后端開發(fā)，至少掌握一種后端框架

Server 運維，掌握 Linux Server 的搭建與維護

客戶端開發(fā)，iOS 和 Android 至少掌握一種

數(shù)據庫，掌握 SQL 和 noSQL 數(shù)據庫

而獲得 全棧 這個稱謂則應該至少獨當一面的一個人完成一款產品的構建，并且真的經歷過商業(yè)化運作，被自己的 愚蠢 坑過無數(shù)次。

由此可見，全棧的門檻還是挺高的，并不是說掌握以上五種技能，就能稱為全棧，至少要加個學徒來修飾一下，也正是因為太多學徒自詡全棧，才導致第二種反應如此廣泛。

不過，這篇文章的題目是 —— 為什么你應該 嘗試 全棧，所以討論點并不在要不要做全棧，而是嘗試。

外行與內行

過去幾年里，我和不少團隊的人聊過，發(fā)現(xiàn)絕大部分的團隊矛盾都在于——

Server 端的不懂客戶端，設計出來個 API 后瞎 BB

設計師不懂客戶端，設計個交互瞎 BB

客戶端不懂 Server，對著 API 瞎 BB

客戶端不懂產品，對著需求瞎 BB

產品經理不懂需求，對著 Team 瞎 BB

除了***的產品經理應該被燒死以外，前四個矛盾都還是有救的。

程序員是一個上帝模式的職業(yè)，每天的工作就是創(chuàng)造，這也正是這個職業(yè)看起來很酷的原因。但是正因如此，程序員多少都會有些自負，自負的結果就是以自己有限的知識去揣測別人的工作該怎么做。

如果 Server 端不懂客戶端，那么很容易設計出來不符合客戶端機制的 API，以網頁的思維去理解客戶端，這時候好點的話做客戶端的耐心解釋，每個 API 耽誤一兩天的時間來磨合，不好的話就要吵架了。

但 Server 端并不總是錯的，客戶端希望所有數(shù)據給出來后不需要再加工，而往往按照客戶端需要的結構給的話，有些查詢可能要耗時一兩秒?？蛻舳巳绻焕斫夥斩说臋C制，一味以 “服務端就是給客戶端服務的” 來要求，就又要吵架了。

如果說技術人之間的爭論是冷兵器戰(zhàn)爭的話，那如果碰到更外行的產品經理或者老板，那就要爆發(fā)核戰(zhàn)爭了。

“你就改個網頁，十分鐘能搞定嗎？”

“效果怎么可能很難做，我給你做個”

“明天上線，趕緊的”

“我不管你技術上有什么難度，反正你就得給我實現(xiàn)出來”

而這樣的場景，無論是哪家公司，幾乎都在不停上演。

嘗試了解對方的技術

先聊聊我的技術軌跡吧，從初中開始使用 Linux，以 Ubuntu 作為自己主力系統(tǒng)，而后切換到 ArchLinux，再回到 Ubuntu，一直使用到大一，這幾年的 Linux 使用經驗奠定了 Server 架構的基礎，大一開始嘗試自己做一款產品。

那時候就琢磨，我應該先寫一個網頁版，然后再寫個客戶端。

所以從后端開始，我使用 Django 作為起步，不過很快我轉移到了 Rails 陣營，Rails 的敏捷開發(fā)極大的降低了開發(fā)成本，而其的約定習慣，也使得菜鳥能夠平安飛過很多危險區(qū)域。

開始寫網頁前端的時候，并不知道有前端框架這個東西，直到用 Rails 寫完了后才發(fā)現(xiàn)原來有東西叫 Ember.js，于是開始用 Ember.js 來重寫，一開始的理解還是如何用 Rails 來渲染前端，后來發(fā)現(xiàn)其實在引入了前端框架后 Rails 的角色已經變成了個 API Server 了。

于是由此開始從新的角度去考慮如何設計 Rails 的 API，閱讀了大量的 API 設計的資料，怎么樣設計前端才好用，怎么樣降低查詢時間，服務器緩存，redis，安全等等。

Rails 的自動化幫了不少忙，很多自己并不知道的地方它已經幫忙做好，而當你想了解的時候，又會發(fā)現(xiàn)其實現(xiàn)是如此精妙。更別說 Rails 對新技術的接受程度，使得你總是有新東西可以玩，CoffeeScript 和 Sass 最早就是 Rails 吸收作為自己框架的默認前端技術。。

隨后由 Ember.js 又切換到 Angular.js，用 Angular 重寫一遍，期間又接觸了前端工具 Grunt （前端的變化一日千里，現(xiàn)在用的東西已經不是這個了）

***到了 iOS 客戶端，此時 iOS 的界面實現(xiàn)又與網頁的 HTML 和 CSS 有著很多不同，也因此又花費了不少時間去理解 iOS 的 UI 概念，把思維從網頁轉換成 iOS 的界面開發(fā)思想。

數(shù)據庫也在這個期間從 MySQL 換成了 MongoDB，因為那幾年的潮流也正好是這個轉變。

這個過程里幸好是我一個人，所以沒人可以吵架，不然我想各個階段都是有很多值得爭吵的地方。

項目上線后，隨著運維的復雜程度逐漸提升，也因此接觸了 chef 和 Ansible 這種自動化運維方式，再往后 NewRelic 這類的監(jiān)控服務也上了，為了一個穩(wěn)定的開發(fā)環(huán)境，繼而使用了 Vagrant。

而這一切都只發(fā)生在一年的時間里，不過很有趣的事情是，很多時候我寫著 iOS 突然想明白了 HTML 和 CSS 的實現(xiàn)原理，做著 Rails 突然想出了更好的 iOS 架構方式，不同的技術之間觸類旁通的感覺在每天都發(fā)生著。

在后來的時間里，這段經歷使得我和不同的技術人溝通都非常輕松，因為去年 秒視 做濾鏡的原因，我開始研究起 openGL，在重拾了Blender 之后，很多以前似懂非懂的地方，實現(xiàn)突然變的像 Hello World 一樣簡單，因此也干脆玩起 Unity 來，在這一切的積累之后，Unity 的學習變的非常輕松，成為了我晚上的休閑項目，或許不久之后，你會看到一款我做的游戲（可能會是 RPG）。

我并不覺得全棧會使得你全面平庸，每種技術在做的時候都可以為其他的技術提供思路，而在你了解各種技術的前提下，深入其中的某個技術，時常能夠帶來對其他技術的反哺。相反，了解的技術如果非常狹隘，很可能才是限制自己潛能的原因。

尊重與和平

在團隊溝通的時候，對對方技術的了解能減少非常多的溝通成本，并帶來尊重和和平。

很少見大神在一起爭論誰該來讓步，相反往往都是初窺門徑的人整天吵個沒完，脾氣一點就爆。

雖然很難講整個行業(yè)的水平能很快有質的變化，但是我想如果產品需求能夠詳細的描述清楚，說清楚原因，技術人員之間能夠在一起相互學習，耐心的探討，設計師能夠尊重技術緯度的事情，設計出更符合當下的原型，那一切就會往者好的方向發(fā)展，這一切就從了解對方的工作開始。