大前端不是全栈

随着业务和技术的快速发展，大前端工程复杂度越来越高。前端面对的业务在快速发展变化，工程的规模也在不断扩大，对迭代速度的要求越来越高了。而随着云计算的普及，云工程化也是目前值得探索的热点。我们应该如何选择最合适的方案在工程中实践？全栈与大前端有何异同？前端中台的建设是否有必要？带着这些问题，InfoQ 采访了腾讯前端技术专家 / 总监、IVWEB 团队负责人刘恒兵（河伯），请他为我们讲述前端人如何在发展的进程中学习与提升。

大前端工程化

大前端工作化的核心是工程化，当前的工程化诉求不仅仅局限在前端领域，涵盖了更广的大前端范围。工程化的诞生是基于企业 / 团队对研发效率的诉求，如何尽可能地使用工具释放产品研发过程中对人力的占用是工程化研发核心宗旨。从建立一套完善的规范着手，到 IDE 配套工具、研发 Mock/ 调试 / 联调、自动化测试、CI/CD，最后线上业务运维监控，涵盖产品上线的全部流程，这就是工程化要做的事情。

多团队配合项目的解决方案

那么大前端工程化，是基于大前端技术做工程化研发。广义来讲，可以支撑不仅仅是端的工程化能力，当工程化能力基于云的体系建设时候，可以满足端、后台所有栈的研发的工程化诉求。狭义来说，核心满足端的工程化诉求（前端、终端），特别是解决多人合作中本地端工程化和云端工程化能力同步，保证研发团队中所有研发人员是在同一套研发体系中，避免不对称导致的各种团队合作问题。

同时，做好工程化可以带来诸多好处。

首先，可以避免团队项目交接、人员交接等各个方面的沟通成本、学习成本。研发模式、代码风格、工具使用都在同一个维度，团队 CR 也会更为轻松。其次，有了工程化体系，对于加入团队的新人，能够更少的成本熟悉业务、更快的速度融入团队，减少不必要的熟悉、等待时间，这也是当前很多团队急需解决的一个痛点 / 问题。

大前端工程化的探索

主要是涵盖研发过程中的各个环节，核心就是前面提到的尽可能提升研发效率。具体来说，研发规范是最基础的，因此团队也是花了很大精力来建设及不断完善团队研发规范，以保证后续的工程化建设有据可依，团队有一个共同的目标和理念。

有了规范之后，接下来就是要基于规范去实现自己的研发工具，最为关键的就是研发过程中基于 IDE 的工程化工具建设，以便研发过程中问题发现前置到写代码过程中（而不是到 CI/CD），可以尽早地解决问题。这里面除了基础的 Lint 之外，更重要的团队研发的通用工具、模板脚手架、团队组件体系、自动化监控能力、MockServer、联调 / 代理、自动化测试体系、A/B Test、统一代理层、全链路监控等。

以团队通用工具举例，每个团队都有自己固有的内部 / 外部工具，那这些工具本身是零散的，需要在工程化研发过程中，把这些分散的工具统一组织、封装，并能开放插件体系，支持工具扩展，所有的工具都在一套研发体系中，可以很大程度降低学习、使用成本。

大前端并非全栈

我们通常提到的全栈，基本上是指前后端全栈研发，是基于传统技术研发人员（前端、终端、后台）的角度来说。早期的 Web 研发（asp、jsp、php、.NET，前后端分离、ajax 兴起之前）基本都可以叫全栈了，既要实现后端逻辑，又要 UI 体验。现在说的全栈概念依然一样，只是后端研发语言有所改变（java、php、nodejs、go 等）。

大前端更多的是技术及端侧研发的角度描述，包含终端技术（Android、iOS）、前端技术（h5、Hybird、Nodejs）、物联（IoT）等其他端设备研发技术，大前端全栈是指基于 Nodejs 的全栈研发。可以看到，两者描述的维度不太一样，有交集也有区别。

组件体系的建设

前面提到工程化建设中，组件体系建设也是极为重要的事情。不论是全栈还是大前端研发都离不开组件体系。好的组件体系能够让团队效率提升很大的层次。详细来说，基于现有体系（诸如 npm、github 等）建设业务的组件生态，提升组件二次研发、组件使用效率。基于好的组件生态，可以实现更复杂的智能研发能力。可以说组件是很多团队业务研发的基础，因此好的组件生态尤为重要。

更应该注重解决问题的能力

前端工程师，首先需要不断自我革新的学习能力，技术层出不穷，需要有一个好的心态，不极左，也不极右。选择合适自己及业务的技术学习并应用是必备的技能之一。

其次，精力之余拓展边界，Nodejs 全栈是一个不错的选择，进入后端研发深水区，选择其他传统的后端语言（java、go 等）解决关键性能问题也是需要考虑的。不局限在一个语言技术，因地制宜，核心是能解决问题。

前端中台只是解决问题的一种方式

