去年在参加QCon时，就明显感受到各个创业者都是『通吃』型，身怀百技。同时，在招聘或者寻找合作伙伴时，也个个都是能手。全栈工程师，基本要求。
各公司也都在努力寻找全栈工程师，打造特种兵团队。从而减少沟通，产品快速迭代。但对全栈工程师的理解也是五花八门。
前几天在微信看到“余晟以为”的《我看全栈工程师》，我比较赞同他的观念，也转载下。
以下为他的原文
「全栈工程师」是近几年流行的说法。按照一般人的理解，「全栈工程师」就是『包打天下』的工程师——从后端到前端，从设计到测试，从开发到运维，都能一肩挑。其实这样的概念早年也有，只是当时不叫这个名字，我还记得自己有个朋友说过：“创业，一定要找到无所不能的超级程序员”。
十年前我刚刚工作的时候，这样的『超级程序员』非常稀罕，每每遇到都会让人膜拜。随着「全栈工程师」的流行，我见到的「全栈工程师」似乎越来越多了（甚至我自己有时候也会莫名其妙地被人称作「全栈工程师」）。这个现象很有点意思，到底是「全栈工程师」的绝对数量更多了，还是我见到的「全栈工程师」更多了？我仔细思考，觉得应该是「全栈工程师」的绝对数量更多了，这种增长的动力大概来自两个方面。
第一个方面是软件开发的“工业化”，提高了「全栈工程师」能够把握的复杂度。
「工业化」这个说法或许不太合适，但我也想不到更易懂的说法。经典的「工业化」指的是将越来越多的简单重复劳动交给机器，把人解放出来。软件行业虽然一直在推动“把越来越多的事情交给计算机去做”，但最近一二十年的速度是明显增加了的。越来越多的问题有了现成的类库和框架，越来越多的问题有了现成的解决方案。
举我印象深刻的例子：十来年前C10K已经算难倒众人的大问题，现在哪怕是C100K，也有现成的解决方案；三四年前Android的推送还很让人头痛，现在刚入门的小朋友也能可以轻松解决……
结果，不但「软件开发的门槛越来越低」，「搭建出质量‘足够好’的软件产品」的难度也越来越低。或者更清楚一点说，软件的工业化提高了大家对复杂度的掌控能力：在了解了『软件要解决的是什么问题』以及『软件应该怎样解决这个问题』之后，剩下的实现工作已经被大大简化了。于是才可能出现能『包打天下』的全栈工程师。否则，倒回去三十年，在没有标准GUI库的Dos下开发程序，光是一个小小的动画效果就能要了工程师的命，更谈不上『全栈』了。
第二个方面是开发节奏和竞争的加剧，沟通和协调成本的压力直接产生了对「全栈工程师」的需求。
如今越来越多的人进入软件开发领域，软件越来越多地深入生活的各种场景，创业拿到风投的机会也越来越高。每时每刻、每个领域、每个问题，都有人在动脑筋，在设想更好的解决方案。而且，光有解决方案还不够，还必须迅速地实现出来，接受实践的检验。
传统（经典）的软件开发模式很像工业时代的企业：众多职能通过磨合确定出最有效率的工作方式，并照此精密化运营。这种方式没有错，但只适合解决相对固定的问题。如果企业要面对的是激烈的竞争，多变的环境，这种方式很难跟上外部的节奏。
软件开发也面临同样的问题。配齐产品、开发、测试并磨合完毕就不是简单的任务，要适应「小步快跑」、「先开火再瞄准」的节奏，配合起来更是难上加难（比如，产品人员看到一个不错的点子决定要借鉴，开发和测试却迟迟无法理解），难以在竞争中立足。
相反，如果把所有的职能集中到一个「全栈工程师」身上，沟通和协调的成本就大大降低。因为产品、开发、测试都是一个人，所以产品人员要借鉴某个点子的决策，一定可以准确流转到开发和测试环节。同样，因为开发和运维都是一个人，也很难出现为了稳定、效率、安全等因素的权衡争得面红耳赤的局面。
以上两个方面互相靠拢。软件行业的「工业化」提供了逻辑的可能，降低协调和沟通成本的考虑直接产生了迫切的需求，于是，「全栈工程师」应运而生了。
可惜，许多人对「全栈工程师」的理解比较片面，有些公司费劲找来了“每种技术都会一点”的「全栈工程师」，却发现事与愿违，协调和沟通的成本不降反升。问题在哪里呢？
我认为，原因还是复杂性。「全栈工程师」的“全栈”是有机的整体，他能定义、理解、把握自己面对的问题，并妥善选用合适的工具，搭建出复杂性可控的解决方案。有时候甚至需要“现学”一些知识来填补自己的“栈”。这种能力通常离不开长期的工作积累和思考，甚至是刻意的训练。所以很多的「全栈工程师」都比较谦虚，因为相比单一方面的工程师，他们更了解每个领域的修炼难度，清楚自己并没有那么多“绝学”，依靠的是学习能力和从整体把握复杂性的能力。
相比之下，很多「什么都会一点」的人，反而很乐意自诩为「全栈工程师」。好几个朋友跟我反馈，『什么都懂一点，但其实既不扎实，也不能融汇贯通』的人到处都有，而且竟然「什么都敢干」，挖了大量的坑，还非常乐意自诩为「全栈工程师」。要我说，这样的人不但与「全栈」无缘，连「工程师」都算不上。
