APPID开发环境和H5开发一样，**件事当然是先注册一个小程序

菏泽炫佑科技 菏泽炫佑小程序开发 菏泽炫佑app制作 炫佑科技

APPID开发环境和H5开发一样，**件事当然是先注册一个小程序

一切的开始

开发小程序，首先当然是注册小程序。

小程序注册

点击箭头注册，按照界面提示即可完成注册。

注册完成后，您可以获得我们的**个重要道具--APPID

开发环境

和H5开发一样，开发小程序也需要搭建开发环境。 对于微信小程序开发来说，*重要的环境就是微信官方提供的微信开发工具。

点击界面中间*大的+号，即可进入小程序新界面。

只需要在上图箭头处填写我们刚刚申请的小程序的APPID，就会自动生成一个内置官方模板的小程序。

至此，我们已经迈出了开发小程序的**步。 但这个时候你千万不要急于敲代码。 事实上，有很多事情比直接开始编码更重要。

达成共识

一般来说，开发离不开协作，而协作*重要的是与伙伴的默契。 这种默契来自于大家的共同认识。

只有大家对项目的理解处于同一水平上，整个开发协作才能向积极的方向发展。

目录结构规范

不要低估我们每个文件和文件夹的命名和分布。 随着项目的扩展，有规范目录结构的项目和没有规范的项目会有完全不同的感受。

在讲目录结构之前，我们先简单了解一下小程序包体的概念。

因为微信对主包的大小有限制，所以我们当然不应该把所有逻辑都放在主包中。

主包和子包有非常明显的区别。 子包可以引用主包中的所有内容，但子包之间不能互相引用。 这是注定的。 我们的通用逻辑必须在main包中。 同时，还可以得出另一个结论——业务逻辑可以放在不同的分包中，也就是下图。 （什么是页面？）

图中还有一个比较奇怪的说法，分包中的公共组件库是什么？ 不是所有的通用组件都应该放在主包中吗？

其实在实际开发中，由于各个业务的差异，并不是每一个我们认为可以公开使用的组件就一定会被所有人使用。 因此，笔者认为，如果是该业务的公共组件，应该首先放在分包中。 如果其他业务确实有需求，我们可以对其组件进行升级使用vue开发微信小程序，移至主包中，统一更改原来的分包。 参考文献在 .

独立分包在开发中很少用到，这里就不过多介绍了。

现在大家应该对小程序的包体有了一定的了解。 实际开发中我们应该如何规划目录结构呢？ 这里作者只是简单介绍一下，并举了一个非常简单的例子来大致表达作者的想法。

首先我们看一下**层，也就是我们的根目录。 为什么要用app文件夹来包裹真正的小程序内容呢？ 这主要是为我们以后引入工程做铺垫。 如果根目录是小程序的根目录，后面会混入.json，然后分开就比较麻烦了。

然后在app里面，这是小程序的根目录。 就像官方的例子一样，这里放置了app.js/app.json/pages等文件/文件夹。 唯一的区别是添加了主文件夹。 这里的设置和之前的一致。 main文件夹包含主包的内容，pages文件夹包含各个业务分包的内容。 主、分包首先与文件目录隔离。

接下来是主文件夹的内部。 上面说了，它包含了主包的内容，所以里面的pages文件夹自然存放页面，外面存放各种公共资源。

*后，还有与 main 同一级别的 Pages 文件夹。 这是存储每个业务分包合同的地方。 这里可以将每个具体的业务存放在一个独立的包中。

编码风格指南

上一段讲的是外部结构规范，下一段应该是更详细的部分——编码风格的规范。

对此没有太多可说的。 每个团队的编码风格肯定不一样，所以这里简单提一下。

一是变量和函数的命名。 命名其实是一件非常复杂的事情。 我们需要明确这个变量或者函数的职责，并在这个职责范围内，思考适合其实际用途的命名。 一个清晰易懂的命名比优秀的内部实现更重要。

然后还有lint、等经典规范，这里不再赘述。

开发模式 *可选

目前我们开发小程序

