经验总结--个人小程序开发和进化之路

前言

从接触小程序开始，到如今大大小小作了差很少有五六个小程序项目了，小项目的只有几个页面，大的项目有几十个页面。此篇文章是对以前项目的一个总结，项目的脚手架，开发框架和后期的优化是一个逐渐进化完善的过程，若是你打算开发小程序或者已经在开发小程序，相信这些经验对你会有必定的帮助。

脚手架

小程序开发者工具能够直接编写小程序的，可是开发工具就像武士手中的剑，多年磨炼，已经达到人剑合一了，忽然换把武器，那势必影响杀敌效率，因此使用本身熟悉的开发工具仍是颇有必要的。

本人所在的公司基本都是中小型公司，项目开发周期都很短，前期的准备工做最多也就几天时间，因此本身去撸一套脚手架而后用于项目开发，难度比较大，在网上找优质的资源是最好的选择。

大佬justjavac的开源项目 微信小程序开发资源汇总，涵盖了大量的优质小程序开发资源，在此推荐一波。

固然，脚手架的选择也是视项目而定的，若是只有几个页面的项目，搞一套很重的工具未免有点多此一举了。咱们的作法是小项目，直接撸，大点的项目选用网络上的优质资源+本身改写。

1. 17年的电商项目，模块很少，采用的脚手架比较简单，使用gulp监听文件改动，实时编译，支持ES6+语法。

• 脚手架地址

2. 18年中旬的电商项目，到了新的公司，当时选用了WePY进行开发，特性简单介绍下：

• 类Vue的开发风格
• 组件化开发（WePY出来的时候，小程序还不支持组件）
• 支持加载外部NPM包(小程序原生也支持)
• 使用babel编译，支持ES6/7的语法
• 针对原生API进行优化

详细介绍请点击WePY文档进行查看，后续框架选择上也会提到，差点被这框架害惨了。

3. 最近的一个地产项目，也是下一个项目打算使用的，weapp-start，上文提到的小程序开发资源汇总中也有提到，特性以下：

• 支持 npm 包引入
• 支持 promise, async/await 等最新语法
• 支持多种编译器，如 pug/less/stylus
• 支持 ESlint
• 支持本地 mock 数据
• 支持一键生成项目，组件模版
• 支持发布前资源压缩
• 支持自定义插件
• 多种工具，加速开发

项目的地址为weapp-start，其中weapp-plugin-require（分析依赖，导入第三方 npm） ，存在问题，window操做系统会出现路径错误，我已修复，并给做者提了PR，但做者并无修复这个问题，若是有同窗要用到这个脚手架，请下载我修改好的文件进行替换，下载地址。

另推荐我根据weapp-start搭建的环境，目录结构为：

├── README.md                 // 说明文档
├── dist                      // 编译后的代码，用小程序开发工具打开此文件夹
├── mock.js                   // 模拟数据的文件
├── package-lock.json
├── package.json
├── project.config.json       // 项目配置文件
├── src                       // 项目代码都在这个文件夹下
│   ├── app.js                // 等同于小程序根目录下的app.js
│   ├── app.json              // 等同于小程序根目录下的app.json
│   ├── app.wxss              // 等同于小程序根目录下的app.wxss
│   ├── assets                // 项目中使用到的静态资源
│   │   └── images
│   │       ├── example
│   │       └── tab
│   ├── components            // 公用的组件
│   ├── page                  // 存放小程序的各个页面文件
│   │   ├── example           // example 页面
│   │   │   ├── components    // example页面中的组件
│   │   │   ├── index.js
│   │   │   ├── index.json
│   │   │   ├── index.wxml
│   │   │   ├── index.wxss
│   │   │   ├── services      // example页面中接口
│   │   │   ├── template      // example页面中的模板
│   │   │   └── wxs           // example页面中的wxs文件
│   │   ├── globalStore.js    // 全局共享的数据
│   │   └── test
│   │       ├── index.js
│   │       ├── index.json
│   │       ├── index.wxml
│   │       └── index.wxss
│   ├── template              // 公用的模板
│   └── utils                 // 公用的方法或工具
│       ├── config.js         // 全局的一些配置信息
│       ├── create.js         // 状态管理插件
│       ├── mitt.js           // 状态管理插件
│       ├── obaa.js           // 状态管理插件
│       ├── util.js           // 公用方法
│       ├── wxRequest.js      // 封装的小程序请求数据方法
│       └── wxapi.js          // 对小程序api进行Promise封装
└── weapp.config.js           // 对脚手架的配置文件
复制代码

项目地址为点击查看，以为有用的请Star或者fork哟。

固然，网上也有不少优秀的脚手架，你们能够根据本身的须要选择哟。

小程序开发框架

17年的项目并无使用开源的框架，直接使用原生小程序写的，开发过程印象中并无不少的坑，只记得当时用到了一个富文本的插件，wxParse，如今已5000多个Star了，虽然如今小程序有了富文本组件rich-text，但在最近的项目中仍是用了这个插件，由于后端的兄弟说，他们不能将html转成rich-text须要的数据格式，后端是java的，有使用这个组件的同窗，麻烦下面留个言，我要去鄙视后端一下。

前文提到本身在项目开发过程当中使用过WePY框架，那么下面我就简单列一下如今比较火热的三大小程序框架WePY，mpvue和Taro的特性，而后着重说下WePY：

