支付宝小程序经历小结

背景介绍

• 支付宝小程序公测以来，看了下文档，感觉很不错，从开发，调试，测试，灰度，上线等全流程都考虑到了。
• 后来看到一篇内部技术文章，“小程序技术方案探讨”，提到了“管控”，“体验”两个侧重点，并且分析了微信小程序为什么这么做。接着，还讲了支付宝小程序的策略：在产品层面，光明正大地抄；在技术层面，保持自己特色。这篇文章增强了我对小程序的信心。
• 接下来，开始向团队内部介绍支付宝小程序，让大家也开始认识支付宝小程序，并且还写了好几个Demo程序，最后，甚至把生活号的相关页面也写出来了，终于引起了大家的兴趣。
• 以试试看的态度，开发了第一版，就三个页面，相对比较简单，在预期的一个月内做出来，实实在在体验到了小程序相对于现有的支付宝生活号、“见客”（一个React Native实现方案）的优势。

场景分析

一般情况下，都是在需求分析中说要实现XXX功能，然后设计产品，开发落地，测试验证。
这种面向功能开发的模式没什么大问题，但是当最终用户使用的时候，常常有个困惑，“这些功能对我来说，有什么用？”
所以，更好的方式，是站在用户的视角，进行场景分析，一般的结构如下：“作为XXX（角色），通过XXX（操作），期望XXX（结果）”

铁三角

一般情况下，如下角色在推动项目前进：

• 项目经理：这个在以前比较多，国外比较流行。这是一个纯管理角色，不做具体的事。在国内，混得好的不多，往往属于“责任大，权利小”的尴尬境地。所以，导致的结果是“项目很少有不延期的...”
• 产品经理：这个在当前比较多，特别是互联网企业，往往就是理论上官最大的。
  不过，现实往往没有那么理想。产品和研发的矛盾，很少有和谐的。“产品狗”，“程序猿”，从这些流行的称谓就能体会到一点点的火药味。当然，平时也能遇到很多聪明的产品经理，时不时买的吃的东西之类的，关系和气氛瞬间就和谐很多了。
• 技术人员：在有工程师氛围的公司里，会出现工程师自己推动的项目的情况。有时候，出现了新技术，或者代码到了不重构不敢动的时候，也会出现。
  这种情况相对好一些，反正是自己有想法自己干，进展一般比较顺利。不过，问题是推进一般比较缓慢。因为这种时候很难得到业务和产品的支持，也很难得到资源，获得其他开发者的支持也是个难题。

有更好的方式吗？比如“铁三角”模式
运营，产品，技术三人组成核心团队，共同推动项目前进。由原先的单人负责制改为团体负责制。将原先的运营-》产品-》技术的串行流动改为团队的并行活动。将原先的部门责任转变为团队共同责任。

将测试当开发者

一般情况下，先开发，再测试。经常遇到的问题是一开始测试事不多，时间浪费了。等开发完了，离上线也不远了，测试就会非常忙，常常需要加班。一般呈现一个前松后紧的不平衡状态。
将测试当开发者，提前介入，可以改善这种状况：

• 将测试用例转化为Demo数据，方便开发调试程序。如果已经将测试用例变成Demo数据，在开发服务器准备好了，这时，要求开发进行更充分的自测就相对合理了。
• 在小程序管理后台，可以把测试人员的角色定位成“体验者”，不过将角色定义为“开发者”会带来很大的方便。比如，测试发现了一个bug，开发人员只要退出IDE登录，用测试人员的支付宝扫一扫，就轻松复现了bug状态。同时，也不影响测试继续用自己的手机进行其他测试。
  开发人员和测试人员公用测试的支付宝账号，一个用IDE调bug，一个用真机测试，两不耽误。

以时间定开发内容

一般的思维是先需求分析，产品设计，过完评审之后，再估算开发周期，再排期，再开发。这种模式的问题是什么呢？比如

• 都过去两三个月了，什么都看不到，虽然开发已经在加班了... ...
• 开发到一半，产品经理又有新想法了，要改一下... ...
• 开发过程中，发现产品逻辑不落地，或者后台不支持，是变更，还是延期...

另外一种方式，就是反过来，时间先定好，再考虑开发内容，多余的，不重要的，下个迭代再考虑。比如，以一个月时间为迭代周期，可以考虑如下安排：

• 第1周，原型和UI要确定下来。按重要性排序，新增功能不要超过3个，不确定的，不重要的，下个周期再考虑。
• 第2、3周，开发，测试，bug修复，内部发版。没完成了，移到下个周期考虑。
• 第4周，内部试用，积累反馈意见，准备下一个迭代周期的内容。

这样做的好处是大家都有明确的预期，并且只要一个月，就能看到成果，还能做到要事优先，不会因为一些小事耽误时间，还能逐步优化，给人越来越完善的正向激励。
比如，这一次，虽然一开始很多人不相信，但是最终真的做到了在一个月内让第一版小程序上线。做完了，我们才发现，目前我们的后台系统只支持客户经理一个维度，其他的诸如总经理，监管员等等都不支持，如果要等后台支持了，再开始，第一版小程序的面试最起码也是三个月之后了。
“能上的先上，条件不具备的，等以后再说。落地的产品，比完美的概念更靠谱。”

将Mock数据写在后台

目前前后端的开发过程一般是这样的：

• 后台开发功能；前端开发静态页面，Demo数据直接写在代码里
• 前后台一般不同步，这里经常会出现等待，比如等接口数据再调试。当然，测试更加不能提前测
• 接口好了，开发造一两条数据，前后台联调，根据后台返回的字段名字，修改代码，（前后端的字段命名一般不同，并且返回值显示到界面上可能要经过必要的转换等），当然先前写死的Demo数据要删除掉。
• 调通了，功能出来了，就提交测试了。当然，只试过一两条正常的数据，bug是再所难免的。
• 出了bug，往往很难分清楚是后台数据的问题还是前端展示的问题，往往需要前后端同步，花很多的时间才能找出问题点。

一种改进的方法：

• 后台先给出接口文档，再开发功能
• 前端根据接口文档，Mock数据。可以Mock到本地，比如dva框架的脚手架，专门提供了Mock的文件夹，Mock的测试命令行。
• 也可以用Charles等软件，进行重定向，将远端的url重定向到本地的JSON文件。
  可以说，这种方法已经很不错了，前端不需要在代码里写死Demo数据，直接按照接口将代码写好，本地调试好，就等后台数据了。
  不过，这里还需要等待，并且接口之间很可能有相互依赖，造数据不是很方便。

有没有更好的方法：

• 后台定义接口文件，前端写静态页面，测试设计用例数据
• 前端直接按照接口文档写数据接口；后台提供简便的造数据的方法；测试将测试用例数据，导入后台。
• 一开始就有数据，前端可以一次性写好代码，一次调通，不用等。并且可以根据测试给的数据情况，多做一些自测工作，将bug及早消灭，不需要等测试来发现了。
• 测试可以第一时间将用例变成数据，及早测试，及早发现问题。往后台造数据，在前端看效果。实际的效果比单纯的脑图用例有用得多。
• 对于后台来说，一方面可以减少依赖，减少等待，因为很多时候后台也要等后台。另一方面，早点有个可用的调试好的前端，对于真正对接数据也是有好处的。有没有问题，看下前端界面就可以了，显示不正常，这个时候，大概率就是获取的大后台数据有问题。