互联网的产品变化较快，很多团队 / 企业在很多领域都有投入，那这些业务之间的一些共同技术建设，如能复用起来能降低业务冷启动成本，提升新业务研发效率。中台建设也是基于这个核心诉求，基于中台能力建设，能做到跨业务、跨领域技术复用，缩短新业务初创时间并节省资源。同时，复用的前提是解耦，能做到通用的能力和业务个性化能力完全解耦。解耦的架构设计，可以降低系统本身的维护成本，增强体统健壮性。解耦的设计能更好的业务之间复用。

大前端中台建设类似，问题存在就得用方案去解决，中台建设是其中一种方式（大中台、小前端）。中台不是万能的，不能解决所有问题。技术复用带来如何满足个性化诉求的问题，需要进一步思考如何更好地解决各个业务之间个性化能力。从火热到冷静也更能反映技术本身的演进，冷静并不是代表放弃，而是面临新的问题如何进一步解决。

前端中台的分层架构

回到前端工程化的能力，针对前端中台来说，一定程度上工程化就是在前端中台的事情。把前端通用的一些规范、工具、能力、组件统一化中台建设，提供不同的业务支持。

因此从设计上，应该包含基础层，统一网关，组件层，业务层。基础层提供基础的工具和能力支撑（诸如全链路监控基础工具）、统一网关（统一路由分发、业务个性化插件）、组件层（基础通用组件、组件二次开发体系、组件组装、智能研发）、业务层（业务逻辑与业务组件等）。

每一个环节都很关键，能够把我们业务开发的基础、插件、组件、业务完全隔离开来，尽可能做到不同复用。

中台的拆分与合并，我们该遵循怎样的原则

架构解耦和拆分工作，本身就是一个度的把握。原则上既要解决逻辑耦合，又不能过度设计，允许一定程度的冗余。在开发过程中，要看到实际业务之间可行的复用能力、模块、组件，而非理想情况下的复用。基于实际的复用诉求，进行业务提炼解耦，并做一定程度的超前思考（原则就是做有意义的拆分）。

前面提到的架构设计中，统一网关层插件、组件二次开发就是要解决这些问题。支撑不同业务自定义插件（或许这些插件之间存在部分重复，但不影响整理架构复用）、组件二次开发进行复用，能做到整体上架构一致和不用业务之间个性诉求。

前端中台的建设实践

上文已经提到了刘恒兵老师团队的前端中台方案和设计。那么其中遇到的问题主要还是怎么尽可能复用以及业务个性化诉求。我们经常会超前研发设计一些拆分与解耦，但后续实际过程中发现是一个伪需求。比如说组件，很多时候提炼的业务通用组件发现后续业务并不能直接复用，业务个性化诉求太多了。

方案上，通过组件二次开发体系建设，解决这类问题。我们发现虽然业务组件不能直接复用，但又能复用其中一部分，直接使用不满足诉求，重新开发浪费精力。其实这里核心的问题并不是复用，而是复用的效率，最后搭建二次研发体系方便研发能够快速二次开发，提升二次开发效率，达到复用的目的。

回顾与展望2020 年，疫情下的“前端”

回顾 2020，我印象比较深的有三件事：一是 TypeScript 的大范围普及，二是工程化的发展，三是全栈深水区。

相比于 2019 年，2020 年 TypeScript 已经深入人心了，各前端框架对 TypeScript 的支持进一步推动了 TypeScript 的应用和普及，语言层面的发展能非常快速的促进一个领域的发展，正如 Node.js 促进前端领域发展一样。

2020 年的疫情给整个社会带来的新的挑战，企业对于研发效率的迫切需求进一步促进了工程化领域的发展。以前工程化对于很多研发人员仅为了解或者认知仅限于工程构建。疫情期间的工程化已经演变为对企业效率的诉求，各个领域都需要工程化体系帮助远程办公、移动办公提升效率。

2020 年，大前端全栈逐渐进入深水区，不再是仅仅满足基本的 SSR/BFF 等诉求。对 Node.js 新的期待逐渐变多，承担更多的场景。中台化后统一的服务、网关都是需要 Node.js 去承担，因此带来的服务质量、容灾等各方面诉求就对 Node.js 提出了新的要求，全链路监控、Serverless 服务质量 / 性能等都需要进一步建设和完善。当然，这些挑战也会进一步促进 Node.js 的生态发展。

2021 年，前端人如何成长？

刘恒兵老师表示，在他看来，以下三个方向都很值得关注：

Node.js 全栈，当进入深水区之后，大家要研究的就是如何进一步突破瓶颈，包含当前遇到的 Serverless 性能（冷启动、并发）的挑战。云工程化 (含 IDE)，提升企业远程办公、移动办公效率。智能研发，改变研发模式，对于业务基础的、通用的 UI 还原可以释放资源，让机器代替研发，提升效率。

前端从业者一直面临的挑战应该就是不断学习的能力，从历史来看，新的技术层出不穷，需要保持不断学习，那么明年或许一样，也会有新的技术诞生。对于我们自身来讲，保持客观的心态，认知每一个新的技术、领域的时候需要从问题着手去了解（解决了什么问题，对当前业务的帮助），然后合理应用。

针对全栈领域进入深水区后，需要提出更高的质量标准要求，搭建工具并抽象解耦复用，提升服务质量。

文章来源：infoQ

作者 | 李俊辰