随着业务和技术的快速发展，大型前端项目的复杂度越来越高。 随着项目前端业务的快速发展变化，项目的规模也在不断扩大，对迭代速度的要求也越来越高。 随着云计算的普及，云工程也是一个值得探讨的热门话题。 应该如何选择最合适的方案在项目中实践？全栈和大前台有什么异同？前台和中台有必要建吗？带着这些问题，InfoQ采访了腾讯前台技术专家/总监、IVWEB团队负责人刘恒兵(Hebo)，请他告诉我们前台人在发展的过程中是如何学习和提高的。 工程是大前台的核心。现在的工程需求不仅仅局限于前台领域，还涵盖了更广泛的大前台。 工程的诞生是基于企业/团队对R&D效率的需求。如何尽可能多地使用工具来释放产品R&D对人力的占用，是工程研发的核心主题 从建立一套完善的规范开始，从IDE配套工具，到Mock/debug/联调、自动化测试、CI/CD的研发，最后到线上业务运维监控，覆盖产品上线的统一流程，这才是工程应该做的。 多团队合作项目的处理方案，大到前端工程，都是基于前端技术的工程研发。 从广义上讲，它不仅可以支持端的工程能力，而且在基于云系统构建工程能力时，可以支持端和后端所有栈的R&D的工程需求。 狭义来说，核心是满足端(前台和终端)的工程诉求，尤其是处理多人合作中本地工程和云工程能力的同步，保证R&D团队所有R&D人员在同一个R&D体系，避免不对称带来的各种团队合作问题。 同时，好的工程可以带来很多好处。 首先可以避免团队项目交接和人员交接的沟通成本和学习成本。 R&D模式、代码风格和工具使用都在同一个维度，团队CR会更容易。 其次，有了工程系统，加入团队的新人可以用更少的成本熟悉业务，以更快的速度融入团队，减少不必要的熟悉和等待时间，这也是目前很多团队急需处理的痛点/问题。 大前端工程的探索，主要涵盖了R&D过程中的各个环节，核心就是上面提到的尽可能提高R&D效率。 具体来说，R&D规范是最基础的，所以团队也花了很多精力来打造并不断完善团队的R&D规范，以保证后续工程建设有据可循，团队有共同的目标和理念。 有了规范，下一步就是基于规范实现我们自己的R&D工具。最重要的是在R&D过程中构建基于IDE的工程工具，让R&D过程中的问题发现可以先于代码编写过程(而不是CI/CD)，尽早处理问题。 除了基础的Lint，还有团队开发的比较重要的常用工具，模板脚手架，团队组件系统，自动监控能力，MockServer，联调/代理，自动测试系统，A/B测试，统一代理层，全链路监控等。 以团队常用工具为例。每个团队都有自己的内部/外部工具，所以这些工具是分散的。在工程研发过程中，需要将这些分散的工具进行统一的组织和打包，并开放插件系统支持工具扩展。所有的工具都在一套研发体系中，可以大大降低学习和使用成本。 大前端不是我们通常所说的全栈，基本上是指前端和后端全栈R&D，这是基于传统技术R&D人员(前端、终端、后端)的视角。 早期的Web研发(asp，jsp，php，。NET，前后台分离之前，ajax)基本可以称为全栈，既需要后台逻辑，也需要UI体验。 现在全栈的概念还是一样，只是后台R&D语言变了(java，php，nodejs，go等。) 前台更多的是从技术和端到端R&D的角度来描述，包括终端技术(Android、iOS)、前台技术(h5、Hybird、Nodejs)、物联网等端到端设施R&D技术。全栈前台是指基于Nodejs的全栈R&D。 大家可以看到，两者描述的维度是不一样的，有交叉也有区别。 工程建设中提到了构件体系建设，构件体系建设也是一件极其重要的事情。 无论是全栈还是大前端R&D，都离不开组件系统。 一个好的组件系统可以大大提高团队效率。 具体来说，基于现有系统(如npm、github等)构建业务的组件生态。)，提高组件的二次研发和使用组件的效率。 基于良好的组件生态，可以实现更复杂的智能R&D能力。 可以说，组件是很多团队业务研发的基础，所以良好的组件生态尤为重要。 更应该注重处理问题的能力。前台工程师首先需要的是自我创新的学习能力，技能是无止境的。他们需要一个好的态度，既不极左也不极右。 学习和应用适合你和你的企业的技术是必备技能之一。 其次，Nodejs的全栈是一个很好的选择，可以在能量之后扩展边界。还要考虑进入后台R&D的深水区，选择其他传统后台语言(java、go等。)来处理关键的性能问题。 不局限于一门语言技术，核心是能够因地制宜处理问题。 前台只是处理问题的一种方式。互联网产品变化快，很多团队/企业在很多领域都有投入。如果这些业务之间少量的共性技术构建可以复用，可以降低业务的冷启动成本，提高新业务的研发效率。 中台的建设也是基于这个核心需求。基于中台的能力建设，可以实现跨业务、跨域的技术重用，缩短新业务的启动时间，节约资源。 同时，复用的前提是解耦，可以将通用能力与个性化服务能力完全解耦。 解耦架构设计可以降低系统本身的维护成本，增强系统的健壮性。 解耦设计可以更好地重用服务。 大前台和中台的搭建是类似的，有什么问题都要用解决方案来处理。中台的搭建就是其中一种方式(大前台和小前台)。 台湾不是万能的，不能处理所有问题。 技术重用带来了如何满足个性化需求的问题，需要进一步思考如何更好地处理各种业务之间的个性化能力。 从火热到冷静也更能体现技术本身的演变。冷静并不意味着放弃，而是如何进一步处理新的问题。 前台的层级结构回归到前台工程的能力。对于前台工程来说，在一定程度上，工程就是前台工程里的东西。 统一少量前台常用的规范、工具、能力和组件来构建中台，并提供不同的业务支持。 因此，设计应该包括基础层、统一网关、组件层和业务层。 基础层提供基础工具和能力支持(如全链路监控的基础工具)、统一网关(统一路由分发、业务个性化插件)、组件层(基础通用组件、组件二次开发系统、组件组装、智能研发)、业务层(业务逻辑和业务组件等)。). 每一个环节都很关键，可以完全隔离我们业务开发的基础、插件、组件、服务，尽可能不同的复用。 台湾的分裂和合并，我们应该按照什么标准来架构脱钩和分裂的工作，这本身就是一种程度的把握。 标准不仅要处理逻辑耦合，而且不能过度设计，允许一定程度的冗余。 在开发过程中，要看到实际业务之间可行的复用能力、模块和组件，而不是理想的复用。 基于实际的复用需求，对业务进行细化和解耦，做一定程度的前瞻性思考(准则是做有意义的拆分)。 在前面提到的架构设计中，统一网关层的插件和组件的二次开发就是为了处理这些问题。 支持不同的业务建立自己的插件(或者这些插件可能有一部分是重复的，但不会影响架构的重组和复用)，通过二次开发复用组件，使整体架构保持一致，避免业务间的个性化需求。 前台建设的实践前面已经提到了刘恒兵先生团队的前台方案和设计。 然后，遇到的主要问题是如何尽可能的重用和业务的个性化需求。 我们往往提前设计了少量的拆分和解耦，但在后续的实际过程中发现是伪需求。 比如组件，很多时候精细化的业务通用组件发现后续业务无法直接复用，业务个性化需求太多。 方案，通过组件二次开发系统构建，处理这类问题。 我们发现虽然业务组件不能直接重用，但是可以重用其中的一部分。直接使用不能满足需求，二次开发浪费。 其实这里的核心问题不是复用，而是复用效率。最后，建立一个二次R&D系统，方便R&D，使其能够快速开发，提高二次开发效率，达到重用的目的。 目前在做前台开发。如果你现在想学习前台开发技术，并且遇到任何关于学习方法、学习路线、学习效率等方面的问题。入门过程中可以申请加入我的前台学习交流裙3000人:前:851中:231末:348。 有少量初学者裙档正在自学前台。还有少量我在做前台技术期间整理的前台学习手册、前台面试问题、前台开发工具、PDF文档、书籍和教程。如果需要，可以自己下载。 回望2020年，回望疫情下的“前台”，有三件事让我印象深刻:一是打字稿的广泛普及，二是工程的发展，三是全栈深水区。 相比2019年，2020年的TypeScript已经深入人心。各种前端框架对TypeScript的支持，进一步促进了TypeScript的应用和普及。语言水平的发展可以很快的推动一个领域的发展，就像Node.js推动前端领域的发展一样。 2020年的疫情给整个社会带来了新的挑战，企业对R&D效率的迫切需求进一步推动了工程领域的发展。 在过去，工程只是被许多R&D人理解或认可，而且仅限于工程建设。 疫情期间，工程已经演变为企业效率的需求，各个领域都需要工程系统来帮助远程办公和移动办公提高效率。 2020年，整个前台将逐渐进入深水区，不再仅仅满足基本的SSR/BFF需求。 对Node.js的新期待逐渐增加，承担更多的场景。 台湾向中国转型后的统一业务和网关都需要Node.js承担，因此服务质量、容灾等方面的需求对Node.js提出了新的要求，全链路监控和无服务器服务质量/性能都需要进一步建设和完善。 当然，这些挑战会进一步推动Node.js的生态发展 2021年接待员会有怎样的成长？在我看来，以下三个方向值得关注:Node.js的全栈进入深水区后，大家要研究如何进一步突破瓶颈，包括目前无服务器性能的挑战(冷启动和并发)。 提高企业远程办公和移动办公效率的云工程(包括IDE)。 智能R&D，改变R&D模式，对于基于业务和通用的UI修复，可以释放资源，用机器代替R&D提高效率。 前端从业者一直面临的挑战应该是不断学习的能力。从历史上看，新技术层出不穷，需要不断学习。然后明年，或者同样的，新技术将会诞生。 对于自己，要保持客观的态度。当我们了解每一项新的技术和领域时，我们需要从问题入手去理解它(处理过哪些问题，对当前的业务有什么帮助)，然后恰当地应用它。 整个栈场进入深水区后，需要提出更高的质量标准，构建工具，一般要解耦复用，提高服务质量。