为何你应该尝试“全栈”

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

1. 卧槽，这个好，碉堡了

2. 你懂毛，全栈就是样样稀松

以上两种反应其实都有失偏颇。由于即便只学一门技术，水平很菜的人也多的是，而全栈工程师当中样样都作，而样样都作得不错的也很多。更别说这个世界还存在另一种爆栈型的程序员，作什么，什么都精。

从个人我的实践出发，全栈学徒至少要掌握如下几种技能：

1. Web 前端开发，至少掌握一种前端框架；

2. Server 后端开发，至少掌握一种后端框架；

3. Server 运维，掌握 Linux Server 的搭建与维护；

4. 客户端开发，iOS 和 Android 至少掌握一种；

5. 数据库，掌握 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）。

我并不以为全栈会使得你全面平庸，每种技术在作的时候均可觉得其余的技术提供思路，而在你了解各类技术的前提下，深刻其中的某个技术，时常可以带来对其余技术的反哺。相反，了解的技术若是很是狭隘，极可能才是限制本身潜能的缘由。

尊重与和平

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

不多见大神在一块儿争论谁该来让步，相反每每都是初窥门径的人成天吵个没完，脾气一点就爆。

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

来源：http://www.ifanr.com/551905