本文主要讲述京东门详业务在支撑过程中遇到的困境，面对问题我们在效率提升、质量保障等方向的探索和实践，在此将实践过程中问题解决的思路和方案与大家一起分享，也希望能给大家带来一些新的启发

一、背景

1.1、京东门详介绍

1.1.1、京东门详业务

门店详情页简称门详，门详业务包含门店详情、列表、凑单、搜索、到店等页面，最早于2020年在京东主站APP上线，最初是作为京东到家线下优质商家以线下店模式入驻京东主站，用户可以在门详内一站式完成门店信息查看、商品浏览、配送时效确认、领券、加车、下单等完整购物流程。后续随着业务的发展，门详陆续承接了天选、小时购、药急送、前置仓等更多的业务模式场景，逐渐形成了以即时零售为特性，覆盖到家、到店场景，承接线上线下的通用综合型业务系统

1.1.2、门详业务形态

门详业务涉及到家门详（小时购、药急送）、到店门详（POP、万家）；技术栈涉及京东小程序[2]、微信小程序[3]、H5、RN；页面涉及门店首页、凑单、搜索、评价、资质、列表等20+

1.2、门详业务支持过程中面临的痛点

• 京东app和微信小程序两端门详功能差异较大
• 因历史原因面临同时维护京东app和京购小程序两套门详业务需求
• 业务规划需求量巨大，双端需求迭代频繁，研发资源紧张无法短时间消化
• 双端业务场景及不同的技术栈对质量保障带来较大挑战

1.3、京购小程序业务方对门详的诉求

• 期望将京购小程序门详功能对齐京东app
• 新需求迭代希望快速同步到微信域
• 期望研发需求吞吐量增加，可以快速消化更多的需求

二、技术方案

2.1、前期方案调研

前期技术方案调研方面，我们也了解了当前流行的各种多端框架像RN、Flutter、Taro、uni-app等，并从多端支持度、开发生态、前端框架支持情况、学习成本等各方面进行了调研对比；由于要支持京东APP及微信小程序，所以优先考虑支持小程序的多端框架像Taro3[1]、uni-app[10]、mpvue[11]、chameleon[12]、WePY[13]等；结合对前端框架兼容情况、京东小程序[2]的支持度及团队自身情况（团队对React比较熟悉）等因素，综合考虑最终决定采用Taro框架来进行多端化重构。

2.2、技术方案制定及实践

2.2.1、思考需要解决的问题

• 如何更好的支持京东小程序、微信小程序、H5等多端需求？
• 如何在改造过程中避免新需求重复开发？
• 如何缩短研发交付周期？
• 如何才能在开发过程中提高效率？
• 如何在快速迭代过程中保障研发质量？
• 如何灵活支持更多的