Open qiuhongbingo opened 4 years ago
与以往相比,今年明显感觉到项目的迭代速度又快了不少,这里总结了几个方面:
实际上,在 QQ 小程序放出内测消息的时候,团队内部就已经有了想法,毕竟 QQ 小程序的用户属性和我们的产品是匹配的,当然最终也顺利地在公测阶段上架了我们的第一个 QQ 小程序
这里从技术上看,开发一个 QQ 小程序其实都不难,与目前市面其他小程序平台如支付宝、百度、字节跳动一样,语法、API 等都与微信大同小异,借助目前成熟的多端技术或者直接拷贝微信端的代码做适配都能满足
想想其实满幸运,在 QQ 小程序公测阶段,团队的技术框架恰好也完成了从原生到 uni-app 的迁移工作,这是个好消息,意味我们不需要通过拷贝代码来适配 QQ,做到了一套代码实现多端,多好的节奏呀
本以为能休息一会,每天摸摸鱼等下班,结果。。。
虽然技术上做到了多端适配,但神奇的业务总是会不满足,我举个场景:
怎样,你经历过绝望吗,丧心病狂吗,要不是产品经理是小姐姐,我就。。。
之所以会说这是个挑战,最大的原因也是当时团队只有一个前端开发,而会有这种需求,想想也不奇怪,无非都是抢流量,最大化利用流量,所以便有了模块复用的尝试
npm package 和 git submodule 是我们列出来仅有的两种方案,考虑到便利性我们最终选择了后者,我们在采用 git submodule 方案的时候,也由于追求更高的便利性选择了单一仓库
对我们的业务,模块可拆成两种:
这里是 apps 其实就是上面举例场景的 a、b、c 功能,严谨的做法是 a、b、c 是三个独立的 git 仓库,而这里我们考虑到业务模块会很细,为了方便管理就放到一起
基础模块和业务模块下又都有各自的可复用模块:
最终模块项目结构长这样
模块项目有了就可以开始开发模块
例如我们的主项目是 weapp,那么在主代码仓库里面创建子模块引用,执行以下指令即可
git submodule add git@gitee.com:test/module.git uniapp/A/src/modules
这样,在我们主项目就引入了整个可复用的模块,以 uni-app 为例长这样:
可能你会问,这样不就实现不了按需加载,全部引入了会导致项目体积变大吗?
实际上,uni-app 依赖的 webpack 在构建时只会打包项目 import 的模块,所以不用担心体积问题
例如我的 A 小程序有个 /pages/ex/test/index/index 页面,那么这个页面的功能就是一个放在 module 项目的页面模块,而对于 A 小程序来说,只需要通过 vue component 的方式引入
这样的好处是 B 小程序也可以用同样的方式使用这个页面模块
简而言之就是,我们大部分的业务代码都放在模块项目各自的业务模块里,主项目只负责页面路径、数据状态的管理
有了模块项目,实现多人协作开发模块就比较简单了
当自己或其他开发要 push 模块的时候,需注意确保当前是在模块目录下再提交
cd your_app/modules git checkout master git add . git commit -m "balabala..." git push orgin master
当自己要使用其他人开发的模块时,可以使用 foreach 循环指令,更新 master 分支,也可以单独 cd 到模块目录执行 git pull
git submodule foreach 'git checkout master;git pull'
双剑合璧必能上班摸鱼
在小程序项目又呆了一年
与以往相比,今年明显感觉到项目的迭代速度又快了不少,这里总结了几个方面:
实际上,在 QQ 小程序放出内测消息的时候,团队内部就已经有了想法,毕竟 QQ 小程序的用户属性和我们的产品是匹配的,当然最终也顺利地在公测阶段上架了我们的第一个 QQ 小程序
这里从技术上看,开发一个 QQ 小程序其实都不难,与目前市面其他小程序平台如支付宝、百度、字节跳动一样,语法、API 等都与微信大同小异,借助目前成熟的多端技术或者直接拷贝微信端的代码做适配都能满足
一件幸运的事和一件挑战的事
想想其实满幸运,在 QQ 小程序公测阶段,团队的技术框架恰好也完成了从原生到 uni-app 的迁移工作,这是个好消息,意味我们不需要通过拷贝代码来适配 QQ,做到了一套代码实现多端,多好的节奏呀
本以为能休息一会,每天摸摸鱼等下班,结果。。。
虽然技术上做到了多端适配,但神奇的业务总是会不满足,我举个场景:
怎样,你经历过绝望吗,丧心病狂吗,要不是产品经理是小姐姐,我就。。。
之所以会说这是个挑战,最大的原因也是当时团队只有一个前端开发,而会有这种需求,想想也不奇怪,无非都是抢流量,最大化利用流量,所以便有了模块复用的尝试
模块复用的调研
npm package 和 git submodule 是我们列出来仅有的两种方案,考虑到便利性我们最终选择了后者,我们在采用 git submodule 方案的时候,也由于追求更高的便利性选择了单一仓库
模块复用的设计
对我们的业务,模块可拆成两种:
基础模块和业务模块下又都有各自的可复用模块:
最终模块项目结构长这样
模块的开发
模块项目有了就可以开始开发模块
如何创建模块
例如我们的主项目是 weapp,那么在主代码仓库里面创建子模块引用,执行以下指令即可
这样,在我们主项目就引入了整个可复用的模块,以 uni-app 为例长这样:
可能你会问,这样不就实现不了按需加载,全部引入了会导致项目体积变大吗?
实际上,uni-app 依赖的 webpack 在构建时只会打包项目 import 的模块,所以不用担心体积问题
如何使用模块
例如我的 A 小程序有个 /pages/ex/test/index/index 页面,那么这个页面的功能就是一个放在 module 项目的页面模块,而对于 A 小程序来说,只需要通过 vue component 的方式引入
这样的好处是 B 小程序也可以用同样的方式使用这个页面模块
简而言之就是,我们大部分的业务代码都放在模块项目各自的业务模块里,主项目只负责页面路径、数据状态的管理
多人协作
有了模块项目,实现多人协作开发模块就比较简单了
如何提交模块
当自己或其他开发要 push 模块的时候,需注意确保当前是在模块目录下再提交
如何更新模块
当自己要使用其他人开发的模块时,可以使用 foreach 循环指令,更新 master 分支,也可以单独 cd 到模块目录执行 git pull
总结