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

举例：
如图 8 所示，新增导购类型（优盟导购），只需新增分类器 Classifier（UM_GUIDE），并绑定相关属性 Attributor（优盟），关联执行器 Executor（优盟导购）。借助 ACE 组件可无侵入性地新增业务类型，完全无需改动原有代码。
文章插图
图 8 ：新增导购类型（优盟导购）
? 代码结构优化代码结构从原有的「纵向+多出口」转变成「横向+单出口」。从代码维护角度，单出口程序更利于维护，代码（方法）出口统一收口到一处地方，代码逻辑一目了然。
文章插图
图 9 ：横向单出口的代码结构
总结
本文提出了一种通用归因技术组件 ACE ，并将其应用于天猫优品导购归因技术链路。 ACE 组件以属性校验器、分类器和执行器三层模型为核心，规范化定义某种类型需满足的属性组合及其对应的执行策略。
ACE 组件借鉴了策略模式思想，不同分类器对应不同执行器（策略），但只有分类器有效时，相应执行器（策略）才会被执行。分类器支持组装式关联多个属性校验器，同一属性校验器可被多个分类器复用，具有较好的灵活性和扩展性。此外， ACE 组件可将代码逻辑结构化，提升应用代码的可读性。
思考
一周岁技术新人的非严谨思考
“业务需求的局部性原理”
大家都听过计算机系统的局部性原理，其实业务需求也存在“局部性原理” 。小到多打一行日志、多传一个参数，大到多留一个扩展点、抽象一个服务，这都在为后续需求留余地。写代码时多做一步，不写一次性代码，也许反而能减少后续工作量。
“应用代码的破窗效应”
在实际需求开发过程中，我们往往会参考原有代码实现。代码风格或结构设计是具有传染性的，糟糕的代码风格和架构设计会使应用陷入破窗效应。一个不成熟的思考，是否绝大部分应用都难逃破窗效应？即使前期有较好的架构设计，但由于业务发展和人员流动，原有架构约束依然有可能过时或被忽略。
“业务团队的技术挑战”
【归因组件ACE：订单归类技术解决方案】在集团的“关怀”下，业务型技术团队的技术越做越轻，业务越做越重。开箱即用的中间件，让业务团队变得“没有技术挑战” 。刚参加工作的这一年，常常焦虑个人技术成长。回过头想，对于业务团队而言，技术挑战也许在广不在深。大多数情况下，技术型团队或许在和机器打交道，考验技术深度与钻研能力；业务型团队则在和商业打交道，考验技术架构与抽象能力。孰好孰坏似乎没有绝对答案。