1. 卧槽，这个好，碉堡了
2. 你懂毛，全栈即是样样稀松
以上两种反响本来都有失偏颇。由于即便只学一门技能，水平很菜的人也多的是，而全栈工程师傍边样样都做，而样样都做得不错的也不少。更甭说这个国际还存在别的一种爆栈型的程序员，做啥，啥都精。
从我的自个实习动身，全栈学徒最少要把握以下几种技能：
Web 前端开发，最少把握一种前端构造;
Server 后端开发，最少把握一种后端构造;
Server 运维，把握 Linux Server 的建立与保护;
客户端开发，iOS 和 Android 最少把握一种;
数据库，把握 SQL 和 noSQL 数据库。
而取得全栈这个称谓则应当最少独立自主的一自个完结一款商品的构建，而且真的阅历过商业化运作，以及，被自个的愚笨坑过无数次。
由此可见，全栈的门槛仍是挺高的，并不是说把握以上五种技能，就能称为全栈，最少要加个学徒来润饰一下，也恰是由于太多学徒自称全栈，才令旁人觉得“全栈”即是“样样稀松”的近义词。
不过，这篇文章的标题是 —— 为啥你应当测验全栈，所以我想评论的并不在要不要做全栈，而是测验。
外行与熟行
曩昔几年里，我和不少团队聊过，发现绝大部分的团队对立都在于——
Server 端的不理解客户端，规划出来个 API 后瞎 BB;
规划师不理解客户端，规划个交互瞎 BB;
客户端不理解 Server，对着 API 瞎 BB;
客户端不理解商品，对着需要瞎 BB;
商品司理不理解需要，对着 Team 瞎 BB。
除了最终的商品司理应当被烧死以外，前四个对立都仍是有救的。
程序员是一个天主形式的作业，天天的作业即是发明，所以这个作业看起来很帅。可是正由于如此，程序员多少都会有些自傲，自傲的成果即是以自个有限的常识去推测他人的作业该怎么做。
假如 Server 端不理解客户端，那么很简略规划出来不契合客户端机制的 API。在这时分，做客户端那儿的程序员耐性解说，每个 API 耽搁一两天的时刻来磨合还可以，欠好的话就要吵架了。
但 Server 端的程序员并不老是错的，客户端这边期望一切数据给出来后不需要再加工，但通常依照客户端需要的构造給的话，有些查询也许要耗时一两秒。客户端假如不了解效劳端的机制，一味以 “效劳端即是給客户端效劳的” 来请求，吵架就又难以避免了。
假如说技能人之间的争辩是冷兵器战役的话，那假如碰到更外行的商品司理或许老板，那就要迸发核战役了。
“你就改个页面，十分钟能搞定吗?”
“作用怎么也许很难做，我给你做个!”
“明日上线，赶忙的!”
“我不论你技能上有啥难度，横竖你就得给我完成出来!”
而这么的场景，无论是哪家公司，简直都在不断演出。
测验了解对方的技能
先聊聊我的技能生长轨道吧。
我从初中开端运用 Linux，主力体系是 Ubuntu，然后切换到 ArchLinux，然后再回到 Ubuntu，一向运用到大一，这几年的 Linux 运用阅历奠定了 Server 架构的根底，大一开端测验自个做一款商品。
那时分就揣摩，我应当先写一个页面版，然后再写个客户端。
所以从后端开端，我运用 Django 作为起步，不过很快我搬运到了 Rails 阵营，Rails 的灵敏开发极大的下降了开发本钱，而其的约好习气，也使得菜鸟可以安全飞过许多风险区域。
开端写页面前端的时分，并不知道有前端构造这个东西，直到用 Rails 写完了后才发现本来有东西叫 Ember.js，所以开端用 Ember.js 来重写，一开端的了解仍是怎么用 Rails 来烘托前端，后来发现本来在引入了前端构造后 Rails 的人物现已变成了个 API Server 了。
所以由此开端重新的视点去思考怎么规划 Rails 的 API，阅读了许多的 API 规划的材料，如何规划前端才好用，如何下降查询时刻，效劳器缓存，redis，安全等等。
Rails 的自动化帮了不少忙，许多自个并不知道的当地它现已帮助做好，而当你想了解的时分，又会发现本来现是如此精妙。更甭说 Rails 对新技能的承受程度，使得你老是有新东西可以玩，CoffeeScript 和 Sass 最早即是 Rails 吸收作为自个构造的默许前端技能。
随后由 Ember.js 又切换到 Angular.js，用 Angular 重写一遍，时期又触摸了前端东西 Grunt (前端的改变日新月异，现在用的东西现已不是这个了)。
最终我开端开发 iOS 客户端，此刻 iOS 的界面完成又与页面的 HTML 和 CSS 有着许多不相同，所以我又花费了不少时刻去了解 iOS 的 UI 概念，把思维从页面转换成 iOS 的界面开发思维。
数据库也在这个时期从 MySQL 换成了 MongoDB，由于那几年的潮流也正好是这个改变。
在这个技能实操的进程里幸好是我一自个，所以没人可以吵架，否则我想各个期间都是有许多值得争持的当地。
在我所开发的项目上线后，跟着运维的杂乱程度逐步提高，也因而触摸了 chef 和 Ansible 这种自动化运维方法，再往后 NewRelic 这类的监控效劳也上了，而我为了一个安稳的开发环境，继而运用了 Vagrant。
这一切都只发生在一年的时刻里。
风趣的是，许多时分我写着 iOS 客户端时，俄然想理解了 HTML 和 CSS 的完成原理，做着 Rails 的时分，俄然想出了十分好的 iOS 架构方法，不相同的技能之间举一反三的感受在天天都发生着。
在后来的时刻里，这段阅历使得我和不相同的技能人交流都十分轻松，由于上一年秒视做滤镜的因素，我开端研讨起 openGL，在重拾了 Blender之 后，许多曾经似懂非懂的当地，完成俄然变的像 Hello World 相同简略，因而也爽性玩起 Unity 来，在这一切的堆集以后，Unity 的学习变的十分轻松，成为了我黑夜的休闲项目，或许不久以后，你会看到一款我做的游戏(也许会是 RPG)。
我并不觉得全栈会使得你全部平凡，每种技能在做的时分都可以为别的的技能供给思路，而在你了解各种技能的前提下，深化其间的某个技能，经常可以带来对别的技能的反哺。相反，了解的技能假如十分狭窄，很也许才是约束自个潜能的因素。
尊敬与平和
在团队交流的时分，对对方技能的了解能削减十分多的交流本钱，并带来尊敬平和和。
很少见大神在一起争辩谁该来退让，相反通常都是初窥门径的人成天吵个没完，脾气一点就爆。
尽管很难讲全部职业的水平能很快有质的改变，可是我想假如商品需要可以具体的描绘明白，说明白因素，技能人员之间可以在一起彼此学习，耐性的讨论，规划师可以尊敬技能纬度的作业，规划出更契合当下的原型，那一切就会往者好的方向开展，这一切就从了解对方的作业开端。
