今天应做的事没有做，明天再早也是耽误了。——裴斯泰洛齐
介绍
最近一直在使用淘宝小程序的技术栈，淘宝为开发者提供了IDE工具，我们按照相应的文档规范编写代码，就会被实时的编译，安装了依赖也会立马被检测到运行。但是我们公司现在一直使用的是内部的一个脚手架工具，这个脚手架工具使用是通过gulp任务流，创建一个client-dev的目录作为开发者目录，进行配置一些额外的工具或者预处理器，然后打包生成一个client目录是真正的小程序IDE识别的代码。类似把client-dev下的文件克隆一份变成client，然后把相应目录下的ts或者less处理成为js还有css，这种也会存在一定的延时，修改代码太多也不能实时生效。虽然可以使用自己定义的一些东西。每次运行前必须得先使用命令进行启动，然后开发者工具才会实时编译。 使用脚手架的好处是可以使用各种一些先进的前端技术在里面，但是坏处也是显而易见的，每次点击上传代码时必须得启动命令否则修改的代码可能不会被编译上传到小程序版本管理，到时候发到线上会出现事故。如果用小程序规范来编写一般实时编译改过后立马会把问题暴露出来。随着发展淘宝小程序也会支持更多的特性来供开发者使用，这个时候脚手架就比较显得鸡肋，所以这次就放弃了使用老的脚手架工具。新模板主要是对这块使用淘宝开发者工具做一个开发的规范，使后面的项目更加规范化。
梳理底层一些通用的逻辑
我们这边的淘宝小程序都是一些通用的活动，这些活动会有很多公共的逻辑在里面，比如说活动配置、统一会员登录等。最近是一边了解淘宝小程序方向的业务。一边梳理业务，一边学习这些项目中遇到的一些技术，我们的互动小程序，我刚看代码的时候，说实话我有很多地方都不明白的，比如说如何跳转到一个活动，很多时候都是在遇到问题的时候，去探索的时候才发现原来是这么回事情。在探索的路上，我遇到了这样的业务场景，但是我不知道这些逻辑是怎么回事，因为我看了上层代码这些逻辑里面没有这部分业务的实现，所以我开始了看一些用到的底层包逻辑到底是什么样的。
我看的第一个底层通过的工具包是"member-center-utils"这个包，这个包中封装了整个互动业务的一些公共的核心业务逻辑，这些包中有最重要的方法就是membcerLifeCyle 与appConfig方法还有pageClass还有http这个方法。memberLifceCyle获取绑定会员的信息方法、appConfig 是绑定当前活动配置参数的方法，在初始化的时候会被每个活动调用，还有http为前后端交互的方法。pageClass工作是重写每个Page添加公共参数和方法。看了这个代码以后我感觉这几个方法之间的相辅相成环环相扣的，当时写这个的代码的人是真的用心写了。当我现在接手这个项目的时候也非常的好接手，非常感谢。
- appConfig这个方法
具体流程如下图：
思路非常清晰，当然了appconfig中还有一些私有属性get、host等方法这里就不一一介绍了，分享一下别人值得学习的地方。
- membcerLifeCyle
其中涉及到了如checkCompleteUserInfoNew的一些核心方法，这些方法会根据前后端交互的一些业务逻辑对用当前的页面进行一个跳转。
- http http层中是使用淘宝请求的一个方法，在这个方法中我们以前老的埋点就集成在了里面，这其中也是的老埋点在新模板总也是被我清理掉了，其中原因是因为老埋点的一些痛点非常多导致我们统计的数据不是很完善，对我们现有产品形成体系化的一个阻碍，所以我们后期开发了新的埋点平台。
- pageClass
使用pageClass定义的页面都会可以访问到appconfig上的所有方法。这个方法我觉得是非常适合这个业务场景的，看到了这个我是学习到了。
当然除了以上这些方法还有很多其他的一些都挺的，但是有些已经不适用于当前的业务开发场景了所以就要被剔除掉了，最重要的就是新埋点平台的进入非常重要。
淘宝小程序的模板规范
规范的目的是为了编写高质量的代码，现代软件架构的复杂性需要协同开发完成，无规范难以协同，所以有一份规范来这样大家的代码开发模式都一样，这样开发或者维护都非常省时省力。这是我感触非常深的事情。如果没有规范来约束代码将会出现各种问题。比如难以确定模板与路由之间的关系，哪些是共用的包，哪些是共用的组件，如果不明确的话都会四处引用导致项目后来变得越来越复杂，难以维护。
- 命名规范 项目名称：first-second 例如：merchant-config
视图文件：小驼峰 例如： myGift
组件命名：小驼峰 例如： myGift 使用
- 模板结构
├── components //通用组件
│ ├── compDemo
│ │ ├── compDemo.acss
│ │ ├── compDemo.axml
│ │ ├── compDemo.js
│ │ └── compDemo.json
├── pages // 视图文件
│ ├── pageDemo
│ │ ├── pageDemo.acss
│ │ ├── pageDemo.axml
│ │ ├── pageDemo.js
│ │ └── pageDemo.json
├── service // http请求文件
│ ├── request.js
├── store // 共用数据文件
│ └── index.js
└── styles // 公共样式
│ ├── animate.css
│ │ ├── _base.acss
│ │ ├── bouncing_entrances
│ │ │ └── bounceIn.acss
│ │ ├── fading_entrances
│ │ │ ├── fadeIn.acss
│ │ │ └── fadeInUp.acss
│ │ └── zooming_entrances
│ │ └── zoomIn.acss
│ └── icon.acss
├── lib // 基础库
│ ├── buridPoints.js
│ ├── getuuid.js
│ ├── pageClass.js
│ └── utils.js
├── mini.project.json // 小程序项目兼容文件
├── package-lock.json
├── package.json // 项目依赖
├── README.md // 项目说明
├── CHANGELOG.md // 重要修改说明 日期+改动
├── app.acss // 项目初始化样式入口
├── app.js // 项目初始化入口
├── app.json // 页面路由配置
├── env.js // 环境
├── .gitignore // git配置文件
├── ext.json // 配置文件
└── .editorcofig // 编辑器配置
- 提交规范 用于说明 commit 的类别，只允许使用以下 7 个标识：
- feat：新功能（feature）
- fix：修补 bug
- docs：文档（documentation）
- style：格式（不影响代码运行的变动）
- refactor：重构（不是新增的功能，也不是修改 bug 的代码变动）
- test：增加测试
- chore：构建过程或辅助工具的变动 通常 feat 和 fix 会被放入 changelog（变更日志） 中，其他类型则不会。
使用方式
我们内部的话有一套cli脚手架生成工具，把生成的模板与cli工具关联起来就可以使用了。每次安装也特别方便，使用命令就可以安装。
- 使用git仓库来存储 使用git来存储模板这样大家用的时候可以直接到git仓库上克隆下来了。然后安装相应的依赖即可。
- 使用内部cli工具 使用内部cli工具来进行操作，前提是团队内部有这样的基建工具。这样的话就非常便捷，只需要全局安装后就可以轻松使用命令的方式来安装了。
总结
接手淘宝小程序这边差不多有一个月左右的时间了，模板这方面还是有很多需要改进的地方，目前的话就先到这里，后期不忙会做更多优化，比如说常用的一些代码校验的配置，目前淘宝IDE是否拥有像VSCODE一样强大支持实时的代码报错提醒之类的东西，但是后期我会持续跟进。
