代码治理及研发心理

在经历了架构治理的多个项目，有顺利达成预期的（如废弃代码治理），也有不太符合预期的（如问题函数的存量/增量治理、服务耦合治理）。通过对比这两种情况，以及对不符合预期项目的实际case的分析、研发的反馈、指标数据分析，本文尝试分析研发收到治理任务时的心理，来理解研发做出决策的关键因素有哪些，给后续的治理任务提供更多信息。

以下分为两种场景进行讨论，一是治理不符合预期的任务，研发多采取延宕治理策略。二是治理符合预期的任务，研发采取协助治理的策略。

一、延宕治理场景

任务场景：以问题函数的增量治理场景为例，研发在提交MR后，问题函数的CI卡点会分析本次变更的函数中是否有高复杂函数和重复函数，如存在，则进行卡点提示。

治理效果：3个业务线推广后，卡点跳过率为91%，远没有达到预期，具体分析可见抽象假设和验证假设。

心理分析：

我作为研发，为了完成需求，进行了代码开发和本地测试后提交了MR。这时被一个问题函数检测的卡点拦截了，卡点检测出1个高复杂函数。

我仔细看了这个函数，嚯，竟然有249行。虽然我只增加了一个if条件，不过有一说一，这个函数确实很复杂和需要被重构。① 但是我只增加了一个if条件，改动很小呀。让我去修改，多多少少有点心理不平衡。② 这个函数有十几个人修改，经历了一年的迭代才逐渐劣化到如此。这是大家的函数，我为什么要去改呢，由别人去改不更好吗。本该是“谁污染，谁治理”，没曾想却变成了“大家污染，无人治理”，公地悲剧莫如是。③ 这种高复杂函数的修改成本看起来就很高，远高于我为了实现需求的必要变更成本。④ 修改后的验证工作也需要花更多时间，例如写单测覆盖关键路径。⑤ 随之需要承担的上线风险也高了很多，比我的血压都高。⑥ 就算我费劲改了，除了出力和承担风险外，好像也不会有什么好处。不改又不会有坏处。⑦ 再说了，上线压力这么大，这种代码优化类任务还是往后放放吧。

研发的直观体感的关键词是：治理成本高、个人收益低。

二、协助治理场景

任务场景：以静态废弃代码下线场景为例，下线工具在保障安全的情况下自动下线代码，然后经过编译成功的验证后，以飞书卡片的形式推送给研发。推送给研发的任务中有八成是无风险的可自动合入的工单，研发只需要知晓即可，无需动作反馈。另外两成是低风险的手动合入工单，研发可以在收到的卡片里点击“合入”按钮即可合入，或者点击“取消合入”来取消工单。另外，卡片只在工作日的上午推送，避免假期推送后被Miss。

治理效果：合码率＞80%，超出预期。

心理分析：

我作为研发，上午到公司后收到一个废弃代码下线的推送。① 卡片设计的挺简洁，那“我”仔细看下是啥吧。哦，是关于我负责仓库的废弃代码下线信息的卡片。② 上面说已经在其他仓库下线了100万行代码，看起来应用挺广的。不过为了安全考虑，我还是看下删除的内容是什么吧。嗯，看起来没啥问题。根据文档了解到其下线原理很安全，并且这个是编译通过后才推送的工单，感觉MR合入的风险很低。③ 那我需要做什么呢？哦，这是一个自动合入工单，在3天后自动合入。流程很简洁啊，不用操作挺好的。那就这样吧，让他自动合入吧。

研发的直观体感的关键词是：承担风险低、零修改成本。

三、代码治理启示

代码治理是由架构治理小组发起的，去治理研发资产的行为。这需要研发的参与，但是决定研发参与积极性的是研发承担的成本和风险。成本可细分为修改成本、验证成本。如果要提高治理效果，那么就需要改变这几个变量：

• 减小研发修改成本，最好是零成本。比如废弃代码下线由工具完成代码下线和生成MR；复杂函数治理由LLM进行治理。

• 减小研发验证成本，最好是零成本。比如依托单元测试、集成测试、流量Diff等自动验证；工具能力完备，结果置信度高。

• 减小研发承担风险，最好是零风险。比如废弃代码下线在编译成功后再推送给用户确认；

• 工具/平台/流程易上手、易理解、易操作。比如操作步骤少，信息提示准确，交互简单明了。