随着小程序越来越火爆，很多公司都推出了多个小程序，或者一个小程序由多人开发。但是小程序不同于大多数WEB开发环境，当小程序变得庞大、复杂（比如各种电商、新闻、社区小程序）并且参与者众多的时候，就会遇到一些意想不到的风险~

传统的 Web 开发流程

小程序

孤狼模式（一个人开发）：没太大区别~

团队模式：在网页开发中，SA或者主程序员通常会将通过QA测试的代码发布到线上。而小程序则不同，云函数缺乏权限控制，云数据库不支持SQL，QA测试无法在发布前对部分功能进行真机测试（在线支付测试、未上线的动态二维码真机测试等）

让我与你们分享一下我们团队是如何做的：

1. 线上“云函数”被直接覆盖的问题（风险较高）

风险点：云函数与小程序代码不同，没有审核、发布流程，容易覆盖线上代码，任何有开发权限的开发者都可以上传云函数覆盖线上代码。

随着小程序中云函数的使用越来越频繁，云函数没有“测试环境”，直接发布部署覆盖线上版本，目前也没有日志可以追踪谁覆盖了，如果有队友失败把线上核心云函数干掉就GG了~

有些人肯定会说“本地调试”是可以的，但是现阶段还无法模拟本地调试的一些情况，比如内置函数等，同时也无法避免其他开发者误覆盖线上云函数。

解决方案 1：创建比较小程序

准备另外一个小程序B，​​将所有配置设置成和主小程序A相同的环境，所有开发者在B环境开发。QA测试通过后，将代码合并到A代码流水线中，然后统一上传部署覆盖A的云函数。

协助QA完成新功能上线测试

小程序管控组可以方便QA进行线上全量测试，解决以下问题：

这也是主流大公司的做法，他们甚至会构建多个相同配置的小程序，进行功能组件和模块化测试。

解决方案 2：在 中创建新的开发环境

const cloud = require('wx-server-sdk') cloud.init({ //env: cloud.DYNAMIC_CURRENT_ENV env："dev-258xxx", //制定dev环境测试 tracerUser:true, })

如果你是单兵开发者或者小团队，在更新已有的云函数时，可以切换新的 dev-xxx，在本地调试后再部署上线，自检通过后即可覆盖上线。

请注意，目前仅可搭建两个小程序云环境。

2.代码管理

风险点：并行开发、紧急修复bug、多版本协作开发~

多人开发常规的代码行管理有git()、svn(小海龟)等，我们内部都有，具体操作如下：

Dev可以根据版本号配置一条测试代码行，方便对后端环境进行QA测试，最后测试将代码传入IDE工具然后打开该代码行进行审核。

3. 后端（服务器）环境切换

风险点：手动修改配置文件，忘记问题了~

之前我们切换环境的时候，手动修改了文件：

但是有一次我在紧急修改一个BUG发布线上的时候出现了问题，合并到分支之后忘记改原来的Url.dev，直接把dev环境发布线上了，还好发现的及时，没有造成严重后果。

解决方法：IDE工具中的“自定义处理命令”。

点击“详细信息”-->“本地设置”，配置节点命令自动修改发布配置，这样就不用手动修改，避免人为失误。

4.指定专人发布并审核，澄清言论内容

风险点：迭代速度快，需要的版本太多~

为避免多人提交不同版本，导致提交的审核版本出现错误，由专人（开发人员、PM等）负责代码提交和发布。同时请写清楚备注，降低被官方审核拒绝的概率。

总结

以上方法不一定是完美/最优方案，都是我自己实践经验的总结，需要根据具体情况来解读：团队规模，项目重要性，开发周期，是否有付费等。

希望我分享的内容能够帮助大家规避一些开发风险，欢迎讨论交流~

你们的点赞就是我继续分享的最大动力！^-^