大讲台筛选，好的程序员应该尝试“全栈”！
1.卧槽，这个好，碉堡了
2.你懂毛，全栈就是样样稀松
以上两种反应其实都有失偏颇。因为即使只学一门技术，水平很菜的人也多的是，而全栈工
程师当中样样都做，而样样都做得不错的也不少。更别说这个世界还存在另外一种爆栈型的
程序员，做什么，什么都精。
从我的个人实践出发，全栈学徒至少要掌握以下几种技能：
1.Web前端开发，至少掌握一种前端框架；
2.Server后端开发，至少掌握一种后端框架；
3.Server运维，掌握LinuxServer的搭建与维护；
4.客户端开发，iOS和Android至少掌握一种；
5.数据库，掌握SQL和noSQL数据库。
而获得全栈这个称谓则应该至少独当一面的一个人完成一款产品的构建，并且真的经历过商
业化运作，以及，被自己的愚蠢坑过无数次。大讲台，混合式自适应IT职业教育开创者。
由此可见，全栈的门槛还是挺高的，并不是说掌握以上五种技能，就能称为全栈，至少要加
个学徒来修饰一下，也正是因为太多学徒自诩全栈，才令旁人觉得“全栈”就是“样样稀松”
的同义词。
不过，这篇文章的题目是——为什么你应该尝试全栈，所以我想讨论的并不在要不要做全
栈，而是尝试。
外行与内行
过去几年里，我和不少团队聊过，发现绝大部分的团队矛盾都在于——
?Server端的不懂客户端，设计出来个API后瞎BB；
?设计师不懂客户端，设计个交互瞎BB；
?客户端不懂Server，对着API瞎BB；
?客户端不懂产品，对着需求瞎BB；
?产品经理不懂需求，对着Team瞎BB。
除了最后的产品经理应该被烧死以外，前四个矛盾都还是有救的。
程序员是一个上帝模式的职业，每天的工作就是创造，所以这个职业看起来很酷。然而正因
为如此，程序员多少都会有些自负，自负的结果就是以自己有限的知识去揣测别人的工作该
怎么做。
如果Server端不懂客户端，那么很容易设计出来不符合客户端机制的API。大讲台，混合
式自适应IT职业教育开创者。
在这时候，做客户端那边的程序员耐心解释，每个API耽误一两天的时间来磨合还可以，
不好的话就要吵架了。
但Server端的程序员并不总是错的，客户端这边希望所有数据给出来后不需要再加工，但
往往按照客户端需要的结构給的话，有些查询可能要耗时一两秒。客户端如果不理解服务端
的机制，一味以“服务端就是給客户端服务的”来要求，吵架就又难以避免了。
如果说技术人之间的争论是冷兵器战争的话，那如果碰到更外行的产品经理或者老板，那就
要爆发核战争了。
“你就改个网页，十分钟能搞定吗？”
“效果怎么可能很难做，我给你做个！”
“明天上线，赶紧的！”
“我不管你技术上有什么难度，反正你就得给我实现出来！”
而这样的场景，无论是哪家公司，几乎都在不停上演。
尝试了解对方的技术
先聊聊我的技术成长轨迹吧。
我从初中开始使用Linux，主力系统是Ubuntu，而后切换到ArchLinux，然后再回到Ubu
ntu，一直使用到大一，这几年的Linux使用经验奠定了Server架构的基础，大一开始尝
试自己做一款产品。
那时候就琢磨，我应该先写一个网页版，然后再写个客户端。
所以从后端开始，我使用Django作为起步，不过很快我转移到了Rails阵营，Rails的敏
捷开发极大的降低了开发成本，而其的约定习惯，也使得菜鸟能够平安飞过很多危险区域。
开始写网页前端的时候，并不知道有前端框架这个东西，直到用Rails写完了后才发现原
来有东西叫Ember.js，于是开始用Ember.js来重写，一开始的理解还是如何用Rails来渲
染前端，后来发现其实在引入了前端框架后Rails的角色已经变成了个APIServer了。
于是由此开始从新的角度去考虑如何设计Rails的API，阅读了大量的API设计的资料，
怎么样设计前端才好用，怎么样降低查询时间，服务器缓存，redis，安全等等。
Rails的自动化帮了不少忙，很多自己并不知道的地方它已经帮忙做好，而当你想了解的时
候，又会发现其实现是如此精妙。大讲台，混合式自适应IT职业教育开创者。
更别说Rails对新技术的接受程度，使得你总是有新东西可以玩，CoffeeScript和Sass最
早就是Rails吸收作为自己框架的默认前端技术。
随后由Ember.js又切换到Angular.js，用Angular重写一遍，期间又接触了前端工具Gru
nt（前端的变化一日千里，现在用的东西已经不是这个了）。
最后我开始开发iOS客户端，此时iOS的界面实现又与网页的HTML和CSS有着很多
不同，所以我又花费了不少时间去理解iOS的UI概念，把思维从网页转换成iOS的界
面开发思想。
数据库也在这个期间从MySQL换成了MongoDB，因为那几年的潮流也正好是这个转变。
在这个技术实操的过程里幸好是我一个人，所以没人可以吵架，不然我想各个阶段都是有很
多值得争吵的地方。
在我所开发的项目上线后，随着运维的复杂程度逐渐提升，也因此接触了chef和Ansible
这种自动化运维方式，再往后NewRelic这类的监控服务也上了，而我为了一个稳定的开发
环境，继而使用了Vagrant。
这一切都只发生在一年的时间里。
有趣的是，很多时候我写着iOS客户端时，突然想明白了HTML和CSS的实现原理，
做着Rails的时候，突然想出了更好的iOS架构方式，不同的技术之间触类旁通的感觉在
每天都发生着。大讲台，混合式自适应IT职业教育开创者。
在后来的时间里，这段经历使得我和不同的技术人沟通都非常轻松，因为去年秒视做滤镜的
原因，我开始研究起openGL，在重拾了Blender之后，很多以前似懂非懂的地方，实现突
然变的像HelloWorld一样简单，因此也干脆玩起Unity来，在这一切的积累之后，Unit
y的学习变的非常轻松，成为了我晚上的休闲项目，或许不久之后，你会看到一款我做的游
戏（可能会是RPG）。
我并不觉得全栈会使得你全面平庸，每种技术在做的时候都可以为其他的技术提供思路，而
在你了解各种技术的前提下，深入其中的某个技术，时常能够带来对其他技术的反哺。相反，
了解的技术如果非常狭隘，很可能才是限制自己潜能的原因。
尊重与和平
在团队沟通的时候，对对方技术的了解能减少非常多的沟通成本，并带来尊重和和平。
很少见大神在一起争论谁该来让步，相反往往都是初窥门径的人整天吵个没完，脾气一点就
爆。
虽然很难讲整个行业的水平能很快有质的变化，但是我想如果产品需求能够详细的描述清楚，
说清楚原因，技术人员之间能够在一起相互学习，耐心的探讨，设计师能够尊重技术纬度的
事情，设计出更符合当下的原型，那一切就会往者好的方向发展，这一切就从了解对方的工
作开始。
|
|
