我们如何改进团队代码所有权模式

我们正在尝试一种新的方式来处理代码所有权，并开发了一个名为 Codenotify (1) 的工具。使用 Codenotify，开发人员可以轻松地订阅 Git 仓库中变更，而无需担心这些文件的变更在审查时候被阻止的情况。

1. https://github.com/sourcegraph/codenotify

发现问题

我们代码托管在 GitHub 上，到目前为止，我们一直在每个仓库中使用 GitHub CODEOWNERS 文件。当有pull request 时，GitHub 将查看 CODEOWNERS 文件来确定自动添加哪些审查者。

随着团队在过去一年中的成长，我开始观察一些模式，这些模式使我认为这种自动分配代码审查者的方式存在缺陷。

• 在不同位置涉及多个文件的 pull request 时，最终会带有大量自动添加的 review。

• 开发者不会审查他们收到的所有 reveiw 请求，因为没法确定他们个人是否与 review 相关（例如：他们可能被通知是因为他属于代码一部分，但并不是这个变更最好的审查者）。

• 开发者（尤其是新人）速度越来越慢，因为他们不清楚是否需要等待所有自动添加的 review 审查。一些工程师使用 CODEOWNERS 作为他们所关心的代码变更的通知方式，但他们并没有打算（或没有能力）审查这些修改。

我的诊断，以前的模式存在两个问题：

1. 自动分配的 review 准确度很低，并且会放慢团队效率。

2. CODEOWNERS 的设计（其名称以及界面处理方法，自动添加代码审查人）创建了一种看门人文化来进行代码审查，这阻碍了更高层级的思维方式。

验证

我认为需要去除 CODEOWNERS 并引入一个新的东西，但我需要进一步验证，团队其他成员是否和我一样感受到了痛苦？继续使用 CODEOWNERS 是否是一个可行的解决方案？

为了了解团队的想法，我开了一个 pull request，提议以上面的理由删除 CODEOWNERS，并要求整个团队提交匿名反馈。结果如下：

调查者可以进一步评论，表达了他们对该提案的支持、关注和建议。以下是几个有代表性的意见：

• “老实说，我从未从  CODEOWNERS 文件中获得价值。我从不研究它们，我从不相信 GitHub PR 中的自动添加审查者功能。”

• “这会导致写代码多的人，被邀请到更多的 review 中？”

• “我使用 CODEOWNERS 是为了获得 PR 的通知”

• “替换为 owner”

• “我认为删除 CODEOWNERS 会让不了解项目背景的新开发人员更加难以确定谁是合适的审查者。”

很明显，我们有相关需求，但是 CODEOWNERS 并没有完全满足我们，并且我们没有能力改变其行为。

寻找替代品

已经有足够的证据表明存在问题，并证明寻找替代方案的合理性。

我在 Fullstory 的博客中找到了它们如何在 CODEOWNER 中遇到类似问题的信息，并最终创建了一个 bot。我本来想尝试使用他们的机器人，但不幸的是它不是开源的。

我的一些同事（包括我自己）在 Google 工作过，因此我们熟悉内部使用和 Chromium 项目中使用的 OWNER 格式。这本来是对 CODEOWNER 的一种改进，因为多个文件比单个大文件更易于维护，并且 Chromium 的实现明确尝试最小化审查者的数量，但是我担心这会继续创造一种围绕修改代码的守门人文化。

我想要一个解决方案：

1. 允许开发者订阅他们关心的代码修改，而不需要担心需要参与所有这些变更的审查。

2. 允许开发者使用自己的判断力和代理权，有意识的选择他们认为有价值的反馈意见的审查者（例如：谁实现了被修改的代码？谁审查了正在修改的代码？谁及时提供了宝贵的反馈？）。

3. 在一个庞大且不断发展的代码库中，要易于理解和维护。

在设计 CODEOWNER 和 OWNER 时都没有考虑到这些需求，因此我开始考虑新工具是什么样的，最后我选择实现 Codenotify。

设计 Codenotify

顾名思义，Codenotify 是围绕通知的概念设计的，而不是用来建立代码的“所有权”或授权“审查者”。Codenotify 在命令行上工作，并且与代码托管无关，但是它也可以打包为 GitHub Action，因此像我们这样的 GitHub 上的仓库很容易采用。GitHub Action 通过在注释中提及订阅者来将通知发送给订阅者，而不是将其添加到 GitHub 上的正式“reviewer”或“assignee”列表中。

通知规则存储在任何目录的 CODENOTIFY 文件中。由于 CODENOTIFY 文件与它们具有规则的文件相邻，因此这使规则更易于维护并且对移动代码不那么敏感。

Codenotify 规则和文件在 CODEOWNER 的语法中很熟悉，但是更容易理解，因为每个规则都是可加的，而不是分层的。这意味着您可以了解单个规则的行为，而无需考虑任何其他规则（与 OWNER 或 CODEOWNER 不同）。

如果您想了解有关 Codenotify 的更多信息或自己尝试一下，那么可参阅项目的 README 文件。

开始试验

在有了 Codenotify 工作原型之后，该进行实际试验了。试验可以发现没有预料的成本和收益，并了解假设的问题是否是实践中的问题。

2020 年 9 月 16 日，我们删除了 CODEOWNERS 文件，从此以后，同事们一直在添加 CODENOTIFY 文件。

在 10 月底我与团队再联系，以了解他们对变更进行了一个多月的体验后的感受。令人兴奋的是，无论结果如何，我们都会学到新的东西。

参考阅读：

本文由高可用架构翻译，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式