干货 | 携程玩乐团队前端多端开发实践

作者简介

 

Neo，携程前端开发工程师，负责玩乐前端架构相关开发工作。

一、前言

本文将介绍在具体业务实践中，携程玩乐团队一套代码多端复用的一些实践与经验，希望能给面对同样问题的同学提供些思路和参考。

1.1 背景

在多端开发实践之前，玩乐的前端开发存在如下一些问题：

1）技术栈架构繁杂且陈旧

到2019年2月，整个玩乐前端系统随着不同需求的叠加积累以及其他原因，造成了不同业务线的基础架构，技术栈不一致。当时的页面技术栈包括：.net页面、imvc页面、nextjs页面、jquey页面等，这些不同技术栈的应用从写法、结构、思想等方面都有不少出入。在公司全面推行React技术栈的背景下，诸如 JQuery、.net的前端技术架构显得十分陈旧，各个技术栈之间形成了天然的技术壁垒，不利于代码维护和人员培养。

2）统一产品需求，需要多端多渠道实现

改造前业务团队是按照端和渠道来进行具体的需求划分，如下图所示：

这就意味着前端需要支持国内、海外包括 PC、H5、Hybrid、RN七个（海外版没有Hybrid页面）端的需求代码实现，如果按照改造前的模式，将会有同学为了这个需求更改6个仓库的代码。可以预见，如果这种模式不更正，前端开发将是在来回切换仓库中度过的。

3）发布困难，监控麻烦

正是由于技术架构不统一，所以改造前的应用从打包到发布，其间的流程、打包技术存在很大差异，发布变成了一件手动且不可预期的工作。改造前的页面只是接入了一些公司日志框架，对于一些业务性能指标、细颗粒度的指标并未记录，这也导致了排查问题流程长，效率低下，开发人员只关注完成代码并不知道页面性能等问题。

1.2 举措

针对前端系统存在的问题，我们进行了一些调研和不同框架之间的横向比对。遗憾的是目前并没有一套架构设计可以同时运行在多端，所以我们开始了对多端架构的持续开发与改造的过程，重点措施如下：

1）架构升级

对代码结构和业务逻辑实现做合理划分，在不同层级架构上做合理的事，并且对代码做测试，引入新的日志系统，接入新的打包发布流程。

2）面向组件化的开发策略

尽可能多的将需求逻辑抽象成各个组件，再将这些组件拼接成页面。基于这个角度，我们将组件划分成基础组件和业务组件两个部分。

3）支持PC/H5/RN同时预览

作为多端开发的实践，为了确保开发效率，需要满足一处修改多端同时可见。

二、架构简介

为了能让RN和非RN的代码同时运行，如果按照改造前的做法会出现如下一些问题：

1）由于是一套代码，在发布的时候会出现不断改代码配置然后再去发布的问题；

2）代码逻辑