微信小程序快速发展历程，四个项目总结

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

其中，《王者荣耀锦标赛》仅用了1个月的开发时间，就作为第一款小程序应用发布了。小程序上线； 《王者荣耀官网》紧随其后，也在上线第二天发布。

《火影忍者大赛》遵循完整完整的直播框架，仅用了8天时间就完成了策划、设计、开发和上线。这次活动的效率让朋友们都震惊了。

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

项目产出效率略高。其背后又遵循着什么样的开发流程？今天笔者就讲一下，希望能引起一点思考，希望对即将开发或开发小程序的团队有所帮助。

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

（有同学问为什么第一个版本是在12月20号制作的？当时微信公开课定在28号，我们以为迷你版- 程序当天发布，所以原计划20号完成完整版，有足够的时间审核。）

竞王小程序的开发流程和开发流程很相似网站要求。主要区别是：程序多了一个“版本审核”阶段

由于审核机制的引入，只要开发者拥有网站等出版权，小程序的迭代就无法在线迭代。必须经过微信官方团队审核后才能上线发布。 ，因此测试就变得很重要。

接下来我们按照简单的原则来谈谈王者争霸小程序的开发流程：

1。前端有源驱动产品

为什么发帖人推荐前端有源驱动产品，主要原因有：

1.小程序前端技术在开发中占有很大份额

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

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

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

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

结合以上两点，前端开发人员可以继续做技术前期研究，发布原型demo，并推广到产品页面，指导他们结合实际业务实施需求项目。在请求项目建立后的功能迭代中，他们还可以结合现有API或组件的技术扩展性，为拟定功能的设计逻辑提供建议。

TGIDEAS前端团队按照上述方法，从10月到11月对小程序进行了技术攻关。发布了结合Web Socket的演示、结合实际业务数据的王者荣耀信息类演示等多个技术演示。 （王者荣耀大赛/官网小程序原型）页面，然后规划新的需求，最后决定开发；在后期的开发中，我们针对视频直播、分享逻辑等功能提供了技术和产品端的方案。

2。前端开发者必须考虑整个开发流程

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

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

2。小步快开发，敏捷开发

每个功能、每个Bug提出后都在短时间内快速实现。王者荣耀活动小程序的开发周期之所以只有一个月，依靠的是各团队的大力配合，实现了快会、快决策、快进度、快开发等高效的工作模式。

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

提出的方案是一个大胆的假设方案，必须拨出时间进行前期研究、突破和实施。

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

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

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

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

首先，运营和开发团队经过初步尝试未能落实预选方案，所以我们很快切换到了保证方案，让项目逻辑一直往下跑。后期人手释放出来之后，运营和开发的同学其实都被突破了。克服困难后，原定的选前计划得以实现。

最低保障计划是计划b。它不能被使用，但却有不可磨灭的作用。

当然您不必只选择这两种解决方案之一，您也可以同时使用它们。我们采用预期方案和保证方案两种方式对热点区域数据埋点进行统计。

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

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

事实是，微信事件统计模块前期出现了错误小程序发布后，数据有点偏差，但幸运的是我们两种方案都用了。点击流统计方法对热点区域进行统计。

上面讲了游戏之王小程序的应急开发流程和一些原则。事实上，攻克了这个小程序之后，其他小程序项目的开发流程在我们手里也变得更加顺畅了。大致流程总结如下：

（时间评估是根据我们团队的人员情况，仅供参考）

我把预延的部分灰掉了。这并不意味着这部分不重要。相反，发帖者认为这部分特别重要。前端同学最好在开始项目之前先做好前期调研，这样有时会事半功倍。

在动态开发时期，视觉修复过程可以与现在的Web开发中的重构过程进行类比，并且可以培训现在的重构人员来分担这部分工作。