作为这里的技术研发团队，我们和其他技术团队一样，时刻关注着新技术、新业态。 面对新的应用形态，团队结合业务实际，在年前发布了以下四款小程序应用：

其中，“王者荣耀活动”仅用了一个月的开发时间，正好赶上小程序上线； 《王者荣耀官网》紧随其后，也在上线第二天就发布了。

《火影忍者大赛》采用了现成的、完整的赛事直播框架，仅用了8天时间就完成了策划、设计、开发和上线。 这样的效率让小伙伴们都惊呆了。

《邻居趣》是一款利用lbs寻找游戏好友的陌生人小社交程序，历时一个多月的开发，终于在假期前上线。

项目产出效率略高。 这背后遵循着什么样的发展流程？ 今天笔者就来说一下，希望能够引起一些思考，也希望对即将开发或者正在开发小程序的团队有所帮助。

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

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

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

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

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

1.前端主动驱动产品

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

1、前端技术在小程序开发中发挥很大作用

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

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

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

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

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

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

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

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

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

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

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

2、小步快跑，敏捷发展

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

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

3. B计划原则

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

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

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

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

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

最低保障方案是：手动转换文章格式，存入数据库，接口调用。

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

最低保障计划是B计划，可能不会用，但有不可磨灭的作用。

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

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

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

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

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

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

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

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