为什么你应该尝试“全栈”

程序员看到"全栈"这个概念，大概会有两种反应

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 端的程序员并不总是错的，客户端这边希望所有数据给出来后不需要再加工，但往往按照客户端需要的结构給的话，有些查询可能要耗时一两秒。客户端如果不理解服务端的机制，一味以 “服务端就是給客户端服务的” 来要求，吵架就又难以避免了。

如果说技术人之间的争论是冷兵器战争的话，那如果碰到更外行的产品经理或者老板，那就要爆发核战争了。

“你就改个网页，十分钟能搞定吗？”

“效果怎么可能很难做，我给你做个！”

“明天上线，赶紧的！”

“我不管你技术上有什么难度，反正你就得给我实现出来！”

而这样的场景，无论是哪家公司，几乎都在不停上演。

尝试了解对方的技术

并不觉得全栈会使得你全面平庸，每种技术在做的时候都可以为其他的技术提供思路，而在你了解各种技术的前提下，深入其中的某个技术，时常能够带来对其他技术的反哺。相反，了解的技术如果非常狭隘，很可能才是限制自己潜能的原因。

尊重与和平

在团队沟通的时候，对对方技术的了解能减少非常多的沟通成本，并带来尊重和和平。

很少见大神在一起争论谁该来让步，相反往往都是初窥门径的人整天吵个没完，脾气一点就爆。

虽然很难讲整个行业的水平能很快有质的变化，但是我想如果产品需求能够详细的描述清楚，说清楚原因，技术人员之间能够在一起相互学习，耐心的探讨，设计师能够尊重技术纬度的事情，设计出更符合当下的原型，那一切就会往者好的方向发展，这一切就从了解对方的工作开始。