今天前来专栏分享的极客，是 60 人左右的团队京东「JDC-多终端研发部」。

作为中国最大的自营式电商企业，京东购物小程序需要支持每日数千万的消费者。作为首批发布的小程序，团队在早期开发小程序和后续提高开发体验的过程中，有着哪些体验？

一起来看这个极客团队的开发故事。

正文

电商网站京东每天服务着数千万的用户，而京东购物小程序每天也服务着数千万的消费者。

这些直达千万消费者的服务背后，其中一个团队是 「JDC-多终端研发部」。

JDC-多终端研发部

「JDC-多终端研发部」于 14 年年中成立，他们在 15 年 10 月份推出了「凹凸实验室」品牌，旨在对外输出京东的前端能力及技术理念。现在团队 60 人左右，主要负责京东商城主战、微信 / 手 Q 购物两大业务，提供 Web 前端开发、动画开发、小程序开发、小游戏开发等前端开发能力，同时具有 app 开发、后端服务开发等全栈开发能力。

2017 年 1 月 9 日，微信小程序正式上线。在没有小程序出现之前，京东的微信入口已有一个独立的团队来负责这个购物平台的运营工作。后来有了小程序功能，这个业务团队希望基于小程序提供更好的体验，因而相关团队就进行了一次小程序化。

在小程序发布之初，团队及时捕获到小程序的体验价值，并进行一系列技术预研。同时，我们也迅速聚集10余人的项目小组，通过一个多月的封闭开发，京东购物小程序赶在第一批小程序发布。

项目初期的开发体验是不够完善的，不少问题需要克服。通过上线第一版本后，我们发现小程序用户体验极大的优于传统的 Web 页面，在响应速度、转场体验、交互组件，都很类似原生APP体验。因为用户体验的极大提升，让团队更加坚定地选择小程序来迭代产品。

基于微信小程序的大型应用发布流程

「JDC-多终端研发部」有两个业务团队，两个基础服务团队。目前两个业务团队内都有小程序团队，分别来服务相关业务的小程序体验。微信内的九宫格入口就算是京东的「大号」，是服务京东集团全平台业务的微信小程序。

微信小程序作为一个较新的一个开发平台，团队在设置团队分工的时候，小程序团队附属于一个前端业务团队之下。长期来判断，是否需要独立的小程序团队，基于小程序本身的业务复杂度来判断相关团队的独立性。

微信小程序的开发不难，可以较轻松地上手。但是京东商城的整体业务十分复杂，为了代码解耦、提高系统鲁棒性和开发效率，我们分别开发了一个页面基类和一个组件基类。在组件化开发方面，早期基于 template 的组件化方案开发体验较差，组件的引用略显啰嗦，组件间嵌套还可能引起问题。而在微信团队提供了新的组件化规范后，各种痛点都得到改善。另外在工程化方面，我们配置了一套 Gulp 流程，为开发时的各个阶段提供快速有效的自动化服务。

需求 ⇒ 开发 ⇒ 测试 ⇒ 部署

京东购物小程序的发版流程已经非常接近 App 的发版流程，而审核发布的流程依赖着微信小程序团队的反馈速度，从 1-2 小时到半天不等。

在测试这一环节，目前微信小程序尚未给出完善的测试工具，无法编写UI层面的测试用例。所以每次版本迭代，都需要人工介入测试。

自动化测试:每一次代码的 commit ，都会运行为小程序定制的 lint 来检测代码是否符合规范。

人工测试：具体到业务逻辑则需要测试同学逐步进行验证。

而在预部署环节当中，有 Gulp 流程专门用于生成预览版及预览二维码，和对代码进行打包压缩并上传等工作。

商城的业务逻辑在移动 Web 端已经十分完善，因此业务层面的开发难度不大，更多的问题在于平滑迁移到小程序的平台上，绕开小程序的限制和问题。其中比较大的几个挑战包括：包大小的限制、跳转层级限制以及请求并发数不可超过 10 个请求的限制。

为了突破请求限制，我们专门开发了一套网关，使用一套通过websocket标准的数据流来支持数据传输。网关主要的功能是对请求进行转发，使用与原 web 端共用的后台接口来提供数据服务。

当遇到长列表场景时，小程序渲染性能会出现瓶颈，滚动时出现明显的卡顿。最近微信针对这个问题专门开发了一套解决方案，希望能够有所改善。

另外，目前的组件化方案依然未能提供最先进、最舒畅的开发体验，所以我们开发了Taro框架来进行改进。而微信小程序推出的插件化方案各方面的限制还是比较多，经过开发、测试之后未达预期，尚不能大规模使用。

而在基于 618 的服务中，各业务侧会对多个小程序页面进行氛围改造，而对于和Web端共用的营销卖场页面，则是使用H5开发。此外，我们还准备了诸如接口容灾、数据兜底等工作，避免出现页面不可用的情况。

