大前端不是全栈 _大前端

作者 | 李俊辰
随着业务和技术的快速发展，大前端工程复杂度越来越高。前端面对的业务在快速发展变化，工程的规模也在不断扩大，对迭代速度的要求越来越高了。而随着云计算的普及，云工程化也是目前值得探索的热点。我们应该如何选择最合适的方案在工程中实践？全栈与大前端有何异同？前端中台的建设是否有必要？带着这些问题，InfoQ 采访了腾讯前端技术专家 / 总监、IVWEB 团队负责人刘恒兵（河伯），请他为我们讲述前端人如何在发展的进程中学习与提升。
1大前端工程化
大前端工作化的核心是工程化，当前的工程化诉求不仅仅局限在前端领域，涵盖了更广的大前端范围。工程化的诞生是基于企业 / 团队对研发效率的诉求，如何尽可能地使用工具释放产品研发过程中对人力的占用是工程化研发核心宗旨。从建立一套完善的规范着手，到 IDE 配套工具、研发 Mock/ 调试 / 联调、自动化测试、CI/CD，最后线上业务运维监控，涵盖产品上线的全部流程，这就是工程化要做的事情。
多团队配合项目的解决方案
那么大前端工程化，是基于大前端技术做工程化研发。广义来讲，可以支撑不仅仅是端的工程化能力，当工程化能力基于云的体系建设时候，可以满足端、后台所有栈的研发的工程化诉求。狭义来说，核心满足端的工程化诉求（前端、终端），特别是解决多人合作中本地端工程化和云端工程化能力同步，保证研发团队中所有研发人员是在同一套研发体系中，避免不对称导致的各种团队合作问题。
同时，做好工程化可以带来诸多好处。

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

大前端工程化的探索
主要是涵盖研发过程中的各个环节，核心就是前面提到的尽可能提升研发效率。具体来说，研发规范是最基础的，因此团队也是花了很大精力来建设及不断完善团队研发规范，以保证后续的工程化建设有据可依，团队有一个共同的目标和理念。
有了规范之后，接下来就是要基于规范去实现自己的研发工具，最为关键的就是研发过程中基于 IDE 的工程化工具建设，以便研发过程中问题发现前置到写代码过程中（而不是到 CI/CD），可以尽早地解决问题。这里面除了基础的 Lint 之外，更重要的团队研发的通用工具、模板脚手架、团队组件体系、自动化监控能力、MockServer、联调 / 代理、自动化测试体系、A/B Test、统一代理层、全链路监控等。
以团队通用工具举例，每个团队都有自己固有的内部 / 外部工具，那这些工具本身是零散的，需要在工程化研发过程中，把这些分散的工具统一组织、封装，并能开放插件体系，支持工具扩展，所有的工具都在一套研发体系中，可以很大程度降低学习、使用成本。
2大前端并非全栈
我们通常提到的全栈，基本上是指前后端全栈研发，是基于传统技术研发人员（前端、终端、后台）的角度来说。早期的 Web 研发（asp、jsp、php、.NET，前后端分离、ajax 兴起之前）基本都可以叫全栈了，既要实现后端逻辑，又要 UI 体验。现在说的全栈概念依然一样，只是后端研发语言有所改变（JAVA、php、nodejs、go 等）。
大前端更多的是技术及端侧研发的角度描述，包含终端技术（Android、IOS）、前端技术（h5、Hybird、Nodejs）、物联（IoT）等其他端设备研发技术，大前端全栈是指基于 Nodejs 的全栈研发。可以看到，两者描述的维度不太一样，有交集也有区别。
组件体系的建设
前面提到工程化建设中，组件体系建设也是极为重要的事情。不论是全栈还是大前端研发都离不开组件体系。好的组件体系能够让团队效率提升很大的层次。详细来说，基于现有体系（诸如 npm、github 等）建设业务的组件生态，提升组件二次研发、组件使用效率。基于好的组件生态，可以实现更复杂的智能研发能力。可以说组件是很多团队业务研发的基础，因此好的组件生态尤为重要。
更应该注重解决问题的能力
前端工程师，首先需要不断自我革新的学习能力，技术层出不穷，需要有一个好的心态，不极左，也不极右。选择合适自己及业务的技术学习并应用是必备的技能之一。