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