架构度量项目复盘

一、指标建设阶段

1）资源有限，项目周期长

• 指标数量较多（23个指标），且开发人力少（1-1.5人力），项目周期验证较长（近半年才完成指标开发和看板搭建）。

2）定义了23个指标，最后经验证只有三个指标（热点代码复杂度、热点代码重复度、服务耦合）有明确的优化价值，占比13%。

• 初始定义多的原因：对于要度量的问题以及如何解决问题没有想清楚，期望通过较多的指标来发现问题。“定义指标→发现问题”的路径，不如“发现问题→定义指标”的路径具有落地性。另外，指标计算口径较复杂，较难理解，后期调整为简单的计算口径。
• 价值不高的原因：距离业务较远，难以定义出业务真正关心的指标，导致指标偏主观，陷入隔靴搔痒的境地。
• 试点阶段未拦截的原因：试点服务验证时未发现问题，是因为有个错误的思想“未怀疑指标有问题，而是认定服务无问题”。正确的思路是：抱着指标可能有问题，先验证指标是否有问题。即应该验证指标是否有效，然后再进行建设和推广。

二、指标推广阶段

1）业务认同度低，推广成本高

• 架构优化收益偏长期，业务痛感不深，一线研发不愿意投入人力优化，用户价值 = (新体验 - 旧体验)- 替换成本中的用户价值不高。研发在大部门的问卷的负向反馈，也证明了这点。

2）指标度量有局限性，需要结合研发的经验进行判断，研发负担大

• 指标度量的内容偏通用，发现的问题抽象层级较低。
• 指标数据不包含业务属性、需求背景等信息，需要结合研发的经验进行判断。例如，不再迭代不需要治理、隔离性设计导致的重复、多团队协作导致的权责分散等。
• 这导致推广过程需要对研发进行打断，需要研发参与标记、修改、验证三个阶段，研发负担较大。

3）静态废弃代码下线项目不在预先的23个指标中，反应出架构优化方向并没有清晰的路线

• 早期聚焦在热点代码的治理，直播侧建设完整的静态下线工具后，在决定进行静态代码下线。
• 这里有两个问题：对价值的判断前后不一致；未聚焦在一个点，精力太过分散。
• 处于跟随者的角色，对于治理的目标和路径不清晰。

4）服务耦合要解决的问题域过大，难以推进

三、其他

• 早期对架构优化项目只有大体的治理思路，没有足够清晰的目标、治理路径，以及对解决问题优先级的判断。
• 与业务没有建立信任和协作关系，业务的架构优化需求不会上浮到本部门，业务倾向于自治或者和兄弟团队合作。另外业务团队的一些优化项目，我们由于缺失业务Context，往往觉得优化价值低，也很难想到这里有痛点问题需要解决。
• 业务侧对架构优化看法：业务成熟后，单点优化的空间越来越小，需要深入理解业务才能发掘出有价值的优化点。
• 架构理念难以统一，也是导致难以推进的一个因素。
• 随着架构治理的过程，发现了更多的可治理点，如MR阶段架构治理卡点、建设架构治理的平台、废弃资产治理等。这说明，有些事如果方向是对的，即便现在没有足够的数据做支撑，也可以激进一点，敢于投入，才能发现和验证其价值。