转载

我看全栈工程师

我看全栈工程师

  文/余晟

  “全栈工程师”是近几年流行的说法。按照一般人的理解,“全栈工程师”就是“包打天下”的工程师——从后端到前端,从设计到测试,从开发到运维,都能一肩挑。其实这样的概念早年也有,只是当时不叫这个名字,我还记得自己有个朋友说过:“创业,一定要找到无所不能的超级程序员”。

  十年前我刚刚工作的时候,这样的“超级程序员”非常稀罕,每每遇到都会让人膜拜。随着“全栈工程师”的流行,我见到的“全栈工程师”似乎越来越多了(甚至我自己有时候也会莫名其妙地被人称作“全栈工程师”)。这个现象很有点意思,到底是“全栈工程师”的绝对数量更多了,还是我见到的“全栈工程师”更多了?我仔细思考,觉得应该是“全栈工程师”的绝对数量更多了,这种增长的动力大概来自两个方面。

  第一个方面是软件开发的“工业化”,提高了“全栈工程师”能够把握的复杂度。

  “工业化”这个说法或许不太合适,但我也想不到更易懂的说法。经典的“工业化”指的是将越来越多的简单重复劳动交给机器,把人解放出来。软件行业虽然一直在推动“把越来越多的事情交给计算机去做”,但最近一二十年的速度是明显增加了的。越来越多的问题有了现成的类库和框架,越来越多的问题有了现成的解决方案。

  举我印象深刻的例子:十来年前 C10K 已经算难倒众人的大问题,现在哪怕是 C100K,也有现成的解决方案;三四年前 Android 的推送还很让人头痛,现在刚入门的小朋友也能可以轻松解决……

  结果,不但“软件开发的门槛越来越低”,“搭建出质量‘足够好’的软件产品”的难度也越来越低。或者更清楚一点说,软件的工业化提高了大家对复杂度的掌控能力:在了解了“软件要解决的是什么问题”以及“软件应该怎样解决这个问题”之后,剩下的实现工作已经被大大简化了。于是才可能出现能“包打天下”的全栈工程师。否则,倒回去三十年,在没有标准 GUI 库的 Dos 下开发程序,光是一个小小的动画效果就能要了工程师的命,更谈不上“全栈”了。

  第二个方面是开发节奏和竞争的加剧,沟通和协调成本的压力直接产生了对“全栈工程师”的需求。

  如今越来越多的人进入软件开发领域,软件越来越多地深入生活的各种场景,创业拿到风投的机会也越来越高。每时每刻、每个领域、每个问题,都有人在动脑筋,在设想更好的解决方案。而且,光有解决方案还不够,还必须迅速地实现出来,接受实践的检验。

  传统(经典)的软件开发模式很像工业时代的企业:众多职能通过磨合确定出最有效率的工作方式,并照此精密化运营。这种方式没有错,但只适合解决相对固定的问题。如果企业要面对的是激烈的竞争,多变的环境,这种方式很难跟上外部的节奏。

  软件开发也面临同样的问题。配齐产品、开发、测试并磨合完毕就不是简单的任务,要适应“小步快跑”、“先开火再瞄准”的节奏,配合起来更是难上加难(比如,产品人员看到一个不错的点子决定要借鉴,开发和测试却迟迟无法理解),难以在竞争中立足。

  相反,如果把所有的职能集中到一个“全栈工程师”身上,沟通和协调的成本就大大降低。因为产品、开发、测试都是一个人,所以产品人员要借鉴某个点子的决策,一定可以准确流转到开发和测试环节。同样,因为开发和运维都是一个人,也很难出现为了稳定、效率、安全等因素的权衡争得面红耳赤的局面。

  以上两个方面互相靠拢。软件行业的“工业化”提供了逻辑的可能,降低协调和沟通成本的考虑直接产生了迫切的需求,于是,“全栈工程师”应运而生了。

  可惜,许多人对“全栈工程师”的理解比较片面,有些公司费劲找来了“每种技术都会一点”的“全栈工程师”,却发现事与愿违,协调和沟通的成本不降反升。问题在哪里呢?

  我认为,原因还是复杂性。“全栈工程师”的“全栈”是有机的整体,他能定义、理解、把握自己面对的问题,并妥善选用合适的工具,搭建出复杂性可控的解决方案。有时候甚至需要“现学”一些知识来填补自己的“栈”。这种能力通常离不开长期的工作积累和思考,甚至是刻意的训练。所以很多的“全栈工程师”都比较谦虚,因为相比单一方面的工程师,他们更了解每个领域的修炼难度,清楚自己并没有那么多“绝学”,依靠的是学习能力和从整体把握复杂性的能力。

  相比之下,很多“什么都会一点”的人,反而很乐意自诩为“全栈工程师”。好几个朋友跟我反馈,“什么都懂一点,但其实既不扎实,也不能融汇贯通”的人到处都有,而且竟然“什么都敢干”,挖了大量的坑,还非常乐意自诩为“全栈工程师”。要我说,这样的人不但与“全栈”无缘,连“工程师”都算不上。

正文到此结束
Loading...