京东购物小程序迎合 618 开发了各种推广活动，例如这是团队开发的一个礼包功能，通过让用户分享转发到微信群来传播，达到让消费者领取礼券和推广 618 大促活动的效果。

小程序业务的统一开发框架「Taro」

Taro 是由凹凸实验室打造的一套遵循React语法规范的多端统一开发框架。李伟涛，余澈、陈攀、陈嘉健等都是主导推进Taro这个开源项目的主力成员。

他们的初期目标其实是解决小程序开发中的一些痛点，但在后来的业务开发中，逐渐发现了同个业务同时开发微信小程序、网站、 React Native 等多个终端的切实需求，所以 Taro 就演变成了一个多端统一开发框架。

Taro 在编码语法上遵循了 React 的语法规范，同时提供了现代化的前端工程化支持，这让项目的开发效率与开发体验有了极大的提升。目前Taro已经完整支持了小程序和 Web 端的开发转换，即将发布支持React Native端的转换，而快应用、其他小程序等的转换支持也在后续的开发规划中。

Taro 曾经进行了一次比较大的重构，一开始的 Taro 是使用小程序端组件化使用 Template 来实现的，但是有很多坑和问题。最后，Taro 团队基于小程序原生方案来重新实现组件化功能，得力于新的组件化方案，目前 Taro 的问题已经大幅减少，Taro 在小程序开发上也更加稳定了。

而在大型的重构同时，我们还需要不断跟进社区里提出的问题和反馈，因而就要不断加班加点地去完成，虽然有时会觉得很累，但是技术上的成就感以及能帮助到更多开发者时的满足感还是不断地激励着我们前进。现在 Taro 的核心有 8 名开发者在维护，还有一些同事会抽空帮忙完善功能。

目前 Taro 已开源了近两个月，在 GitHub 上有 6600 多个 Star，同时已经处理近 300 个 Issue ，还有 100 多个在等待反馈与优化。公司内、外都有十多个项目已经在使用 Taro 了。

接下来，团队会继续以 Taro 为中心完善整个 Taro 生态的建设，例如兼容小程序第三方组件库，支持整个小程序生态，以及即将发布的 Taro 多端 UI 库来助力 Taro 的多端开发。

文档极其优秀的微信小程序 期待更加开放

除了微信，百度、阿里都在推出类似的小程序解决方案，整个业界都在重视各个细分场景的产品体验。目前来看，小程序更适用于一些简单应用的业务场景， 通过较低的开发成本换取较好的产品体验，而 app 则更适用于复杂业务功能的载体。

微信的优势是社交关系，因而一切依赖着社交关系的应用场景及传播需求，微信小程序的体验和效果都更佳。

另外一方面，微信普及了扫码体验，通过这个交互模式打通线下线上的体验。但是，微信小程序为了保证极致的体验和速度，它同时限制了业务复杂性，可以支持的服务较为单一，缺乏持续吸引力。

JDC-多终端研发部甚至表示，期望微信小程序整个平台更加开放，融入社区更多成熟的能力，让开发者能做的更多。

团队的成员还表示，「微信小程序的文档非常优秀，它是我们心目中中文文档写的最好的那一个。」他们表示微信小程序文档的基础知识与 Web 开发相近，一个合格的开发者大概学习 2 周左右的时间即可上手，通过文档就可以快速进行小程序开发。

其实微信小程序与 Web 在业务需求上很相似，都以用户需求为主，但业务团队相对独立。从开发速度上，微信小程序和之前 Web 开发最大的差异是，需要增加版本的规划和发版流程。目前，团队每周固定有 2 次的发版流程，通过微信小程序平台发布。

当然从体验上来说，微信小程序的体验明显优于网页。其次，小程序具备完整的开放能力，加上微信社交关系链和生态的巨大优势，必然会成为市场追捧的方向。

微信团队的持续更新和发力，也让企业及开发者对这个开发平台更有信心。随着更多框架性能层面和开发效率、用户体验的优化，开放能力的不断完善，平台对比 Web 端的优势愈发明显，并且抹平多终端适配及碎片化的开发成本。

我们团队还在不同层面上比较了小程序和快应用、app、网页、PWA 的优劣性。

不过微信小程序在开发体验上仍可以提高，比如工具、语言，还有提升自动化测试工作的支持以及更好的组件化支持。

目前我们的每一次发布都「心惊胆战」，测试用例都是手动完成的，让版本发布有一定的风险。我们希望出现一套完整的自动化测试工具，免去人工验证的流程。

当然，微信小程序经常发布的新能力，也让我们对其充满了信心。

了解更多微信小程序开发者内容，欢迎扫码关注微信公众号——微信极客WeGeek