全栈与大前端，前端工程师进阶该如何抉择？-InfoQ

今天，我想跟大家谈谈前端工程师进阶方向的问题。关于这个问题市场上的杂音太多，各种误解、误导太多，我想谈谈我的观察和理解，包括全栈、Node 全栈、大前端等，希望对大家有所帮助。

不想成为全栈的前端不是好程序员。

数年以前，全栈工程师的理念忽然风靡墙内外，成为开发者们津津乐道的话题。数年过去，关于全栈工程师的争议不多了，教你速成全栈工程师的视频课程多了起来，说明大家对于这个理念慢慢接受了。但我发现，鼓吹前端往全栈转型做的有点走火入魔，有的说前端应该成为 K 型人才，甚至部分招聘前端工程师的要求都写着：熟悉后端至少一门语言和框架，熟悉数据库。

过分了啊。

诚然，有了 Node，再加上 JavaScript 大杀四方，前端转型全栈的确是非常顺理成章，但各个语言在各自领域耕耘多年，别说取代，就连取得一席之地都非常难。如果不靠一门语言通打天下，去学习其它领域知识、熟悉领域整个技术生态依然是艰难而缓慢的过程，这难度不亚于转职为其它领域的程序员了。

所以，全栈虽好，也不能贪心啊。

不必神话全栈

时至今日，全栈工程师需要做到什么程度依然没有定论，但如果我们从一些全栈的课程、招聘需求去看，可以得出社会上对于全栈的一个朦胧的认知。

这是YouTube 上的一个全栈教程，它教了什么呢？MongoDB、Express、Node、Angular。是的，就这些。

我们来看一个严肃点的吧，号称可以发放“纳米学位”的某在线学院的付费课程：

是的，就这么多。

如果你觉得这些太简单，感觉很不现实，那我们来看看招聘方的需求：

这是ebay 的招聘要求，注意是招的Senior，要求才这么高。

然后看看国内的。

从上面我们可以看到，对于全栈工程师，社会上的要求真的不高。就像某些人调侃的那样：会一门前端和一门后端就自称是全栈工程师了。没错，真的可以。

为什么呢？随着现代大型互联网应用架构越趋复杂，一个人是很难同时精通很多领域的，但如果只是开发小型应用，应对不多的流量，借助开源软件和工具，一个人也可以办到，这是导致全栈工程师出现的根本原因。

全栈工程师从最开始就是为小型应用而诞生的，想让它解决一切只不过是幻想。

谈谈Node 全栈

随着全栈工程师兴起的还有另一个词：Node 全栈。它到底指的什么？

Node 现在真的什么都能干，从服务端开发到人工智能、区块链，到处都可以见到 Node 和 JavaScript 的身影。只靠 Node，你似乎都能完成全栈开发了，事实上有些全栈招聘的后端技能就是 Node。

但这只是表面现象。

就像上面我说过，各种语言都有他们适合的场景，在追求性能的服务端基础组件、追求高并发高可用的大型系统开发上，Node 还非常稚嫩。比如，最近 OpenResty 的创始人就在微博上对 Node 启动之慢表示惊讶，而这是因为 Node 启动时要加载很多 JS 代码造成的，算是先天缺陷，难以克服。

所以，要想真正开发靠谱的大型系统，Node 还得靠边站。但是，靠着前端的飞速发展，Node 在这种大型系统中也取得了一席之地。

其中，SSR 和 BFF 都需要在后端开发一个中间层，而且这个中间层多半由前端开发和维护，于是使用 Node 成为顺理成章的选择。

其次，在现代的微服务架构中，Node 可以用来开发部分服务，利用在异步 IO 上的优势，在性能上可以满足需求。

除此之外，桌面应用开发上基于 Node 的跨平台方案渐成主流，一些新兴领域也都等待探索，Node 的应用场景还是很丰富的。

所以，我认为的 Node 全栈，是部分优势领域的开发 + 新兴领域探索，Node 本身并不是一个完整的全栈方案。

关于 Node，我们这次 GMTC 邀请了 cnode 社区的扛把子，Node 全栈的鼓吹者狼叔，还对他做了采访，他对 Node 的理解更深，大家后面可以看采访文章。

K 型人才？为何不干脆“米”字型？

