业务|场景构造难，编译很耗时？看小程序业务如何提高效研发构造|场景|编译|小程序|业务

文章插图
作者 | 王梦君
来源 |滴滴顺风车技术（ID：sfc-tech）
自 2016 年小程序诞生以来，小程序以其“用完即走”的设计理念，以及简单易上手的开发模式，吸引了大批的小程序使用者以及开发者，随着小程序市场越来越大，相应的小程序开发者也越来越多，与此同时出现的各类小程序开发第三方框架也层出不穷。
一、小程序开发模式
小程序开发模式整体来说有两种，一种是原生小程序开发，一种是第三方框架开发。

文章插图
整体来看小程序原生开发只能适配在对应的单独 App 中运行，不能提供比较全面的可以跨多端的开发能力，在有多端小程序应用需求的情况下，比较浪费人力
另外一种方案则是利用跨端框架，这种方案开发的应用一般可以达到“一套代码，多端运行”的基本目标，可以大量地节省人力，提高效率。
跨端框架开发小程序固然有很多优点，但是这种开发模式也会有一些问题，比如核心问题就是编译耗时长、开发体验差、前后端耦合等
本篇文章主要分享使用 Chameleon 框架在开发业务小程序应用过程中遇到的痛点问题，以及如何解决的心路历程。
同时也欢迎大家多多关注我们，Github 地址：
https://github.com/didi/chameleon
二、业务开发面临的痛点问题
1. 业务开发面临的痛点问题
我们在小程序开发中遇到的痛点问题主要包括两方面：
场景构造难：强依赖后端接口和手动操作流程
编译耗时长：第三方框架编译和开发者工具编译耗时极长

文章插图
【场景构造难】
我们的业务开发中很多场景，包括发单场景、收到邀请场景、等待车主邀请场景、被多个车主邀请场景、各种管控策略场景等，都强依赖后端接口以及强依赖人工操作某些流程，从乘客发单到被车主接单，需要乘客账号、车主账号 (某些场景下需要多个手机多个账号) 进行协助构造某些场景，甚至很多情况下，构造场景耗时间占用开发 50% 的时间，严重影响开发流程和开发效率。

文章插图
极端情况下，可能几十行代码的增减，就需要耗费一天的时间，大量的人力浪费在构造场景、多个手机发单接单等等本不应该有的流程上，令人痛苦不堪。
【编译耗时长】
从开发者第一次启动项目开发，到编码之后保存热更新编译，Chameleon 框架编译的源码在小程序开发者工具会再次消耗编译耗时。
小程序原生开发过程中，编译耗时主要集中在小程序开发者工具这一个过程。
而第三方框架开发，编译耗时则主要集中在框架编译 + 小程序开发者工具这两个过程。
同时第三方框架编译的源码的大小也会直接地影响小程序开发者工具编译耗时。

文章插图
对于编译耗时长的问题，特别是前端开发而言，需要实时查看代码变更到 UI 的效果，多次保存就会多次构建，即使仅仅写了一行代码，甚至一个空格的变更，保存之后都会引起重新编译
这个编译是让很容易让人抓狂和崩溃的，最宝贵的开发时间都浪费在了等待上，项目再紧急也要等着这些令人难以忍受的编译过程一直转圈圈，严重影响开发效率，严重浪费人力成本，严重影响项目进度。
2. 如何解决业务上的痛点问题？
针对场景构造难的问题，核心原因是：
前后端强耦合，各种场景强依赖开发人员人工操作复现；
前端缺少基本的数据体系建设，对于各种场景的后端数据结构缺少基本的收集规整。
针对编译耗时长的问题，核心原因是：
从代码开发到小程序开发者工具展示要经历框架编译和小程序开发者工具编译两个过程；
对于业务代码量大的情况下，编译的文件个数和文件体积会更多更大，同时会进一步影响这两个构建编译的耗时。
那么如何解决上述核心痛点问题呢？
我们团队采用了“微型前端应用”这样的思路进行单点突破，化解面临的棘手问题，逐个击破，成功地解决了开发效率极低，人力成本极为浪费，开发体验极差的情况。
3. 解决方案
服务层：构建本地数据体系，规整各种状态数据结构，建设开发规范，梳理开发文档。
应用层 + 业务层：将应用层的代码和业务层的抽象进行对应，支持路由和分包的自动化配置，支持按需构建要开发的单页面，这样从源头上解决了要构建编译大量代码而引起的编译耗时长的问题。