作者:王夢君
微信公眾號:滴滴順風車技術
出處:https://mp.weixin.qq.com/s/M1VArJ_ORY-eXSKzD6ysQw
導讀：
自2016年小程序誕生以來，小程序以其“用完即走”的設計理念，以及簡單易上手的開發(fā)模式，吸引了大批的小程序使用者以及開發(fā)者，隨著小程序市場越來越大，相應的小程序開發(fā)者也越來越多,與此同時出現的各類小程序開發(fā)第三方框架也層出不窮。
一、小程序開發(fā)模式
小程序開發(fā)模式整體來說有兩種，一種是原生小程序開發(fā)，一種是第三方框架開發(fā)。
整體來看小程序原生開發(fā)只能適配在對應的單獨App中運行，不能提供比較全面的可以跨多端的開發(fā)能力，在有多端小程序應用需求的情況下，比較浪費人力
另外一種方案則是利用跨端框架，這種方案開發(fā)的應用一般可以達到“一套代碼，多端運行”的基本目標，可以大量的節(jié)省人力，提高效率。
跨端框架開發(fā)小程序固然有很多優(yōu)點，但是這種開發(fā)模式也會有一些問題，比如核心問題就是編譯耗時長、開發(fā)體驗差、前后端耦合等
本篇文章主要分享使用 Chameleon 框架在開發(fā)業(yè)務小程序應用過程中遇到的痛點問題，以及如何解決的心路歷程。
同時也歡迎大家多多關注我們 ，Github地址：https://github.com/didi/chameleon
二、業(yè)務開發(fā)面臨的痛點問題
1.業(yè)務開發(fā)面臨的痛點問題
我們在小程序開發(fā)中遇到的痛點問題主要包括兩方面
- 場景構造難：強依賴后端接口和手動操作流程
- 編譯耗時長：第三方框架編譯和開發(fā)者工具編譯耗時極長
【場景構造難】
我們的業(yè)務開發(fā)中很多場景，包括發(fā)單場景、收到邀請場景、等待車主邀請場景、被多個車主邀請場景、各種管控策略場景等，都強依賴后端接口以及強依賴人工操作某些流程,從乘客發(fā)單到被車主接單，需要乘客賬號、車主賬號(某些場景下需要多個手機多個賬號)進行協助構造某些場景，甚至很多情況下， 構造場景耗時間占用開發(fā)50%的時間，嚴重影響開發(fā)流程和開發(fā)效率 。
極端情況下，可能幾十行代碼的增減，就需要耗費一天的時間，大量的人力浪費在構造場景、多個手機發(fā)單接單等等本不應該有的流程上，令人痛苦不堪。
【編譯耗時長】
從開發(fā)者第一次啟動項目開發(fā)，到編碼之后保存熱更新編譯，Chameleon框架編譯的源碼在小程序開發(fā)者工具會再次消耗編譯耗時。
小程序原生開發(fā)過程中，編譯耗時主要集中在 小程序開發(fā)者工具 這一個過程。
而第三方框架開發(fā)，編譯耗時則主要集中在 框架編譯 + 小程序開發(fā)者工具 這兩個過程。
同時 第三方框架編譯的源碼的大小 也會直接的影響 小程序開發(fā)者工具編譯耗時
對于編譯耗時長的問題，特別是前端開發(fā)而言，需要實時查看代碼變更到UI的效果，多次保存就會多次構建，即使僅僅寫了一行代碼，甚至一個空格的變更，保存之后都會引起重新編譯
這個編譯是讓很容易讓人抓狂和崩潰的，最寶貴的開發(fā)時間都浪費在了等待上，項目再緊急也要等著這些令人難以忍受的編譯過程一直轉圈圈， 嚴重影響開發(fā)效率，嚴重浪費人力成本，嚴重影響項目進度。
2.如何解決業(yè)務上的痛點問題？
針對場景構造難的問題，核心原因是
- 前后端強耦合，各種場景強依賴開發(fā)人員人工操作復現
- 前端缺少基本的數據體系建設，對于各種場景的后端數據結構缺少基本的收集規(guī)整
針對編譯耗時長的問題，核心原因是
- 從代碼開發(fā)到小程序開發(fā)者工具展示要經歷框架編譯和小程序開發(fā)者工具編譯兩個過程
- 對于業(yè)務代碼量大的情況下，編譯的文件個數和文件體積會更多更大，同時會進一步影響這兩個構建編譯的耗時
那么如何解決上述核心痛點問題呢？
我們團隊采用了 "微型前端應用" 這樣的思路進行單點突破，化解面臨的棘手問題，逐個擊破，成功的解決了開發(fā)效率極低，人力成本極為浪費，開發(fā)體驗極差的情況。
3.解決方案
- 服務層：構建本地數據體系，規(guī)整各種狀態(tài)數據結構，建設開發(fā)規(guī)范，梳理開發(fā)文檔
- 應用層+業(yè)務層：將應用層的代碼和業(yè)務層的抽象進行對應，支持路由和分包的自動化配置，支持按需構建要開發(fā)的單頁面，這樣從源頭上解決了要構建編譯大量代碼而引起的編譯耗時長的問題
同時團隊進行了歷史問題梳理，文檔建設，數據體系梳理等，將以往阻塞開發(fā)的問題一一掃除，最終開發(fā)效率得以提升 50% ~ 80%
三、解決場景構造難
對于小程序開發(fā)中很多頁面強依賴人工操作和嚴重缺失前端數據體系這樣的問題，我們通過
- 建立本地數據體系，前后端分離
- 區(qū)分開發(fā)環(huán)境和生產環(huán)境請求域名
- 開發(fā)環(huán)境下支持配置請求的域名，請求轉發(fā)，支持切換請求環(huán)境
- 生產環(huán)境下則請求線上環(huán)境
我們可以看下改造前后的前后端交互和開發(fā)模式上的一些不同點
前后端分離，徹底解決原來前后端強耦合情況
自建前端數據體系中心， 開發(fā)頁面直達 ，免除諸多人工操作進行場景復現等繁瑣流程
參考：
https://github.com/chameleon-team/cml-best-practice/tree/master/mock
四、解決編譯耗時長
【編譯層適配優(yōu)化】
編譯耗時長的根源是【框架編譯】+【開發(fā)者工具編譯耗時】
編譯層的優(yōu)化，并不能大幅度提升開發(fā)效率
【業(yè)務層適配優(yōu)化】
那么業(yè)務層是否能夠有優(yōu)化手段呢？
根據上面的分析可以看到，當我們所有的業(yè)務代碼全部參與構建的時候，會嚴重影響框架編譯的速度和開發(fā)者工具二次編譯的速度，能否從業(yè)務層，對各個模塊進行拆分，獨立構建呢？
業(yè)務層原來的構建模式：
所有的業(yè)務代碼都參與構建，各個模塊之間強耦合，前后端強耦合，每次構建極為耗時，嚴重影響開發(fā)效率、開發(fā)體驗，甚至影響開發(fā)進度。
業(yè)務層優(yōu)化后的構建模式:
依賴于自建前端數據中心，前后端分離，使得前端頁面可以以“微型前端應用”的思想進行單獨構建，大大減少了要編譯構建的內容，大幅度提高了開發(fā)效率。
參考
https://github.com/chameleon-team/cml-best-practice/blob/master/dev-optimize.js
基本的思路就是通過腳本自動化配置要參與構建的路由，每次開發(fā)的時候只將要開發(fā)的頁面配置到路由表中，這樣可以大大降低要參與構建的內容。
最終，我們的編譯耗時問題得以有效地解決
以上介紹了基本的實現思路和優(yōu)化方案，同時我也整理了一個簡單實現案例，方便給大家參考
https://github.com/chameleon-team/cml-best-practice
五.總結
日常開發(fā)中，我們面臨的問題無非是 開發(fā)提效、業(yè)務開發(fā)、性能優(yōu)化 等
其中 開發(fā)效率 會直接影響后續(xù)的 業(yè)務開發(fā)以及性能優(yōu)化 等后續(xù)工作。
日常開發(fā)中的效率提升要重點注意和優(yōu)化， 任何阻塞開發(fā)的流程和痛點問題都要及時解決 ，絕對不要忍受項目開發(fā)中的各種低效率問題， 萬不可聽之任之， 等到項目復雜龐大到無法變更、無法優(yōu)化、甚至無法開發(fā)的地步，那個時候再想去優(yōu)化開發(fā)效率將會更加棘手。
作者:王夢君
微信公眾號:滴滴順風車技術
出處:https://mp.weixin.qq.com/s/M1VArJ_ORY-eXSKzD6ysQw
