我们如何改进团队代码所有权模式
我们正在尝试一种新的方式来处理代码所有权，并开发了一个名为 Codenotify (1) 的工具。使用 Codenotify，开发人员可以轻松地订阅 Git 仓库中变更，而无需担心这些文件的变更在审查时候被阻止的情况。
https://github.com/sourcegraph/codenotify
发现问题
我们代码托管在 GitHub 上，到目前为止，我们一直在每个仓库中使用 GitHub CODEOWNERS 文件。当有pull request 时，GitHub 将查看 CODEOWNERS 文件来确定自动添加哪些审查者。
随着团队在过去一年中的成长，我开始观察一些模式，这些模式使我认为这种自动分配代码审查者的方式存在缺陷。
在不同位置涉及多个文件的 pull request 时，最终会带有大量自动添加的 review。
开发者不会审查他们收到的所有 reveiw 请求，因为没法确定他们个人是否与 review 相关（例如：他们可能被通知是因为他属于代码一部分，但并不是这个变更最好的审查者）。
开发者（尤其是新人）速度越来越慢，因为他们不清楚是否需要等待所有自动添加的 review 审查。一些工程师使用 CODEOWNERS 作为他们所关心的代码变更的通知方式，但他们并没有打算（或没有能力）审查这些修改。
我的诊断，以前的模式存在两个问题：
自动分配的 review 准确度很低，并且会放慢团队效率。
CODEOWNERS 的设计（其名称以及界面处理方法，自动添加代码审查人）创建了一种看门人文化来进行代码审查，这阻碍了更高层级的思维方式。
验证
我认为需要去除 CODEOWNERS 并引入一个新的东西，但我需要进一步验证，团队其他成员是否和我一样感受到了痛苦？继续使用 CODEOWNERS 是否是一个可行的解决方案？
为了了解团队的想法，我开了一个 pull request，提议以上面的理由删除 CODEOWNERS，并要求整个团队提交匿名反馈。结果如下：
调查者可以进一步评论，表达了他们对该提案的支持、关注和建议。以下是几个有代表性的意见：
“老实说，我从未从 CODEOWNERS 文件中获得价值。我从不研究它们，我从不相信 GitHub PR 中的自动添加审查者功能。”
“这会导致写代码多的人，被邀请到更多的 review 中？”
“我使用 CODEOWNERS 是为了获得 PR 的通知”
“替换为 owner”
“我认为删除 CODEOWNERS 会让不了解项目背景的新开发人员更加难以确定谁是合适的审查者。”
很明显，我们有相关需求，但是 CODEOWNERS 并没有完全满足我们，并且我们没有能力改变其行为。
寻找替代品
已经有足够的证据表明存在问题，并证明寻找替代方案的合理性。
我在 Fullstory 的博客中找到了它们如何在 CODEOWNER 中遇到类似问题的信息，并最终创建了一个 bot。我本来想尝试使用他们的机器人，但不幸的是它不是开源的。
我的一些同事（包括我自己）在 Google 工作过，因此我们熟悉内部使用和 Chromium 项目中使用的 OWNER 格式。这本来是对 CODEOWNER 的一种改进，因为多个文件比单个大文件更易于维护，并且 Chromium 的实现明确尝试最小化审查者的数量，但是我担心这会继续创造一种围绕修改代码的守门人文化。
我想要一个解决方案：
允许开发者订阅他们关心的代码修改，而不需要担心需要参与所有这些变更的审查。
允许开发者使用自己的判断力和代理权，有意识的选择他们认为有价值的反馈意见的审查者（例如：谁实现了被修改的代码？谁审查了正在修改的代码？谁及时提供了宝贵的反馈？）。
在一个庞大且不断发展的代码库中，要易于理解和维护。
在设计 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 月底我与团队再联系，以了解他们对变更进行了一个多月的体验后的感受。令人兴奋的是，无论结果如何，我们都会学到新的东西。
本文由高可用架构翻译，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。