用数据说话!使用“设计稿智能生成代码 imgcook ”后的研发提效!

 用数据说话!使用“设计稿智能生成代码 imgcook ”后的研发提效!
阿里巴巴 前端委员会智能化小组 @ 阿里巴巴

文/阿里淘系 F(x) Team - 苏川

设计稿智能生成代码的发展

据不完全统计,淘宝天猫仅搭建类模块的年新增量 1w 以上,年页面增量 100w 以上,这些产品页面心智不同导致 UI 视觉多样、业务性质不同导致业务逻辑不同,大量的模块难以复用,需要投入大量的前端人力来开发,前端同学的业务压力非常大。

为了解决这种困境,在 2017 年研发了能够自动生成代码的工具,当时叫达芬奇,后来我们逐步引入 CV、NLP 等 AI 技术来解决图层识别问题和语义化问题,经过一年多的发展后已经能够在对设计稿的约束很少的情况下生成可读性和可维护性较高的代码,并在 2019 年 1 月正式对外开放 imgcook 平台。


稳定性和性能是每年大促必备的横向项目,对外保障大促会场的稳定和性能体验,从 2019 年双 11 开始,研发效率也成为大促的横向专项之一,对内提升研发效率释放人力,减轻前端同学的业务压力。

设计稿生成代码(Design to Code, D2C)平台 Imgcook 作为研发效率专项项目中提升研发效率的核心抓手,在 2019 年双 11 大促会场中承接了 78.94% 的新增模块的自动生成,代码可用率达到 79.34 %。

今年前端智能化助力前端研发模式升级,数个 BU 共建前端设计稿识别算法模型和数据集,并于双十一会场大规模应用落地。设计稿生成代码技术体系全面升级(如对 UI 多态、直播视频组件、循环的智能识别增强等)带来了营销模块研发链路产品化升级:双十一会场有 90.4% (高于去年)新模块的代码智能生成。升级设计稿智能检查能力,无人工辅助的情况下智能生成的代码被保留发布上线的占比 79.26%。相比传统模块开发模式,使用设计稿生成代码技术后编码效率(模块复杂度和研发耗时比值)提升68%,固定人力单位时间模块需求吞吐量增加约 1.5 倍。

今年双11的研发提效

今年双 11 在可统计范围内共有 52 个新增模块,其中使用 D2C 的模块占新增模块的 90.4%,包括主会场、行业会场、专题会场、榜单会场、新品会场、U 先会场、感恩会场等,没有使用 imgcook 的原因为:复杂互动交互、动效、3D 和 UI 设计感较强的场景。下图展示的是本次双十一中通过 Imgcook 可视化研发链路开发的部分模块。



研发提效是一个比较常见同时比较宽泛的概念,根据真正前端的时间花去哪了,我们统计了 100+ 的淘系 C 端前端开发者的具体时间,结果(经过被统计同学私人同意,电脑安装类似 Timing 的软件进行批量统计,总计约 2200h+ )如下:


  • 前端耗时占比最高的是编码阶段 27.7%,top2 是线上钉钉沟通 20%。
  • 除了编码外,前端其他环节多,每个环节均有一定耗时,如分享总结和学习的时间占比也不少,前端是一个需要不断学习总结的职位。
  • 从全局来看,前端整体提效关心的是整体的前端人效的提升,到底能减多少人,或者现在人员本来就紧缺,减人的统计方式不太可行,那就看需求吞吐率(固定前端人员单位时间的需求吞吐量);从局部看目前D2C 主要提效的是编码阶段,所以编码效率是也是关键提效指标,进一步分析,影响编码效率的主要因素有智能生成代码的可用率和业务的复杂度等。

研发提效的衡量指标

我们从三点来衡量是否有效的进行了研发提效,分别是:需求吞吐率、编码效率、代码可用率

需求吞吐率

在本次双 11 会场项目中,选择了 2 位正式同学和 2 位外包同学作为试验人员,只做模块需求,模块按高度复杂、中度复杂和低度复杂区分,模块个数按中等复杂度为单位折算,例如 1 个高等复杂度模块相当于 2 到 3 个中等复杂度模块, 1 个低等复杂度模块相当于 0.5 个中等复杂度模块。最终得到这样的结果:


同时采访了数十位同学,在不使用 D2C 的情况下平均每周能开发 1.5 个模块,所以将 定为 1.5。由此可计算出,和完全不使用 D2C 相比,固定人力单位时间模块需求吞吐量提升约 1.5 倍。

