當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

大型程序是如何开发的_大型小程序如何研发提效

發(fā)布時間：2023/12/3 编程问答 38 豆豆

生活随笔收集整理的這篇文章主要介紹了大型程序是如何开发的_大型小程序如何研发提效小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

作者:王夢君

微信公眾號:滴滴順風(fēng)車技術(shù)

出處:https://mp.weixin.qq.com/s/M1VArJ_ORY-eXSKzD6ysQw

導(dǎo)讀：

自2016年小程序誕生以來，小程序以其“用完即走”的設(shè)計理念，以及簡單易上手的開發(fā)模式，吸引了大批的小程序使用者以及開發(fā)者，隨著小程序市場越來越大，相應(yīng)的小程序開發(fā)者也越來越多,與此同時出現(xiàn)的各類小程序開發(fā)第三方框架也層出不窮。

一、小程序開發(fā)模式

小程序開發(fā)模式整體來說有兩種，一種是原生小程序開發(fā)，一種是第三方框架開發(fā)。

整體來看小程序原生開發(fā)只能適配在對應(yīng)的單獨App中運行，不能提供比較全面的可以跨多端的開發(fā)能力，在有多端小程序應(yīng)用需求的情況下，比較浪費人力

另外一種方案則是利用跨端框架，這種方案開發(fā)的應(yīng)用一般可以達(dá)到“一套代碼，多端運行”的基本目標(biāo)，可以大量的節(jié)省人力，提高效率。

跨端框架開發(fā)小程序固然有很多優(yōu)點，但是這種開發(fā)模式也會有一些問題，比如核心問題就是編譯耗時長、開發(fā)體驗差、前后端耦合等

本篇文章主要分享使用 Chameleon 框架在開發(fā)業(yè)務(wù)小程序應(yīng)用過程中遇到的痛點問題，以及如何解決的心路歷程。

同時也歡迎大家多多關(guān)注我們，Github地址：https://github.com/didi/chameleon

二、業(yè)務(wù)開發(fā)面臨的痛點問題

1.業(yè)務(wù)開發(fā)面臨的痛點問題

我們在小程序開發(fā)中遇到的痛點問題主要包括兩方面

場景構(gòu)造難：強依賴后端接口和手動操作流程
編譯耗時長：第三方框架編譯和開發(fā)者工具編譯耗時極長

【場景構(gòu)造難】

我們的業(yè)務(wù)開發(fā)中很多場景，包括發(fā)單場景、收到邀請場景、等待車主邀請場景、被多個車主邀請場景、各種管控策略場景等，都強依賴后端接口以及強依賴人工操作某些流程,從乘客發(fā)單到被車主接單，需要乘客賬號、車主賬號(某些場景下需要多個手機多個賬號)進行協(xié)助構(gòu)造某些場景，甚至很多情況下，構(gòu)造場景耗時間占用開發(fā)50%的時間，嚴(yán)重影響開發(fā)流程和開發(fā)效率。

極端情況下，可能幾十行代碼的增減，就需要耗費一天的時間，大量的人力浪費在構(gòu)造場景、多個手機發(fā)單接單等等本不應(yīng)該有的流程上，令人痛苦不堪。

【編譯耗時長】

從開發(fā)者第一次啟動項目開發(fā)，到編碼之后保存熱更新編譯，Chameleon框架編譯的源碼在小程序開發(fā)者工具會再次消耗編譯耗時。

小程序原生開發(fā)過程中，編譯耗時主要集中在 小程序開發(fā)者工具 這一個過程。

而第三方框架開發(fā)，編譯耗時則主要集中在 框架編譯 + 小程序開發(fā)者工具 這兩個過程。

同時 第三方框架編譯的源碼的大小 也會直接的影響 小程序開發(fā)者工具編譯耗時

對于編譯耗時長的問題，特別是前端開發(fā)而言，需要實時查看代碼變更到UI的效果，多次保存就會多次構(gòu)建，即使僅僅寫了一行代碼，甚至一個空格的變更，保存之后都會引起重新編譯

這個編譯是讓很容易讓人抓狂和崩潰的，最寶貴的開發(fā)時間都浪費在了等待上，項目再緊急也要等著這些令人難以忍受的編譯過程一直轉(zhuǎn)圈圈，嚴(yán)重影響開發(fā)效率，嚴(yán)重浪費人力成本，嚴(yán)重影響項目進度。

2.如何解決業(yè)務(wù)上的痛點問題？

針對場景構(gòu)造難的問題，核心原因是

前后端強耦合，各種場景強依賴開發(fā)人員人工操作復(fù)現(xiàn)
前端缺少基本的數(shù)據(jù)體系建設(shè)，對于各種場景的后端數(shù)據(jù)結(jié)構(gòu)缺少基本的收集規(guī)整

針對編譯耗時長的問題，核心原因是

從代碼開發(fā)到小程序開發(fā)者工具展示要經(jīng)歷框架編譯和小程序開發(fā)者工具編譯兩個過程
對于業(yè)務(wù)代碼量大的情況下，編譯的文件個數(shù)和文件體積會更多更大，同時會進一步影響這兩個構(gòu)建編譯的耗時