1. mpvue（美团）

• 完全的组件化开发能力：提升代码复用性
• 完整的 Vue.js 开发体验
• 方便的 Vuex 数据管理方案：方便构建复杂应用
• 快捷的 webpack 构建机制：自定义构建策略、开发阶段 hotReload
• 支持使用 npm 外部依赖
• 使用 Vue.js 命令行工具 vue-cli 快速初始化项目
• H5 代码转换编译成小程序目标代码的能力

2. taro （京东）

• React 语法风格
• 支持使用 npm/yarn 安装管理第三方依赖。
• 持使用 ES7/ES8 甚至更加新的 ES 规范，一切均可自行配置。
• 持使用 CSS 预编译器，例如 Sass 等。
• 持使用 Redux 进行状态管理。
• 持使用 Mobx 进行状态管理。
• 程序 API 优化，异步 API Promise 化等等。

3. WePY （腾讯）

上文已列出，此处再也不赘述

三大框架分别是国内三家大佬的前端团队产物，印象中mpvue和taro都是18年下半年出来的，WePY出来的最先，几乎和小程序同步。

mpvue拥抱了vue，taro拥抱了react，WePY握住了vue的手，mpvue和taro都没有用过，咱们只是开发个小程序，不用作到H5和RN共用一套代码，因此18年中开发的一个电商小程序选择了WePY，毕竟腾讯的产物，亲儿子。

后来了解到，是腾讯的儿子没错，不过是养子，WePY原本是腾讯内部一员工的我的项目，后来腾讯团队看这个项目不错，就由官方来维护了，由此带来了一些问题，曾在掘金看到过对WePY做者的专访（好像是专访，文章我找不到了），做者本身也认可，WePY前期的一些核心代码存在的缺陷，后期很难修复了，像脏检查机制，听说2.0会有很大的改变。

贴一张WePY其中的一个Issue，咱们当时的心情和他是同样同样的，不过咱们不用重构了，项目死掉了，哈哈哈哈（悲凉的笑）

本身曾经写过一篇wepy+weappx开发小程序遇到的坑以及解决方案，文中列举了开发过程当中遇到的一些问题和解决方式，在此就不赘述了，想了解的同窗能够点击查看。

若是你要问我开发小程序选择那个框架合适？我只能给出一个建议，根据需求来定，若是只是单纯的想作个小程序，就不要用框架了，小程序的语法目前已经很完善了，何须要去学习两套语法呢，出了问题，又改不动他们框架，一句话归纳下就是，小程序原生有的问题他们确定有，原生没的问题，他们可能给你造出来。

固然，若是有写一套代码适用H5和RN,那么能够考虑下mpvue和taro，做者更新很频繁，有团队维护，至于能不能提升效率，还得看需求，咱们如今是不会选用任何框架了，小程序已经玩的很熟，不必再折腾了。

小程序开发建议

在开发过程当中，咱们总结了一些感受比较好的开发实践，在此奉献一波，大佬别笑哈。

1. 目录结构

上文中脚手架第三项中贴出的目录结构，是目前咱们以为比较好的一种形式（参照umi项目的建议），按页面组织代码，将一个页面所须要的内容放在同一个文件夹，方便往后的维护和有相似页面开发时候的复制，存在公用组件的时候，放到外部的文件夹中，当一个项目大了之后，这种目录结构，真的很方便。

2. 组件的层级

组件的层级真的不能太深，2层最好，不能超过3层，以前项目有的封装组件过分，层级太深，后期维护，根据数据传递一层层的去找代码，简直不要太爽（反话）。

3. 状态管理

目前小程序能用的状态管理框架也是比较多的，Redux，Mobx，还有基于Redux二次开发的像weappx，都很好，在这推荐两个本身用过和打算用的，使用过的weappx，打算用的omi-mp-create，项目比较小能够不用，大项目仍是用上吧，都放到global中，很差维护。

4. 频繁setData的功能放到组件中

电商项目中，少不了相似倒计时这种功能的，像这种须要频繁setData操做的功能，应该单独放到一个组件中，为啥呢？当你setData的时候，小程序会有一个遍历监听了data数据方法的过程，好比当你setData的时候，小程序wxs中的函数都会执行，在我上文提到本身的脚手架中有这个例子weapp-quick-start，感兴趣的能够测试一下。

5. 使用WXS

小程序对js表达式的支持并非很好，固然，就算能够，我也曾见过这样的代码

<block wx:if="{{drawgift.giftDetail.virtualGoods.length>1||((drawgift.giftDetail.realGoods.length>0||drawgift.giftDetail.couponGoods.length>0)&&drawgift.giftDetail.virtualGoods.length>0)}}">

复制代码

把这些判断的逻辑放到wxs中，统一维护岂不是美哉。还有一点，官方说在 iOS 设备上小程序内的 wxs 会比 javascript 代码快 2 ~ 20 倍，因此，能用仍是要用起来的。

6. 控制包的大小，分包加载等

不用的包，别偷懒，通通删掉，至于分包加载等，推荐看下这篇文章，我就不啰嗦了微信小程序：一些运行细节及针对性的优化策略

结语

文章中涉及到的具体的技术点很少，更多的是对走过的路的一种回顾，以为有帮助的童鞋，点个👍哟！

参考资料

• WePY文档
• mpvue文档
• taro文档