行业资讯

微信支付大规模前端外包实战演讲分享(一)

2022-09-16 09:42:29

内容来源:2017年6月24日,腾讯前端高级工程师郭润增在“腾讯Web前端大会TFC 2017”上发表了“微信支付大规模前端外包实践”的演讲。 IT大咖表示,作为独家视频合作伙伴,经主办方和演讲者授权发布。

字数:3543 | 9分钟阅读

观看嘉宾演讲视频和PPT,请点击:/EyfTA1F

总结

业务的快速发展离不开各种配套操作系统的高效建设,微信支付也不例外。在前端人力极度匮乏的情况下,我们采取了不同的方式,引入外包团队进行大规模协作,在如何保证效率和质量、控制风险的问题上做了大量的研究和实践。版本更改,并确保可持续性。借此机会与大家分享分享交流​​。

为什么要引入外包

相关数据

目前我们基于外包做了20多个系统,这些系统粗略估计有200多个模块。我们组建了20多人的前端外包团队,并培养了20多名内部后端开发到前端SE,负责与外包合作。同时创建了40多个文档、5个视频教程和5个招聘流程,并有2个全职前端持续跟进。

第一次惨败

2015 年下半年,我们将整个项目外包。结果一个比较简单的小系统花了两个多月才完成,我们负责指导外包的同事也很累。

失败的客观原因

因为远程通讯,合作通讯成本高。

很多支持文件不完整,导致大量时间浪费在沟通和理解需求上。

外包研发水平较低,与腾讯培养的专业人才还有差距。

愿景

构建前端系统研发模式,引入外包团队,提高组织研发效率。

小额支付的需求发起者可能是数据、运营等各个部门,所以我们打造了“XPHP”前端外包协同研发平台VR ,为外包提供各种工具和框架。

这种模式是需求发起者提出需求后,业务团队开发SE接收需求,然后交付给外包团队,让外包最终实现高质量的系统工具。

定义关键角色 SE

整个微信支付90%以上的研发都在后端。我们从后端培训这些学生,让他们了解前端。这些学生负责制定各个系统实施的技术方案,整理微服务文档,指导外包团队的工作,最后配合需求发起者接受工作成果。

引入外包的三大挑战

如何解决外包效率和质量问题

1、抽象“契约式”开发模式,提高沟通合作效率。

我们将表现层的前端协议配置模块拆分给外包团队实现,后端业务逻辑层由我们自己维护。

为了让外包在研发中的效率更高,我们建立了一个可以创建需求的系统,然后可以进行协议配置,将协议应用到各个领域。配置好协议后,系统提供了填写一些假数据的能力,可以调用系统返回假数据。允许外包团队直接基于此协议进行开发。

我们规定前端尽量不要有业务逻辑,只通过数据驱动展示。让外包尽可能少的业务逻辑以减少沟通。

有一种编程哲学叫做“契约”编程。 “契约”有几个关键概念,例如先验条件、不变量、后置条件等。

我们的“基于合同”的开发模型只是一个原型。现在我们只要配置一个字段U3D开发外包ue外包公司,配置一些格式,前端就本着“契约”的精神开发了。

2、抽象出前端请求生命周期,填空完成业务逻辑开发。

我们抽象了整个MIS系统的业务逻辑层,抽象了整个业务逻辑层的生命周期。

比如前端请求来的时候,会统一经过一个安全过滤器过滤,再经过一个服务认证过滤器进行认证。然后,到了合约检查器的时候,可以检查前端的合约参数是否按照合约传输,有些返回包也可以通过合约检查器来判断,保证返回包按照约定返回合同当时设定的格式。

数据层是微信支付内部各个业务团队用C++做的底层微服务。 MIS系统只是调用底层接口来改变一些数据和配置。所以我们也统一封装了一个RPC请求者来调用各种协议的底层微服务。

最后,我们挖出了两个“空洞”:调用底层服务时需要向其传递哪些参数,返回时需要进行哪些处理以确保最终返回到那个时候做出的合约时间和前端。

开发者只需要“填空”。根据前端传过来的参数做一点处理,传递给底层服务。返回的时候做一些处理然后返回到前端

整个生命周期中的所有其他代码均由系统自动生成,形成“填空”研发。这种研发的好处是一方面,写的东西很少。另一方面,只要自动生成的代码质量足够高,基于此生成的最终代码的质量是可以保证的。

在这个系统中,你可以配置底层的哪些接口是依赖的。