之前美团点评的刘平川老师曾写过一篇文章，说前端开发可以一专多能，又叫 T 型人才，这个词其实在职场提的挺多，大家都比较认同。放到前端领域来说，就是在不同的侧重点、不同的平台上都有开发能力，但同时对某个子领域扎的很深，他们欢迎这样的人才。

然而，前段时间看到这样一段话：

……到了今年，企业开始更注重前端工程师的技术广度。一个优秀的前端，要做到的不仅仅是「T 字型」，而应该努力成为精通前后端至少两门语言的「K 字型」人才。

K 字型啊，看着这些触手，我稍微想象了一下，内心受到了冲击……要同时精通前后端至少两门……精通一门就已经够难的了，按一万小时定律，再怎么也得好几年吧，四门的话，算成十年不过分吧，它的这个要求，你要花十年来达到，显然不太可能。

而且那代表广度的横杠也没有的，意思是不用关心其它平台和领域吗？

还不如米字型更合理呢。

而米字型，宛如章鱼，那是真全能了，比上面说的全栈还厉害。

讨论人才什么类型，针对的是市场的需要。这又引出一个问题，前端在企业里的晋升到底靠什么？公司到底需要什么样的前端？

在大厂里，前端的晋升靠什么？

在筹办今年的 GMTC 的时候，我拜访了百度的谭待和高磊老师，也聊到了这一话题，与我所想的 T 型、全栈不一样，他们的回答是，在大厂里，工作高度分工，工程师的全栈其实很少有用武之地，晋升要看他们的工作对业务的帮助。

是的，公司要的是业绩，技术的最终价值就应该体现在提升业绩上，这其实是放在任何职业都适合的说辞，只是我们很多时候都忘了。

在对新技术的追逐上，在对采用何种技术的选型上，很多时候我们为了技术而技术，为了让自己不落伍而学习使用新技术，而并没有从是否适合公司业务的角度去考虑。

举个例子，去年以来，前后端分离非常火，很多前端打着首屏直出或者 SSR 的理由要做前后端分离。但是你想过吗？增加一个中间层，必然会让响应时间增加，即使需要渲染的页面简单，最少也要增加几十毫秒。另外，如果不能保证中间层的可用性，就变相的增加了系统挂掉的风险。所以，不能盲目的采用新技术。

还有人说，前端离业务太远，根本联系不起来。有的公司可能是这样，前端接触不到业务数据，不知道自己所做的工作给业务带来的影响，更不知道如何去衡量。但前端是数据采集端，其实离数据很近，PV/UV、应用性能数据等至少是可以接触到的吧，通过这些数据，也可以衡量工作的效果。

另外，提升工程效率，制定规范，打造持续集成工作流，也都是能帮助业务的地方。

从提升业务数据的角度去看新技术，才能既让工作获得肯定，也能保持技术上的成长。

当然，这里的新技术要在你负责的岗位职责之内，逾越本分，抢别人的活干，干好了别人不会感激你，活儿干差了则是铁定背锅。

那么前端、App 开发工程师，这些所谓的大前端，到底都能干些什么？

再谈大前端

大前端快被说烂了，然而还是有很多人不理解它具体指什么。像上面的“K 型人才”，作者认为这样也算大前端，这显然不对。

那么，大前端的边界到底在哪里？

端上的开发，Web、移动端、PC 端，这些平台上的开发现在大家基本都认同是大前端的职责了，虽然在具体的工作中会按平台来划分。

工程化，提升工程效能，其中端上的工作也被认为是大前端的事情。

服务端的开发，Node 全栈，有人认为也是大前端，因为都是用的 JS 嘛。但我认为不是。因为这样的话，前后端的划分就没有意义了，全栈是全栈，前端是前端。那么，在服务端上，大前端可以做什么？

我认为这要看具体的系统架构，拿现在越来越流行的微服务架构来说，API 网关看似和前端有关，API 的内容是由前端的需求驱动而来，但分析网关需要做的事情，流控、鉴权、熔断、报文转换等等，完全是后端的职责。

但在 API 网关之外，SoundCloud 的 Phil Calçado 提出的 BFF 架构，其实是可以由前端来负责的，而且也刚好和平台、岗位对应起来，可以当做前端的自留地。在上面 SSR，或者像是由手 Q 开源的 VasSonic 框架里的代码 buffer 化这样的骚操作都可以实现。当然，这里一定会遇到高并发、高可用、性能的问题，是需要前端去拓展自己的地方。