多终端开发框架是指Taro、kbone等框架。 后两种开发模式的定义比较模糊，因为随着团队的积累和积累，即使是纯原生开发也会添加各种二次封装并提高效率。 因此，这里所说的二次封装方式是更高层次的。 例如，可以使用vue3 API模式来开发小程序页面。

你可能会问，这种二次封装和Vue编写多端开发有什么区别吗？ 它们*大的区别在于前者的模板仍然是.wxml，而后者的模板是.vue。

对于这三种方法哪种更好，作者还没有定论。 每种模型都有其优点和缺点。 唯一可以确定的是，型号的选择与项目形式密不可分。 我们可以从这些方向出发。 方案的选择：是否需要输出多个终端、团队的主要技术栈或者技术积累是什么、是否需要随时准备接入小程序的*新功能……

基础设施建设

做项目开发其实有点像盖房子。 将整个项目视为一座房子。 我们盖房子的**要务自然是打地基。 回到我们的代码项目，这一步叫做基础设施建设。 首先要保证我们的基础稳定、高可用，才能谈我们的房子内部装修有多么华丽。 否则，就是空中楼阁，一触即倒。

登录状态

首先，我们需要关注的部分是登录状态。 登录状态就是我们小程序中用户的身份证。 我们必须保证每个用户都能在正确的登录状态下操作我们的程序，否则将会出现不可预测的后果。 ，其范围从混乱的报告到埋点，再到影响数据库中数据的稳定性。

那么如何保证我们的登录状态能够稳定的获取和维护呢？ 笔者认为*基本的一点是保持统一的登录方式，关闭路径后也能保持稳定性。 接下来笔者分两部分来描述登录状态。 由于业务需求的不同，小程序中可能存在两种登录状态——小程序登录状态和自身账户系统登录状态。

小程序登录状态

这里所说的小程序登录态是指通过调用wx.login获取code，并用code来换取用户对该小程序

理想情况下，我们应该能够向外界提供一个通用的方法。 该方法不需要关心是否获取到有效的登录状态。 只需要通过wx确认登录状态即可。 每次调用，无效则重新登录。 （文末会提供后端实现以及整个流程的源码地址）

自己账户系统登录状态

为什么这里会出现另一种登录状态？ 它们是两个不同的登录系统。 事实上，小程序提供的登录状态也可以满足我们对登录状态的需求。 它有唯一的标识ID，维护着一套有效的逻辑。 它确实适合小型企业。 直接申请。

但当业务规模较大时，特别是同一实体下有多小程序时，这种情况下我们需要制定一个新的唯一标识字段作为用户的标识，并且无论在哪个小程序内，用户的身份是一致的。

这个所谓的新领域其实就是我们在开发H5、uid等时经常看到的，标识的生成因人而异。 每个团队对其用户 ID 都有不同的要求。 有些可能是普通的随机的。 字符串，有些可能是加密字符串。 登录状态除了包含用户ID外，一般还包含一个token或者带有有效期的字段，就像微信一样，用来判断登录状态的合法性。

如何生成和token基本上没有通用的解决方案。 它们都需要根据业务需求进行设计。 不过前提还是比较明确的——必须成功获取用户，才能注册用户并生成登录状态。 。

请求封装

既然前后端分离已经成为共识，请求就成了前端必须接触的东西。

在正常的项目中，几乎每个页面都会有多个请求。 如果我们不尽早对请求进行统一标准化的封装，项目很快就会陷入怪圈——随着时间的推移，我们会发现项目中的请求协议变得越来越繁重，并且在*终没有人敢去梳理协议内容，生怕调整影响整体要求。

因为项目之间差异巨大，我们当然不可能拿出一套人人都能用的请求逻辑，所以只能写一点示例代码。

如上面的伪代码所示，首先声明了一个通用的请求类，并在此基础上扩展了业务实际需要的请求方法。

在例子中，作者简单地预设了三种类型的请求，，。 其实在实际开发中，我们可能需要用到的请求类型比这多很多，但这三类请求是我认为缺一不可的。

// 通用业务请求
const defaultRequest = (...args) => {
    const r = new Request({ baseURL: BASE_URL })
    return r.request(...args);
}