那么如何解決上述核心痛點問題呢？

我們團隊采用了 "微型前端應(yīng)用" 這樣的思路進行單點突破，化解面臨的棘手問題，逐個擊破，成功的解決了開發(fā)效率極低，人力成本極為浪費，開發(fā)體驗極差的情況。

3.解決方案

服務(wù)層：構(gòu)建本地數(shù)據(jù)體系，規(guī)整各種狀態(tài)數(shù)據(jù)結(jié)構(gòu)，建設(shè)開發(fā)規(guī)范，梳理開發(fā)文檔
應(yīng)用層+業(yè)務(wù)層：將應(yīng)用層的代碼和業(yè)務(wù)層的抽象進行對應(yīng)，支持路由和分包的自動化配置，支持按需構(gòu)建要開發(fā)的單頁面，這樣從源頭上解決了要構(gòu)建編譯大量代碼而引起的編譯耗時長的問題

同時團隊進行了歷史問題梳理，文檔建設(shè)，數(shù)據(jù)體系梳理等，將以往阻塞開發(fā)的問題一一掃除，最終開發(fā)效率得以提升 50% ~ 80%

三、解決場景構(gòu)造難

對于小程序開發(fā)中很多頁面強依賴人工操作和嚴(yán)重缺失前端數(shù)據(jù)體系這樣的問題，我們通過

建立本地數(shù)據(jù)體系，前后端分離
區(qū)分開發(fā)環(huán)境和生產(chǎn)環(huán)境請求域名
- 開發(fā)環(huán)境下支持配置請求的域名，請求轉(zhuǎn)發(fā)，支持切換請求環(huán)境
- 生產(chǎn)環(huán)境下則請求線上環(huán)境

我們可以看下改造前后的前后端交互和開發(fā)模式上的一些不同點

前后端分離，徹底解決原來前后端強耦合情況

自建前端數(shù)據(jù)體系中心， 開發(fā)頁面直達(dá) ，免除諸多人工操作進行場景復(fù)現(xiàn)等繁瑣流程

參考：

https://github.com/chameleon-team/cml-best-practice/tree/master/mock

四、解決編譯耗時長

【編譯層適配優(yōu)化】

編譯耗時長的根源是【框架編譯】+【開發(fā)者工具編譯耗時】

編譯層的優(yōu)化，并不能大幅度提升開發(fā)效率

【業(yè)務(wù)層適配優(yōu)化】

那么業(yè)務(wù)層是否能夠有優(yōu)化手段呢？

根據(jù)上面的分析可以看到，當(dāng)我們所有的業(yè)務(wù)代碼全部參與構(gòu)建的時候，會嚴(yán)重影響框架編譯的速度和開發(fā)者工具二次編譯的速度，能否從業(yè)務(wù)層，對各個模塊進行拆分，獨立構(gòu)建呢？

業(yè)務(wù)層原來的構(gòu)建模式：

所有的業(yè)務(wù)代碼都參與構(gòu)建，各個模塊之間強耦合，前后端強耦合，每次構(gòu)建極為耗時，嚴(yán)重影響開發(fā)效率、開發(fā)體驗，甚至影響開發(fā)進度。

業(yè)務(wù)層優(yōu)化后的構(gòu)建模式:

依賴于自建前端數(shù)據(jù)中心，前后端分離，使得前端頁面可以以“微型前端應(yīng)用”的思想進行單獨構(gòu)建，大大減少了要編譯構(gòu)建的內(nèi)容，大幅度提高了開發(fā)效率。

參考

https://github.com/chameleon-team/cml-best-practice/blob/master/dev-optimize.js

基本的思路就是通過腳本自動化配置要參與構(gòu)建的路由，每次開發(fā)的時候只將要開發(fā)的頁面配置到路由表中，這樣可以大大降低要參與構(gòu)建的內(nèi)容。

最終，我們的編譯耗時問題得以有效地解決

以上介紹了基本的實現(xiàn)思路和優(yōu)化方案，同時我也整理了一個簡單實現(xiàn)案例，方便給大家參考

https://github.com/chameleon-team/cml-best-practice

五.總結(jié)

日常開發(fā)中，我們面臨的問題無非是 開發(fā)提效、業(yè)務(wù)開發(fā)、性能優(yōu)化 等

其中 開發(fā)效率 會直接影響后續(xù)的 業(yè)務(wù)開發(fā)以及性能優(yōu)化 等后續(xù)工作。

日常開發(fā)中的效率提升要重點注意和優(yōu)化， 任何阻塞開發(fā)的流程和痛點問題都要及時解決 ，絕對不要忍受項目開發(fā)中的各種低效率問題，萬不可聽之任之，等到項目復(fù)雜龐大到無法變更、無法優(yōu)化、甚至無法開發(fā)的地步，那個時候再想去優(yōu)化開發(fā)效率將會更加棘手。