大淘宝技术-阿里云开发者社区

大淘宝技术

旗下包含淘宝技术、天猫技术、iHome等团队和业务,是一支是具有商业和技术双重基因的螺旋体。大淘宝技术部的愿景是致力于成为全球最懂商业的技术创新团队,打造消费者和商家一体化的新零售智能商业平台,创新商业赛道。依托大淘宝丰富的业务形态和海量的用户数据,我们持续以技术驱动产品和商业创新,不断探索和衍生颠覆型互联网新技术,以更加智能、友好、普惠的科技深度重塑产业和用户体验,打造新商业。

  1. 首先我们解决的问题一定是有边界的是处在一个业务领域的,并在这个业务域下进行分析。因此我们分析了一下我们最常见的业务形态- 模块。而据统计“相同业务能力,不同技术实现”的模块在整个天马体系中的占比非常的高,单单拿通用商品坑来看就有上千个,而这些模块大部分都是相同的逻辑实现,也有很多是处于不同时期的技术产品。

  2. 一个模块在前端的开发设计里,大概可以分为4 部分,通用组件,通用Action,视觉代码,驱动逻辑。

  3. 我们可以看到视觉和通用组件以及Action 都是已经有了的,变动周期比较低。而驱动逻辑部分是是业务中的主要实现逻辑,如何让这部分逻辑能让运营进行产出呢?

  4. 首先我们将这部分能力进行一个拆解,我们得出一个初步的结构,就是由 运算符 + 表达式 + 基础action + pipeline 组成的表达结构,这个表达也可以组成一个新的action,再加上trigger,整体就完成一个workflow 的能力了。

image.png

new Expression = Variable + Operator + Expression + Pipeline

new Action = Expression + Action

Workflow = Action + Expression + Trigger

业务模块的四个部分中,驱动逻辑就是我们主要核心产出的内容,根据我们的经验这部分ProCode 大部分都是表达式 Expression 内容。因此我们只要能让运营能够自主的完成 ProCode 部分的编排即可高级定制需求的产出物。

让运营完成所有的ProCode 也显然是不现实的,但是对于IFTTT 这种简单的逻辑表达,只要将这部分内容的表达可以使用更接近自然语言的表达方式,自然会降低整个的理解难度。

以上内容摘自《大促背后的前端核心业务实践》电子书,点击https://developer.aliyun.com/topic/download?id=728可下载完整版。

胡嘞嘞 评论 0

这个过程通俗来讲就是 通用组件 + 配置信息 的模式,配置信息即 ProCode的部分,该部分即为需要 AI 自动产出的内容。因此想要完成自动出码,就需要对ProCode 的部分进行样本制造和监督学习。

我们来总结一下我们的三步走计划:

  1. 需求的结构化收集 (为了降低NLP 的分析难度)。

  2. 创造结构化需求到标准逻辑表达的样本(为机器学习ProCode 部分提供充足样本)。

  3. 通过机器学习对样本进行学习,以达到AutoCode 的目标(长期目标)。

即我们需建立要两个平台,我们称之为P2C 的 2.0 代 和 1.0 代。P2C 1.0 负责打标需求数据,并为 2.0 的智能出码提供庞大准确的数据。而 P2C 2.0 则主要进行需求的结构化收集并与1.0 的样本进行关联学习,训练出码模型,最终达到创作和自动完成需求的目的。

两个平台所代表的关键词分别是:

●P2C1.0:精确收集,精确产出

●P2C2.0:开放收集,创新产出

那么精确收集样本就成为我们 P2C 1.0 的主要工作方向。

打标样本一定要从实践出发,并能在该阶段帮助需求真实的进行产出,即我们提供的打标平台能真实的完成业务需求,因此我们决定开发一个可视化编排的平台,通过该平台来收集样本数据,并且可以顺手把需求也消化掉。

那么问题来了,这么多的样本打标的工作到底由谁来完成呢?

我们通过调研发现运营的角色在可视化编排方向上,是有着非常高契合度的。为什么呢?其一,运营都具备模块搭建的能力。其二,很多运营的需求都不一定有机会能够落地,主要原因是开发资源不足导致的,这也是多年来存在的业务与技术矛盾,前端这十年来一直朝着工程化、规范化、模块化的方向发展,本意是为了更有效的重用业务能力以达到解放生产力,而产品却一直在朝着丰富化、精细化的方式来运作,各个业务方不再是单单为了满足功能诉求而更讲求的是用户心智。最终致使现在对一个个性化需求的提出往往是用一个标准化方案来落地的。当业务方为资源不足妥协时,其业务整体感官也会越来越平庸化、趋同化,最终导致产品对用户的心智弱化。

image.png

因此对于运营的诉求是希望能将创新和业务思考带入到自己的产品中,而不是简单的拆解为一个个的标准实现。如何拉大与竞争对手的运营差异、交互差异、创新差异、视觉差异才是对于运营真正的核心价值。

在AI 的介绍篇中我们讲了对于复杂的逻辑关系我们依然可以采用抽象的组件化来实现,而这部分实现对比传统搭建体系的组件颗粒度更细,传统搭建一般是对模块的自定义配置,而在我们的编排体系里最小的组件应该是原子化的不可再被拆解的,比如一个Image 组件,而对组件的配置可以是一段编排好的逻辑实现,因此它能有着同代码一样的绝对灵活性。

以上内容摘自《大促背后的前端核心业务实践》电子书,点击https://developer.aliyun.com/topic/download?id=728可下载完整版。

胡嘞嘞 评论 0

互动场景下的前端交互非常复杂,然而前端功能回归一直以人工方式为主。我们在项目中尝试自动生成测试用例,用于回归测试。

从用户交互的视角出发,收金币、购买车厢、合成车厢都对应用户的一次交互行为。我们在 Puppeteer 环境中运行页面,根据沉淀下来的数据,回溯到特定的状态。

并结合强化学习,择优触发前端Action 事件,模拟真实的用户操作,最终形成用户的前端交互行为树。

image.png

得到用户交互行为树之后,我们会对行为路径再进行优化,排除无价值的链路,合并重复链路,并最终拆分成简短的片段便于测试。如合成车厢N 次,会处理成为N 个测试用例,尽量以同种状态下的最短路径作为最终的测试用例。

image.png

在需要回归测试时,我们可以在 Puppeteer 环境中回放测试用例,做到了前端功能的自动回归。这个过程中,我们把各个测试用例的UI 快照保存了下来,利用图像识别技术进行最后的校验。

以倒计时浏览任务为例,我们需要验证在跳转后的页面上,是否正确的展示了某个组件,通过图像元素的对比,可以判断该功能点是否正常。

image.png

互动项目的业务逻辑,是一系列用户行为带来的反馈的组合体,智能测试方案在本次 618 互动项目中,成为了前端开发测试阶段的提效利器。在线上阶段发生变更时,可以快速完成线上功能的全量回归和新功能的验证,保障线上业务的稳定。

以上内容摘自《大促背后的前端核心业务实践》电子书,点击https://developer.aliyun.com/topic/download?id=728可下载完整版。

胡嘞嘞 评论 0

了解更多

更多内容为你解读,持续关注!

展开