我为什么反对提“全栈工程师

我为什么反对提“全栈工程师”？

肖文峰 · 1 年前

最近参加一个技术社区活动，在讨论到“CTO的技术深度和广度哪个更重要”的话题时，我想起社区里面常常提到的“全栈工程师”的事情，于是表达了一些观点。临场未必能够清晰表达，所以下笔，希望能够引起一些讨论，避免年轻工程师误入歧途。

长期以来，社区就有人在提“全栈工程师”，还有一些公司直接挂出名为“全栈工程师”的招聘职位。那什么是全栈工程师？

百度百科的解释是：全栈工程师，英文叫Full Stack Developer，是指掌握多种技能，并能利用多种技能独立完成产品的人。说白了就是啥都懂的人，左青龙右白虎老牛在腰间，人挡杀人佛挡杀佛。想想，一个项目从前到后要包含多少技术？就拿TalkingData来说，就至少有H5、JavaScript、CSS、Java、Kafka、MongoDB、Redis、MySQL/MariaDB、Vertica、Hadoop、Spark、Tychron等等，这些研发目前需要数据可视化团队、计算平台团队、存储平台团队、数据挖掘团队和运维团队来共同完成。要是出现这么一个全能王，把活一揽子全部接下来，那要省掉多少沟通代价和薪资成本？——这简直就是救世主！

想到这里，我顿觉惭愧，十几年的技术算是白搞了，要是刚毕业即以此为目标，每个月学一门，学完一门换一门，那用不了两年就能转职“全栈工程师”这个终极职业，站上技术巅峰，俯瞰芸芸众生——是不是有一种游戏开挂的快感？想想做个架构师都需要四五年的辛苦积累，现在能两三年速成，岂不是很爽？

终于，在这样自我催眠，加上一些舆论的刻意引导下，大批有志青年开始走上全栈工程师的自我修炼之路。没有多少人愿意脚踏实地积累自己的技术经验，或者潜心去研究开源技术的底层代码，或者做更深入的性能对比分析。很多人闪电般的在不同公司之间跳来跳去，走马观花，狂热浮躁。

这几年，因为大数据需求的不断成熟和数据业务的持续发展，TalkingData研发团队一直保持高密度的招聘，我们对这个现象的感觉是比较明显的。因为我们在面试中越来越多的发现，年轻人的简历写得愈发琳琅满目，这也“精通”，那也“擅长”，数量不等的“多年经验”或“长期从事”……恨不得2年工作经验比干10年的简历还要长，几乎称得上当代常用技术巡展。不要太强！只看简历就想赶紧招进来，再开掉现在这些“尸位素餐”的非全栈员工，世界肯定清净了吧？

但是情况真的是这么好吗？

在面试中，我们会通过问答，检验候选人在技术上思考的深度、理解能力、学习能力和解决问题的能力。所以研发人员面试一般会遵循以下流程：

1. 介绍一下背景和职业经历。

2. 选择一个你最熟悉或擅长的项目，详细描述一下整体架构和你做的工作。

3. 讨论一下你遇到的挑战以及怎么去解决的。

4. 然后从这一步开始，我们就会不断地挑战，不断追问“为什么”，直到通关或者回答不出来为止。

在这个流程中，每一步都有大批候选人失败，比较典型的失败原因包括：

1. 跳槽频繁

最常见的理由是“我想学习新的东西”。想学新东西是值得赞赏的，但是我很难想到正常人在短时间就能把一门新的技术学通。尤其是开源技术，基本属于入门容易精通难，很容易找到一些教程101，帮你5分钟学会安装部署，但是一旦用上生产系统，就很容易出现各种各样的突发问题，配置的、架构的、网络的、代码的、甚至还可能有硬件的——逼迫你绞尽脑汁上各种论坛找各种谷哥度娘去解决。经验就是从不断填坑的过程中积累起来的。只会安装部署，距离真正掌握还差八千里。

最夸张的见过2年换了6个公司。所以到后来，只要一看到简历中最近3次工作经验中没有超过2年的，直接就略过了。

