为什么你应该尝试全栈？
程序员看到“全栈”这个概念，大概会有两种反应：
- “卧槽，这个好，碉堡了”
- “你懂毛，全栈就是样样稀松”
以上两种反应其实都有失偏颇。即便只专注于一种技术，做得很糟糕的程序员也大有人在；而掌握全栈技术且样样都做得不错的程序员同样不少。更有甚者，存在一种“爆栈型”程序员，无论做什么技术都能精通。
全栈学徒的技能要求
全栈学徒至少要掌握以下几种技能：
- Web 前端开发：至少掌握一种前端框架。
- Server 后端开发：至少掌握一种后端框架。
- Server 运维：掌握 Linux Server 的搭建与维护。
- 客户端开发：iOS 和 Android 至少掌握一种。
- 数据库：掌握 SQL 和 NoSQL 数据库。
而获得“全栈”这个称谓，则应该至少能够独当一面，一个人完成一款产品的构建，并且真的经历过商业化运作，在实践中被自己的失误坑过无数次。由此可见，全栈的门槛还是挺高的，并不是说掌握以上五种技能就能称为全栈，至少要加个“学徒”来修饰一下。也正是因为太多学徒自诩全栈，才导致第二种反应如此普遍。
不过，本文的主题是“为什么你应该尝试全栈”，所以讨论的重点不在于要不要成为全栈，而是去尝试。
外行与内行的矛盾
过去几年里，我和不少团队成员交流过，发现绝大部分的团队矛盾源于以下几点：
- Server 端人员不懂客户端，设计出 API 后随意发表意见。
- 设计师不懂客户端，设计交互时随意发表意见。
- 客户端人员不懂 Server，对着 API 随意发表意见。
- 客户端人员不懂产品，对着需求随意发表意见。
- 产品经理不懂需求，对着团队随意发表意见。
除了最后的产品经理这种情况比较严重外，前四个矛盾还是有解决办法的。
程序员是一个具有“上帝模式”的职业，每天的工作就是创造，这也是这个职业看起来很酷的原因。但正因如此，程序员多少都会有些自负，自负的结果就是以自己有限的知识去揣测别人的工作该怎么做。
如果 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）。
我并不认为全栈会让人全面平庸，每种技术在学习和实践过程中都能为其他技术提供思路。在了解各种技术的前提下，深入钻研其中某一项技术，还能对其他技术产生反哺作用。相反，技术知识面过于狭隘，很可能会限制自己的潜能。
尊重与和平
在团队沟通中，了解对方的技术能大幅减少沟通成本，带来尊重与和平。
很少见到技术大神在一起争论谁该让步，相反，往往是初入行业的人整天争吵不休，脾气一点就着。
虽然很难说整个行业的水平能很快有质的提升，但我认为，如果产品需求能够详细清晰地描述并说明原因，技术人员之间相互学习、耐心探讨，设计师能够尊重技术层面的问题，设计出更符合实际情况的原型，那么一切都会朝着好的方向发展，而这一切要从了解对方的工作开始。