施德来：有赞电商小程序的实践
Posted 腾讯云加社区
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了施德来：有赞电商小程序的实践相关的知识，希望对你有一定的参考价值。
欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~
施德来，毕业于浙江大学计算机学院。曾任职于淘宝、网易，现任有赞前端技术负责人、电商小程序技术负责人。
因为有赞刚好在移动电商这个赛道上，整个行业都推动着我们向前走。海量的商家有各自的需求，不断地在业务上督促我们做一些事。这次我代表团队为大家汇报一下我们被商家推动着做了哪些事，主要是关于技术方面的。
我眼中的小程序
首先和大家分享一下我眼中的小程序到底是什么？关于小程序，有两大矛盾困扰着所有的移动开发者。一个是H5跨平台的开发速度很快，但是打开速度很慢，Native能力差。这是它的开放性所决定的，这是一个矛盾。另外一个矛盾是Native的APP体验流畅、功能齐全，但是开发速度极慢、更新麻烦，而且ios和安卓要重复开发。
Write Once，Run Anywhere. 我知道大家都很喜欢这句话，我在后面加了一个Like Native。为了这个目标各大公司都给出了自己的方案，比如Google给出的方案是PWA，因为国内互联网的现状，这个PWA最多可以做到离线缓存、通知推送，所以其实PWA不是一个出路。其他也有一些方案，比如说Hybrid App，PhoneGap、lonic，充分使用Native的能力，但性能终究还是有问题的。我给大家提供另外一个方案：React Native、Weex，充分利用Native的能力，同时也能达到一处编写到处执行，而且也能够写得很快，至少不用写两次。但是它也有一些问题，事实上前端工程师是不可能抛开安卓和ios独立进行开发的，一定需要大量的适配，但这已经算是很大的进步了。
在我眼中现在只有一个选择：JS Native APP，微信本质上就是做JS Native APP，也就是小程序。它拥有JS Native APP的各种优点，再也不需要安卓的工程师和ios的工程师帮助解决系统问题了。结合Win7本身的公众号、浏览器功能，以及它底层的帐号能力，事实上微信已经有点像操作系统了。所以最终的结构是WeChat Operating System，什么事情都可以在微信里面完成，事实上就是这样。
有人提出这样的观点，随着微信小程序生态的完善，中国的操作系统可能就是要靠腾讯了。这就是我理解的小程序是JS Native APP中未来相当有竞争力的方案，因为一半以上的人都使用微信。很多H5中需要高阶能力才能解决的问题，被小程序用降维解决了。小程序为什么要打包上传？其实是因为微信可以通过一定的策略让这个包提前下载，大家如果推送过小程序新版本的话就会知道，包是分批更新的，我相信微信底层有更新这个小程序代码或小程序包的机制。它省去了H5中我们要做的大量工作，比如原先要完成的异步加载等等。这些都是为了让打开速度更快，但如果代码被预先加载好了这些问题就都没有了。
以码农的视角介绍有赞微商城小程序
下面我将以码农的视角介绍一下有赞微商城小程序，或许哪天你在做一个小程序的时候，又需要有电商的功能。这时你可以通过小程序之间的跳转，在有赞注册一个小程序，把课程、服务等跳转到有赞这边，进行完购买流程再跳回去。在H5的年代我们有几千个商家就是这么做的，在他们的APP中嵌入了我们的H5，其实在小程序里面也是可以这么做的。
简单来讲，有赞介入得很早，也有过彷徨。小程序是在2016年9月21日开始内测，2017年1月9日正式发布。其实我们2016年就介入了小程序，当时对于小程序的理解又结合了小程序基于地理定位的特点，也就是发现附近的小程序。我们觉得餐饮是很好的切入口，当然电商是我们的老本行，我们很快就做出了电商的小程序。在1月9日小程序发布的时候，我们同时也发布了有赞的电商小程序，那时只能将代码生成给到商家，让商家自己提交。因为当时微信没有提供相关的平台型能力，所以直到现在有些商家还是用我们一年前的代码。其实外界也对小程序有很多的质疑，大概持续了半年不到，我们在这方面的投入其实也不多。随着微信官方推出了很多新的功能，大家对于小程序越来越清晰，商家的需求也越来越大，2017年下半年我们开始发力，商家也开始更重视起来，到了2018年有赞小程序开始爆发。
首先声明一下这个数字是被我伪装过的，因为现在不能给大家透露真实的数据，这是购买有赞小程序的每个月的数量，趋势是没有问题的。大家可以简单看到，一开始的趋势是下降的。2017年1月的购买量比较大，刚发布的时候大家都过来用，后来发现好像也没什么。因为那时很多能力没有开放，群的能力、附近的小程序都没有开放，后来慢慢了提供更多的能力，大家慢慢开始有感觉了。
下面来介绍一下我们在小程序里面做了哪些功能。如果大家了解有赞就会知道，我们是把H5里面大量的核心能力全部搬到小程序，同时也做了小程序特有的能力。后台包括店铺、商品、订单、客户、数据、营销工具、营销渠道，市面上有的各种营销工具基本上我们都做了，有些是我们首创的，有些是参考的。
这是我们页面的编辑器，左边是编辑，右边是编辑出的页面，所有页面都是商家自己编的。现在我们已经实现了每秒5万笔订单的处理能力，多门店选择可以根据地理位置选择门店。对于卖水果、卖蛋糕的商家比较有用。其他功能还有拼团、新人有礼、瓜分券等。瓜分券就是分享给自己的小伙伴，比如5个人来领才能领到。这是我们小程序独有的功能，因为小程序在群的能力上，分享页面更方便一些。
简单来讲，我们的小程序包袱重、工作量大、场景复杂。首先，商家想要所有H5微商的功能，只是想要的比例不一样，我们要选择性地去搬。第二，我们要服务海量的商家，提供他们需要的技术服务，我们要生成海量的小程序。第三，H5微商城大量模块正在重构。这也是我们的工作环境。
技术上的探索和积累
接下来讲一下有关技术上的探索和积累，第一个问题是如何同时产出海量独立的微商城小程序，每个商家一个版本还不同。微信是提供这种能力的，同一份代码在不同的ID提交后到微信的开发平台可以生成一个模板ID，拿到模板ID后所有商家在我们的后台批量提交小程序。在提交的时候把商家特有的配置，包括商家的APP ID和底部导航信息一起提交给微信，微信再开始审核。
有赞拥有公共版的小程序和专享版的小程序，一套代码两个马甲，共用业务代码。如果小程序的名字是自己的，类似于垂直商城这种有自己的店且完全独立的小程序就属于专享版。公共版是免费的，所有有赞的商家都可以使用。事实上两者的功能基本是一样的，只是底层的导航不一样，本质上我们需要在一套代码里面输出两种小程序。左图为公共版，右图为专享版。在一个仓库里输出两种小程序，解法其实很简单。一般而言我们小程序有一个APP的json，罗列小程序中基本有哪些页面。我们另外罗列出了基于原先的小程序额外多出的页面，底部的导航条信息是独立的，这是不会被合并的。
富文本现在已经不是什么大问题了，在以前对我们来说却是比较难解决的问题。最早的时候富文本是图文编辑的组件，我们最早用的是wxParse，这是开源项目，它能够比较好的解决问题。但是它存在两个问题，一是没有办法很好地处理表格、列表标签，二是它最多只能嵌套11层。一般来说是没有问题的，但是有些商家会从第三方的编辑器编辑源码，再复制到有赞的页面编辑器里。第三方编辑器有的嵌了几十层，在小程序中就会出现很多内容丢失的情况。在2017年7月10日官方推出了一个rich-text，也存在一些问题。总结下来是svg无法在组件里面正常展示，能够展示但不能缩放。
下图是我们整个包大小的变迁，刚刚提到上半年发力，到11月份已经有1.4M，按照这个趋势再过两个月就要超过2M的限制了。我们用了一个叫做wxapp-webpack-plugin的开源工具，因为业务场景不一样可能需要二次开发。它可以帮助我们只打包有用的代码，在H5的生态里是最简单的东西，在小程序里会稍微有点麻烦，我们的结果就是把0.3的包变成0.93兆。12月份微信推出了分包，所有的包加起来4M，每个包不能超过2M。
接下来还有两部分，一是如何提高开发效率，二是如何提高稳定性。我们在2017年的1月开源了有赞小程序的组件库，我们拥有组件库的传统，最近也改用了官方推荐的自定义组件的写法。在开发的过程当中，同样也会涉及到接口的东西，有切换的问题，有接口转发的问题。在这里推荐大家尝试使用ZanProxy，现在我们的小伙伴没有这个工具就没有办法写代码，它可以很方便地转发。我们也支持自定义插件，做一些不同业务场景需要的关于接口文件、转发以及改造的相关需求，包括在H5的头里面加一些字段之类。
前店后厂模式还是跟效率有关，为了能够比较快速地把小程序做起来，我们回顾总结出了前店后厂模式，也就是减少环节快速往前跑。我们组建了对接商家的群，商家提出需求，开发的同学觉得这个需求有道理就马上去做，有些需求是凭感觉就知道有道理的。因为已经有了H5的能力在参照，我们要做的是选择哪些要复刻到小程序中去。提出的痛点解决之后马上给商家讲清楚，减少所谓的产品测试等各种环节，整个过程是很顺畅的。但需要核心人物同时发挥PM、产品经理以及开发的角色，或者团队里有人每天有一部分时间切换为产品经理。
关于如何提高稳定性，在我看来这是本次分享里比较有含金量的部分。简单来讲就是想要快速迭代但同时活多人少，而且没有测试资源的情况下要怎么快速向前跑。我们的解法就是体验版、稳定版机制，前端工程师历来都是改完马上生效，完全不管之前的版本，最多就是灰度发布。我们组建了一个内测商家群，每个星期及时同步稳定版发布时间以及体验版的新功能。内测商家全部默认使用体验版，但这些商家也是要进行筛选的。我们会在后台单独操作进行更新，也可以进行批量更新。基本上保持的节奏是两个星期一版，所以一个体验版的代码将被100来个内测商家至少使用一个星期。所以体验版小程序在改成稳定版提供给所有商家使用的时候，基本上已经没有什么问题了。其中唯一一次故障就是因为没有遵循这个原则，在体验版上停留三四天就着急上稳定版了。第二就是利用好回滚、撤销接口。对于这个版本出现的所有问题，我们可以批量地把所有商家的小程序都回撤到上一个版本，这是官方提供的借口。我们需要去开发，回撤之前会确认一下。
最后回顾一下，本次分享首先是为大家介绍了我眼中的小程序，简单来讲小程序就是微信操作系统中的APP，解决了之前H5和Native APP的各种问题，降低了开发门槛。第二是从码农的视角介绍了有赞微商城小程序，第三是介绍了我们团队技术上的探索和积累。
Q/A
Q：数据和数据之间做的隔离是在腾讯云上做一个集群吗？
A：这个事和腾讯没有什么关系，我们有自己的运维团队，基本上管得比较底层。当然对于个人开发者而言，我还是蛮推荐腾讯云的套路。刚才你说的商家数据隔离，我们现在没有做这样的事情。确实有给商家提供审核的时候，商家自己的配置，其中一个配置就是在小程序申请的APP ID，我们所有的请求都会带上这个ID，后端会拿到对应的数据。
Q：使用体验版的商家为什么愿意做小白鼠？是因为有一些优惠还是确实看中？
A：这个问题问得非常好，有两个理由。做生意的人，因为跟钱挂钩，他们会认定有些东西是很需要的，是他们下一步商业计划里急需的一环，他愿意承担这个不稳定的风险去使用这个功能。实际上我们的体验版质量也没有那么差，至少我们自己去回归过，该测还是会测。商家很愿意影响你，他对这个产品有自己的想法，人人都是产品经理，他们都希望这个产品按照他的想法去做，所以很愿意参与这个共建。现在很多产品都这么用，我们也用类似的套路去做这个事情，对于我们而言好处当然更多了。
Q：刚才说的体验是在现场，不是在小程序客户端，正儿八经的发到线上？
A：对，无非就是有一个名单，给这个名单发的时候给他提交的是制定的模板ID，是体验版的，只是提交审核的时候不一样而已。回撤是微信最近一两个月才公布的能力，我们也刚刚用起来，之前如果发了一个有问题的版本也没有办法，只能再发一次。
Q：刚才提到跟用户之间直接联系，我想问一个细节，这个推动过程是把多个商家拉到一个群里面这样操作，还是有分开？
A：把多个商家拉到一起。
Q：会不会有不和谐或者冲突的？
A：我不是特别明白你说的不和谐？
Q：比如说有些功能是加强版，我想拥有但是它没有，如果这个版本的价格跟别人的价格都会在群里提到？
A：在有赞我觉得是没有问题的，因为有赞各个版本的价格是比较透明的。说得再直白一些，哪怕你跟我们的CEO是很铁的哥们也没有优惠码，除非是商业定制款、高阶的、有更高的价格，需要有BD的同学进行对接。
Q：单独对接？
A：如果是特别高阶的几十万几百万的肯定需要单独对接，我们普通的基本款是4800，还有9800，都是一样的。
更多分享资料，请戳下面的链接：
问答
相关阅读
此文已由作者授权腾讯云+社区发布，原文链接：https://cloud.tencent.com/developer/article/1117052?fromSource=waitui
以上是关于施德来：有赞电商小程序的实践的主要内容，如果未能解决你的问题，请参考以下文章