归因组件ACE：订单归类技术解决方案陈浩宇（水古）淘系技术前言

陈浩宇（水古）淘系技术
文章插图
前言
天猫优品导购归因链路负责天猫优品订单导购判定工作，目前支撑了天猫优品权益券导购、普通导购和淘花导购等多种导购类型。随着业务迭代，现有导购归因链路在维护性、扩展性和可读性等方面存在明显不足，代码复杂性不断攀升，历史代码债务逐步积累。
为解决上述问题，开展了天猫优品导购归因链路技术重构工作。进一步地，在导购归因重构基础上，作为对“属性-分类-执行”问题的产品化思考与实践，提出了一种通用归因技术组件 ACE。 ACE 组件基于属性校验器、分类器和执行器三层模型解决了属性分类的通用性问题，具有良好的扩展性和代码语义。
本文以天猫优品导购归因重构为背景，阐述了一种基于 ACE 组件的订单归类技术方案。
技术痛点
伴随业务快速上下线，现有天猫优品导购归因链路在不断迭代过程中逐渐积累历史代码债务，应用代码存在复杂性高、扩展性低、可读性差等问题。
? 事务脚本编程事务脚本编程导致代码复杂性攀升。事务脚本型代码可能我们每天都在写，我们有时在用一门面向对象语言写着面向过程代码，基于 IF-ELSE 等条件判断语句快速堆砌业务代码。每新增一行业务代码，也许就新增了一行代码债务，应用代码复杂性逐步攀升。
文章插图
图 1 ：代码复杂性的演变
? 违背开闭原则违背开闭原则导致可维护性差。每次业务需求迭代，都在原有业务代码基础上修改或新增逻辑。我们很难知道历史代码哪些地方埋了坑，最好的方式就是尽量避免改动它。实际上，对于大部分业务代码，很难保证在新增需求时完全不需要改动原有代码逻辑。
? 缺失架构设计缺失架构设计导致可扩展性差。业务型技术团队常常面临业务需求急、开发周期短等问题，为支撑新业务快速上线，有时会采取最快的方式满足业务诉求。然而，最快的方式往往缺失架构设计，只为满足单一需求，对后续迭代并不友好。随着源源不断的新需求，应用代码很快陷入破窗效应，可扩展性越来越差，代码债务不断积累。
? 业务逻辑复杂复杂业务逻辑导致代码可读性差。看到下面这段代码，可能很难理解满足哪些属性是导购订单。这样的代码在业务型技术团队很常见，我们带着业务需求打开应用代码，却发现连原有代码所表示的业务含义都难以理解。代码可读性对业务型技术团队尤为重要，因为代码往往隐藏着业务含义，复杂的业务场景加上晦涩难懂的应用代码无疑是雪上加霜。
文章插图
图 2 ：晦涩难懂的业务代码逻辑
重构目标
为解决上述技术痛点，结合天猫优品导购业务发展背景，制定以下重构目标。
? 精简导购归因链路，清理过时业务逻辑业务发展存在不断试错的过程，应用代码伴随着业务不断迭代。有些业务代码虽然早已过时，且由于团队开发人员流动，谁也不敢轻易删除历史代码。代码上线容易下线难，代码愈发臃肿。因此，有必要精简现有天猫优品导购归因逻辑，清理过时业务逻辑。
? 抽象业务模型，向后兼容业务发展结合现有业务场景，抽象业务模型，支持后续业务轻量化迭代。通过抽象业务模型，可降低应用代码复杂度与业务场景复杂度的强相关性，甚至实现同一模型支撑多种不同业务场景。
? 完善业务优先级决策，规则统一收口规范业务优先级决策，统一收口业务优先级规则，便于后续代码维护和业务迭代。优先级决策是一种很常见的业务规则。如何用一行代码描述所有业务优先级，而不是将业务优先级判断散落在应用的多处地方？
? 提升代码可读性，代码语义即业务语义借助通用业务模型，赋予代码更丰富的语义，提升代码可读性。代码可读性对业务型技术团队尤其重要，看懂代码即看懂业务规则，可极大减少沟通成本，提升开发效率。
技术方案
基于现有技术痛点和重构目标，首先抽象业务模型，然后设计了一种通用归因技术组件 ACE ，最后将 ACE 应用于天猫优品导购归因链路。
? 业务模型以导购归因为例，导购归因旨在判断一个订单存在哪种类型的有效导购行为。有效性定义可概括为两个方面：一是满足或过滤某些属性，二是满足业务优先级规则。