2. 缺乏对架构的感觉

先不说一个技术人员（尤其是大数据技术人员）必备的好奇心或逻辑性，也只有对整体架构有清晰的认识，才能更加准确的了解自己要实现的需求对整个业务线的意义，从而在功能边界定义和技术选型上有相对合理的判断。如果对于自己熟悉项目的整体架构缺乏了解或者描述不清晰，我们认为这样的研发人员比较缺乏整体感和全局观，成长一般都会比较有限。

实际上画不出整个产品线技术架构图的大有人在，能画出来但是各个模块画的稀里糊涂的也不在少数。

3. 技术浮于表面

说起遇到的挑战时，很容易能够看出候选人对于技术掌握的深度。说不出挑战的情况，要么是任何技术都挡不住的大牛，要么就是没有经历过比如计算瓶颈、数据淤积、磁盘爆满、内存不足、架构调优这样的战斗洗礼。对于后者，面试官辨就一定要小心，因为这样的人即使用过的技术和框架再多，为你带来的坑也可能比填的坑还多。

想起一个印象比较深的例子，一个候选人简历上充满了说自己长于各种大数据技术的明示，然后在面试中请他找个最擅长的项目深入聊聊的时候，他说，呃…这个…那我们来聊聊之前做过的一个网站项目吧，我在里面做web前端……当时我就无语了。

4. 细节禁不住挑战

为什么要选择这个方案？和别的方案对比有什么优势？这个方案有什么问题？如果让你来研发这个方案的新版本，你准备做什么样的优化，为什么？数据量如果增大一个数量级，你觉得这个方案会出现瓶颈吗？再增大一个数量级呢？BlaBlaBla……这些都是例行问题，如果没有对技术熟悉并研究到一定程度，是很难有条理的说清楚的。

曾经遇到过一个牛气哄哄的年轻人，刚毕业工作1年就找亲戚投资创业担任CTO，瞎折腾了一年公司黄了，然后出来找工作。第一年的薪资算正常，担任CTO的时候就给自己工资翻倍，然后在翻倍的基础上期望我们再涨50%。也就是说，经过这一年创业过程，他觉得自己做了CTO，接触了好多技术，增值了，“我什么都能干”，理应比第一年涨3倍。实际问起来，每项技术都是泛泛，没什么细节，自然就fail了。

作家格拉德威尔在《异类》一书中指出，“人们眼中的天才之所以卓越非凡，并非天资超人一等，而是付出了持续不断的努力。1万小时的锤炼是任何人从平凡变成超凡的必要条件。”他将此称为“一万小时定律”。

要成为某个领域的专家，需要至少10000小时。如果每天工作八个小时，一周工作五天，那么成为一个领域的专家至少需要五年。就算是一直搞“996”，也差不多需要3年。这符合任何一个有经验的技术人员的认知：一门技术，没有两三年以上的熟悉和研究，是根本谈不上精通的。尤其是大数据行业是一个比较新的行业，很多技术和方法都在摸索阶段，需要更多的时间来积累。TalkingData也是经过了4年多和海量数据以及各种大数据技术的斗争，趟过了无数的地雷阵，到今天才可以说是有了一些积累，培养出一批在大数据领域比较有经验的技术专家。即使这样，我们从来也不认为我们研发团队里面有“全栈工程师”。

大数据行业一定是靠经验靠积累，没有任何速成的做法，所以我们始终控制研发团队能够更加聚焦一些而不是更发散一些，做的更深而不是更广一些。

那说回来，到底有没有全栈工程师存在？肯定是有的。但是我见过的能称得上“全栈”的工程师，基本都在某一个领域写过大量代码，或者解决过大量问题，积累了非常深厚的功底，然后在精深之后，把知识转化成为常识，才能真正触类旁通。这时候看起来应该就是大家说的“全栈”吧。但是这显然不适合经验较少的菜鸟工程师。

所以，希望年轻的技术人员能够更加踏实一些，不要轻信“全栈工程师”的美丽神话。只有为自己打好技术基础，才能飞得更高。