3、赋能底层研发,提升前端研发质量

由于外包团队经验不足,我们希望提供更多工具来赋能他们。

我们提供了一个UI组件库,让他们在这个组件库中构建页面。有了官方提供的UI组件库,以后可以直接使用优质的react组件库进行开发,提高了外包团队的效率和质量。

CRR研发框架是react+redux的简化版,目前正在开发中。我们计划将其封装成一个界面供外包团队查看。开发方法就像开发一个小程序一样简单U3D开发外包,但最终编译出来的代码是react+redux的方法。

构建工具是XPP研发系统,集成了之前使用的构建方法的所有内容,并基于这整套东西外包构建和编译。这样页面和前端开发的规范就可以在里面得到保证了。

赋能外包开发的思路基本围绕着这个思路。

4、提供更简洁的研发视角,降低研发门槛

通过CRR编译器,将CR代码转化为虚拟语法树结构,将redux生成的额外代码注入其中。写的时候就像写一个小程序,只需要编译成几个文件。

总结:兼顾效率和质量,赋能研发人员

我们做了协议配置和Mock来解决表现层的高效外包开发。基于协议Mock高效开发页面渲染逻辑,并根据协议配置对参数字段进行质量强校验。

业务集成用于解决业务逻辑层代码的高效开发。填空业务逻辑开发,写的越少,效率越高。自动生成高质量、经过严格验证的代码。

UI组件库+CRR框架可以解决外包开发的效率和质量。 React 的 UI 组件的性能优化是由我们内部人员来保证的,所以外包可以基于一整套完全性能优化的 UI 组件进行开发,并且可以交付更高质量的代码。

如何解决版本变更风险问题

大型外包团队面临着一些严峻的挑战,例如没有测试人员、高昂的沟通成本、高开发流动性和许多系统。

为了更好地提高自动化测试用例生产的性能,去年底,我提出了无痛前端自动化测试的概念,我将其命名为PFAT。

PFAT 的灵感来自 react+redux 中单向数据流的思想。好处是我们只需要操作数据和改变状态。

React 本身有一个中间件机制。 PFAT 使用这个中间件来拦截所有的状态变化和事件,然后记录下来。这就是 PFAT 感知页面状态的方式。

关于前端异步请求的用例记录问题,常见的解决方案是业务自己将异步动作拆分成多个对应的同步动作。例如,一个可以拆分为三个Action,, , .

这种方案的缺点是每个业务都需要自己开发和拆分,不方便统一管理。

XPHP的解决方案是基于XPHP标准化协议管理的优势,封装通用异步请求中间件U3D开发外包,将异步动作拆分成多个对应的同步动作。业务规范使用,无需自行拆分。

把PFAT做成浏览器插件,显示隐藏灵活,不干扰正常体验和验收工作,后台记录操作过程直接保存。 PFAT 可以轻松地嵌入到正常的研发过程中。

Jest 的方法比较传统,需要额外的编码; PFAT可以一键记录需要的用例,更方便。 PFAT 比 Jest 更轻松。

PFAT对于提高测试验收效率的重要意义在于能够回放BUC。

传统上报bug的方式只有一张截图,开发调试效率很低。 PFAT可以一键保存案发现场每个操作的数据和动作,进行开发、回放和调试,大大提高了开发和修复bug的效率。

PFAT 适用于所有 react+redux 项目。

总结:

1、标准研发模式:定义前端研发模式CRR“基于状态机反转”。

2、高效用例记录:PFAT,一个高效的单元测试用例记录工具。

3、自动化用例回归:日常自动化回归、版本变更回归。

4、变更及时达成:变更关联发现机制、用例失败预警机制。

《PFAT无痛前端自动化测试方案》设计思路:

1、认清本质。 “ROI优先”原则,不要盲目追求100%的覆盖率。

2、尽量减少感知。 “不感染”的原则不改变研发流程,不编写额外用例,不导入额外数据; “保证效率”原则是指仪器记录、自动回归、用例管理能力和报警能力。

3、发挥你的力量。 “本着开源社区”的原则,模拟浏览器环境,自动回归,Diff展示。

如何解决可持续的问题

外包模式:持续培训,持续平台建设。

系统维护:持续推进标准化建设,不断加强系统管理和分析能力。

总结

我们必须善于利用和授权人们与有限的人一起做更多事情。解放劳动力,做更多有价值的事情U3D开发外包,获得​​更快的增长。

标签: U3D开发外包