1.

小程序于2017年1月9日全面发布，10月份主办团队开始研究小程序官网文档。 12月初，团队首个小程序项目——《王者荣耀赛事小程序》项目需求正式获批。 12月20日制作出第一个完成版本。下面是开发流程示意图：

2.

超高清大图邮票：

3.

（有同学问为什么第一个版本要在12月20号制作？当时微信公开课定在28号，我们猜测小程序可能会在当天发布，所以原计划是完成20号出完整版，留出足够的时间审阅）

4.

王者争霸小程序的开发流程与网页需求的开发流程非常相似。主要区别在于小程序多了一个“版本审核”阶段。

5.

由于审核机制的引入，小程序的迭代并不能像网页一样，只要开发者拥有发布权限就可以立即在线迭代。必须经过微信官方团队审核后才能上线发布。因此，测试就变得很重要。

6.

接下来说一下王者争霸小程序的开发流程，遵循简单的原则：

1. 前端主动驱动产品 7.

原贴提出前端主动驱动产品的主要原因是：

8.

1、小程序开发中前端技术占比较大

9.

对于API和组件，可以由前端开发人员提供可行性评估。

10.

由于小程序的大部分API和组件都属于前端范畴，前端开发人员可以告诉产品经理组件和API可以实现到什么程度；对于一些涉及后端技术的API，前端开发人员了解整个前后端逻辑，可以跟后端开发同学讨论如何制作接口（如用户认证接口）

11.

前端架构首先改变的是开发模式。

12.

与网页相比，小程序的前端技术形态并没有改变。虽然主要开发语言没有改变，逻辑仍然可以通过编写/(w)xml/css来实现，但是设计思路发生了很大的变化。本来，大多数网页的前端逻辑大多是面向的。过程式编程，虽然小程序是借用的技术栈，但是运行在传统的客户端开发模式上，这就限制了对界面的直接控制。开发者只能通过数据驱动来间接控制接口。

13.

结合以上两点，前端开发人员可以进一步进行技术预研，输出原型demo，推广到产品端，指导其结合实际业务实施需求项目。在需求项目建立后的功能迭代中，他们还可以结合现有的API或基于组件的技术可扩展性对拟定功能的设计逻辑提出建议。

14.

前端团队按照上述方法，从10月到11月对小程序进行了技术攻关。输出了一些技术demo，如结合实际业务数据的组合demo、王者荣耀信息demo等。

15.

（王者荣耀大赛/官网小程序原型）

16.

为了让相关团队知道我们用小程序可以实现什么，我们还专门写了技术文章，最终得到了产品方和项目方的认可，然后规划新的需求，最后决定开发；在后续开发中，针对视频直播、分享逻辑等功能提供技术和产品端建议。

17.

2.前端开发者需要考虑整个开发流程

18.

首先，由于开发需要，小程序账号的唯一运营者需要绑定前端开发者的微信账号。从最初的账号申请到最终的审核发布，以及后续的数据统计分析阶段，都需要前端开发人员参与，需要兼顾整个研发、测试和发布的过程。

19.

其次，前端架起了交互、UI和后端的桥梁，是各方沟通的桥梁。因此，如果前端同学在这个过程中积极推动整个项目的进展，项目的开发速度将会得到很大的提升。

2. 小步快跑，敏捷发展 20.

每个功能、每个bug在提出后短时间内都很快实现了。 《王者荣耀》小程序的开发周期仅用了一个月，得益于各团队的大力配合以及会议的快速发展。快速决策、快速调度、快速开发等高效工作模式。

21。

如何实现敏捷开发？笔者认为只要有司机就可以了。前端是可以驱动产品的，所以这个时候前端同学只要不把自己的角色定义为执行者，而是驱动者，遇到问题的时候不是寻求解决方案而是提前设想解决方案，然后指导大家实施解决方案。只是优化。

3. 原则 22。

这也是海报在其他项目中应用的原则。意味着对于任何一套技术方案，最好设想两套方案，一套是预期方案，一套是保证方案。

23。

设想的计划是一个大胆的假设计划，必须分配时间进行预研究、突破和实施。

24。

最低保障计划是必须可行的计划。这通常是一种非常简单粗暴的方法。目的是保证整个产品逻辑至少能够形成一个闭环。

25.

这么说可能有点神秘。让我举个例子。我们在开发王者荣耀活动小程序时，遇到了一个问题：现有信息的数据格式无法满足小程序的数据格式要求。

26.

我们制定的预选方案是在操作端或者前端端创建一个自动转换接口，将原始信息内容自动转换为小程序格式的内容。

27.

基本方案是手动转换文章格式，存入数据库，接口调用。

28.

起初，运营开发团队经过初步尝试未能实现预选方案，所以我们很快切换到了保障方案，让项目逻辑直接向下运行。后期人手释放出来后，运营开发的同学其实已经克服了困难。原定的预选计划已经实现。

29.

保障计划是不一定能用，但有不可磨灭的作用。

30.

当然，您不必只选择这两种解决方案之一，您也可以同时使用它们。对于热点区域的数据点统计，我们部署了预期方案和保障方案。

31.

预期解决方案：微信提供的事件统计模块

32.

保障方案：点击流二次封装接口

33.

事实是，微信提供的事件统计模块在小程序发布初期就存在bug，数据有些偏差。但幸运的是，我们两种方案都部署了，并且点击流统计方法收集了热点区域的统计数据。

34.

上面讲了游戏王小程序的应急开发流程和一些原理。事实上，攻克了这个小程序之后，我们手中的其他小程序项目的开发过程也变得更加顺畅了。以下是总结的一般流程图：

35.

（时间评估是根据我们团队的人力而定，仅供参考）

36.

我已将预扩展部分变灰。这并不意味着这部分不重要。相反，发帖者认为这部分特别重要。前端同学最好在开始项目之前做好预研，这样有时候可以事半功倍。

37.

在动态开发时期，视觉修复过程可以类比当前Web开发中的重构过程，可以培养当前的重构人力来分担这部分工作。

38.