程序员看到全栈这个概念大概会有两种反应1.靠，这个不错，一鸣惊人2.毛毛你懂的，全栈算不了什么。以上两种反应，其实都是有失偏颇的。哪怕只做一种技术，做的菜也不少，全栈的什么都做的也不少，更何况这个世界还有另一种爆栈。一个好的程序员，该怎么做。全栈学徒必须至少掌握以下技能Web前端开发，至少一种前端框架Server后端开发，至少一种后端框架Server运维，LinuxServer搭建与维护Client开发，iOS和Android掌握至少一种数据库，掌握SQL和noSQL数据库才能获得全栈的称号，至少需要一个人完成一个产品的搭建，真正体验过商业化运营，并且已经被自己的愚蠢愚弄了无数次。可见，全栈的门槛还是挺高的。并不是说掌握了以上五项技能就可以称为全栈。至少要加徒弟修改一下。这就是为什么第二种反应如此普遍的原因。不过这篇文章的标题是——whyyoushouldtryfullstack，所以讨论的重点不是要不要做fullstack，而是去试试。外行和高手这几年跟很多团队成员交流，发现大部分团队的矛盾在于服务端不懂客户端，设计完一个API，盲BB设计师不理解了解客户。设计一个不懂Server的交互式盲BB客户端，不懂API的盲BB客户端，不懂需求的产品经理，不懂Teams的盲BB，前四个矛盾还是可以挽救的。程序员是一个神模式的职业，每天的工作就是创造，这也是这个职业看起来很酷的原因。但也正因为如此，程序员或多或少都有些自负，而自负的结果就是揣测自己有限的知识如何去做别人的工作。如果服务端不理解客户端，很容易设计出不符合客户端机制的API，用网页的思维去理解客户端。如果这时候比较好，还不如给客户端耐心解释一下，每个API都会延迟一两天。过来磨合一下，不好的话会吵架的。但服务器端并不总是错误的。客户希望所有数据发出后都不需要处理。但是，如果按照客户端要求的结构给出，有些查询可能需要一两秒。如果客户端不了解服务器的机制，一味的问“服务器是给客户端用的”，又会吵起来。如果说技术人之间的争论是冷兵器战，那么如果遇到比较外行的产品经理或者老板，那么核战就会爆发。“你换个网页，十分钟能搞定吗？”“效果怎么难做，我给你做一个”“明天上线，快点”“我不管你技术难不难，你要给我实现”等等这样的场景，不不管是哪家公司，几乎都是在上演，尽量了解对方的技术，先说说我的技术轨迹吧，初中开始用linux，主要用ubuntu，后来转archlinux，然后回到Ubuntu，一直用到大一，这几年Linux的使用心得在打下Server架构基础后，大一尝试自己做一个产品，当时想，应该是先写web版，再写客户端。所以从后端开始，一开始用的是Django，但很快就转到了Rails阵营。Rails的敏捷开发大大降低了开发成本，而且它的约定俗成也让菜鸟安全的飞过重重险阻地区。刚开始写网页前端的时候，并不知道有前端框架这种东西。直到用Rails写完才发现有Ember.js这个东西，于是开始用Ember.js重写。一开始我的理解还停留在如何使用Rails来渲染前端，后来发现引入前端框架后Rails的角色变成了一个APIServer。于是开始思考如何从新的角度设计RailsAPI，看了很多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等监控服务。为了稳定的开发环境，那就用GotVagrant吧。而这一切只发生在一年之内，但有趣的是，很多时候我在写iOS的时候突然想通了HTML和CSS怎么实现，而在做Rails的时候突然想出了一个更好的iOS建筑学，不同技术之间类比的感觉每天都在发生。在后来的时间里，这段经历让我很容易和不同的技术人员交流。因为去年用妙视做滤镜的原因，开始研究openGL。重拾Blender后，很多以前不明白的地方，实现一下子变得和HelloWorld一样简单，于是干脆开始玩Unity了。经过这些积累，Unity的学习变得非常轻松，成了我晚上的休闲项目。也许在不久的将来，你会看到我做的一款游戏（可能是RPG）。我不认为全栈会让你变得平庸。每种技术在你做的时候都可以为其他技术提供思路。在你了解各种技术的前提下，深入某一种技术往往能给你带来对其他技术的反馈。相反，如果你所了解的技术非常狭窄，很可能是限制你潜力的原因。尊重与和平在团队沟通时，了解对方的技术可以减少很多沟通成本，带来尊重与和平。很少看到大师们争论谁应该让步。反倒是见惯了招数的人，整天吵个不停，稍有脾气就会大发雷霆。虽然很难说整个行业的水平能迅速发生质的变化，但我认为如果能把产品需求描述的详细，并把原因说清楚，技术人员可以互相学习，耐心讨论，设计师也可以可以尊重技术纬度的事情，设计一个更符合现状的原型，然后一切都会往更好的方向发展。这一切都始于了解对方的工作。