首先，顾名思义，它是默认的请求模式。 前端除了和用户交互之外，*重要的就是和后端交互。 这种请求就是在这种情况下使用的。 可能是提交表格。 也可能是状态查询...

// 页面配置请求
const configRequest = (someKey, data = {}) => {
    const r = new Request({ baseURL: `${BASE_URL}/config-api` });
    return r.request('getConfigBySomeKey', { someKey, ...data });
}

那么，这就是作者构思的一个特殊的请求范式。 如今，配置已经成为主流思维。 大家都希望通过前端页面的配置来达到快速验证、敏捷实施的目的，所以我们在构思框架的时候也应该考虑到这一点。 我们应该有意识地将配置请求与业务请求分开。 在*初的开发中，我们总是将它们耦合在一起。 但如果你仔细想一想，他们显然是不同的。 一是接口配置的拉动，二是后端操作的触发。 我们可以在项目构思时将它们完全解耦。

// 云函数请求
const cfRequest = (cfKey, data = {}) => {
    const r = new Request({ baseURL: BASE_CF_URL });
    return r.request(cfKey, { ...data });
}

看到这里，有经验的童鞋可能会问，有些情况下，我们前端需要的并不是静态的配置，而是需要与后端数据进行一系列处理的配置。 这个问题非常有价值。 这种情况是必然会发生的，但是借助我们上次的请求也可以彻底解决。

云功能并不是特别新颖，但我感觉普及率还是不是很高。 稍微谈谈这个想法，这里我认为这是一个高层次的想法。 我们可以在云函数内部完成请求，并根据返回的数据进行配置处理，向前端输出开箱即用的数据。

另外，云函数不仅可以用来拉取页面配置APPID开发环境和H5开发一样，**件事当然是先注册一个小程序，还可以基于后端提供的原子级接口进行增删改查操作。 这里就不展开了，涉及到团队云功能职责的边界。 如果有机会，你可以写一篇关于它的新文章。

*后说一句，除了方便、标准化之外，封装请求的优点也很重要。 可以为后续的汇报提供极大的便利。

路由封装

小程序的跳转API比较特殊，和H5的路由跳转不一样，但是我们封装的思路其实是一样的。

路由封装主要是为了解决以下问题：

微信小程序的路由级别仅支持10级，如果在第10页想跳转到新页面，会报错，无法正常跳转。 因此，我们在处理跳转类型时需要添加当前页面级别的判断。 如果页面级别已经达到10级，我们可以将跳转改为，以保证本次跳转能够正常进行。

options.action = 'navigateTo';
const { _pathName, _query } = _navigateFormator(path, query);
if (getCurrentPages().length >= 10) {
    options.action = 'redirectTo';
}

然后就是数据传输的问题。 当我们进行各种跳转时，总是希望将一些数据从原始页面传输到目标页面。 虽然现在小程序提供了页面间通信的方式，但是使用起来还是比较麻烦。 如果我们能够整合整个项目的跳转方法，那么我们就可以用统一的封装的路由方法来维护页面的传递数据。

constructor(options = {}) {
    this.routes = {};
}
router(path, query, options) {
    // ...
    const preloadData = typeof options.preloadData === 'function' ? options.preloadData() : options.preloadData;
    const routeID = _randomString(6);
    query.__routeID = routeID;
    this.routes[routeID] = {
        routeID,
        preloadData,
        // ...
    };
}

*后，还有隐藏点和报告的问题。 正如上面提到的要求，统一操作对于隐藏点和报表来说是百利而无一害的。 我们可以实现一个默认的跳转回调，并在这个回调中实现上报相关的逻辑。 下面是一个简单的封装代码。 还有很多细节可以根据业务需求进行优化，这里就不展开了。

页面和组件初始化函数

本质是对小程序暴露的Page和功能进行重新封装。

随着开发的进行，我们希望能够在页面加载之初就获取到一些全局共享的参数或者方法。 这种情况下，我们就需要开发页面和组件的初始化函数。 笔者对此进行了总结。 当我们遇到以下情况时，可以考虑开发统一的初始化函数。