PS: 此 需求吞吐量 指标后续日常待增加更多样本,持续验证。

编码效率

需求吞吐量会将整个需求中的因素包括需求沟通时间也考虑进去,而编码效率则可以衡量单位时间内完成的开发工作量。我们统计了 2020 年 9 月份之后在 IDE 中开发的 38 个模块与使用 imgcook 开发的 34 个模块的复杂度和开发时长,并计算出每个模块的效率值 E=Complexity/Time。

在 IDE 中平均研发编码效率值是 0.604,在 imgcook 中的研发编码效率值是 1.89,换算成相同复杂度模块的编码时间比较,可以看出使用 imgcook 研发编码效率上可提升约 68%。


代码可用率

我们统计了 Imgcook 最后一次还原生成的代码在此次还原最靠近的线上版本中的留存行数占比。即代码可用率 = (imgcook 生成代码行数 - 删除的代码行数) / 线上代码行数。双 11 会场无人工辅助的情况下纯视图代码可用率 70.07 %,CSS 代码可用率 73.88%,总体代码可用率 79.26%。

(Imgcook 生成代码与线上代码比对面板)

我们以一个双 11 模块为例分析代码生成的情况,对于一个布局生成较好的模块,代码的改动主要在于添加一些事件绑定和字段绑定代码,此模块代码生成可用率为 89.8%。

(U先会场-短视频)

变化和创新

在前端智能化大背景下,对 D2C 技术体系全链路进行了智能化能力升级,并为前端同学带来了让前端工程师能成为机器学习工程师的前端算法工程框架 Pipcook 和解决样本收集问题的样本制造机 Samplecook。同时带来了营销模块研发链路产品化升级,助力全链路研发提效。

(D2C 技术升级架构图)

D2C 技术体系升级

D2C 的智能化能力分布在还原链路的各个阶段,我们以提升代码可用率为目标,对全链路进行智能化能力升级,将技术方案细化到如何让各阶段模型识别准确率提升以及如何能将识别结果最终应用到智能还原链路生成代码,如何做到从样本收集、模型训练、模型部署到模型应用到工程链路整个流程能够自动化、自我迭代优化,不断优化和迭代模型能力。

智能化能力的应用还需要工程链路的支撑,例如模型识别结果的应用、线上用户行为召回、前端开发组件对 UI 组件识别结果的承接等,整体的 D2C 技术体系也需要同步升级。

(D2C 技术体系升级大图)

D2C 研发模式升级

淘系营销以模块开发为主,模块开发的完整链路是从模块管理平台创建模块 ⇥ 进入 Imgcook 平台智能生成代码&可视化研发 ⇥ 开发完成后进入 IDE 调试预览 ⇥ 测试完成后进入工程平台发布。整个研发流程需要切换多个平台,开发链路体验和工程效率都有待提升。

创建模块后进入 Imgcook 平台智能生成代码&可视化研发,如果能够直接在 imgcook 平台开发、调试、预览和发布,一站式的 D2C 研发模式是提升整体研发效率和研发体验的一个不错的选择。

所以我们自定义了具有可视化模式和源码模式的营销版本 Imgcook 可视化编辑器,在可视化模式智能生成代码和可视化研发,并将生成的代码一键同步到源码模式的 WebIDE,在 WebIDE 中支持界面化的调试、预览、发布。

(天马模块 Imgcook 可视化研发动线)

我们通过计算使用传统研发模式开发的模块与使用 Imgcook 可视化研发模式开发的模块的效率值(复杂度与研发耗时比值)看到,使用 Imgcook 可视化研发链路开发的模块编码效率提升 68%。

增加算法工程体系

Pipcook 通过提供通用的模型能力,比如图片分类、目标检测、文本分类等,减少了在 imgcook 中从开发到上线这些模型的门槛,使得如此多的底层识别能力也具备快速迭代的可能性。imgcook 全链路的识别能力,如组件识别、Icon 识别、字段语义识别等都是基于 Pipcook 训练。

(前端算法工程框架 Pipcook)

来年展望

编码和沟通是占比最大的部分,期望通过结构化需求、提高 PRD 交付质量以减少沟通时间。未来期望业务研发平台能够打造需求即代码、需求即生产、协作在线化的全新业务研发模式,提升整体需求链路研发效率。

(业务研发架构)

更多阅读



除文章外还有更多的团队内容等你解锁🔓

分类:
前端
标签:
分类:
前端
标签:
收藏成功!
已添加到「」, 点击更改