如上面的代码块所示，在对象中声明了一个函数，在其中进行了一些页面初始化操作，并约定本阶段产生的所有数据都将存储在this.data.$中。

在示例中，作者完成了以下初始操作：

以上只是冰山一角。 您可以根据业务需要添加更多的逻辑，让开发更加方便。

公共组件库

小程序中的公共组件库与我们通常在H5中看到的不同。 由于小程序对包大小有两个限制，并且子包之间不能互相引用，所以我们不能将组件库单独放在某个子包中。 ，只能放在主袋里，然后又出现了一个问题，袋体的大小。

正如在目录结构规范部分提到的，作者并不主张将所有提取的组件作为全局公共组件放在主包中，而是采用组件提升的方式。 当组件确实需要被其他业务引用时，可以将其提升为主包，既保证了主包量的顺利开发，又可以实现对组件的二次审核。

基础设施文档

!!我们决不能忽视团队技术文档的建设和积累

引用一句不知道从哪里来的经典句子——铁一般的辅助，流动的输出

我们用本文的场景来简单理解一下：

团队内部人员流动很可能频繁，无论是职位调整还是人手增减，都是不可避免的。 这个时候我们就需要稳定的援助来保证我们项目的可持续性，也就是我们的技术文档。

那么技术文档到底有什么作用呢？ 平时你可能很难注意到它们的存在，甚至当你想写的时候也会感到不舒服。

笔者根据多年来在团队的经历总结了以下几点：

业务开发

每个公司都有自己的业务开发流程，无法统一。 我们要充分观察公司内部工作流程，并与公司业务形态相结合，动态调整*适合团队的开发模式。

测试与发布

这部分主要讲解黑盒测试流程，顺便介绍一下发布相关的内容。

在进入正题之前，我们需要思考一件事——根据自己的业务规模来判断是否需要申请两个小程序。

如果是比较大的业务，建议准备两个小程序，一个用于测试，一个用于正式发布。

如果明确业务规模较小，或者是MVP项目，我们只能准备一个小程序。

下面，笔者将从这两个项目出发，分别介绍两个项目的测试模式。

MVP项目

小程序目前有开发版、试用版和正式版三个版本。 开发版和试用版有一定的访问限制，而正式版则对所有用户开放。 根据各个版本的特点，我们可以做出以下版本规划：

这是一个比较理想的版本规划，但是在实际的项目推进中，肯定会出现多个需求穿插开发情况。 这样的话，试用版就会被重复覆盖，这对测试和检查非常不利。 那么为什么我们不能使用开发版本来进行测试呢？

也不是完全不可能，因为拥有开发权的用户很少。 如果团队规模较小，可以在开发版本中全部测试，然后使用试用版本进行审核。 但稍微大一点的团队就做不到这一点，只能迁移测试人员体验权限。

如果我们在开发过程中发现项目比预期大很多、团队规模更大，就应该考虑将项目转为大型项目测试计划。

大项目

如图所示，一个大项目会有两个小程序。 一个小程序是专门用来测试的。 各个版本的功能与MVP项目类似。 唯一的区别是演练的时间发生了变化。 在大型项目中，我们会选择一个更稳定的版本进行产品和设计审核，这就是小程序的正式版本。

另外一个小程序是小程序。 代码到这里就绝对稳定了，所以这里只有试用版的位置。 在此试用版中，您可以享受预发布体验。 将其理解为灰度阶段的正式小程序。

在上面的测试部分，出现了多个版本。 那么这些版本是如何发布并部署到微信的呢？

以上两种方法都可以将本地开发小程序变成试用版小程序。 如果我们想让外部用户访问我们的小程序，我们需要登录微信公众平台，进入对应小程序的运营后台，并进行版本审核和发布，这没什么好说的。 只需按照界面提示填写小程序审核信息即可。

概括

如果以上内容构建成功，我们的小程序就成型了。 随着业务开发的深入，我们可以总结抽象出更多符合团队业务开发“轮子”，让我们的小程序更加健壮。

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等