易于维护的企业文化。 但是，只有少数几家公司正在积极探索对生产力产生重大影响的公司文化的少数特征，因为这是最困难的。
对于软件团队而言，代码所有权是工程设计的关键指标。 在本实用指南中，我们将精确分析您如何在开发团队的日常工作中实现这一原则，从而使代码库的运行状况得以维护。
我很幸运地与世界上最好的开发人员会面-在Stepsize，我每天与他们合作。 在讨论如何产生技术债务的过程中，与Skyscanner，Spotify，Palantir等公司的领先开发商一起，总是提出一个问题：所有权。
在紧密互动，快速发展的团队中（即现代团队），开发人员可以致力于代码库的任何部分，代码很容易混乱，并变成类似于科学怪人的怪兽。 而且当情况变得很糟时，应该像Marvel上尉那样介入，并通过一次大的重构来修复所有问题。
为了避免这种情况，开发团队尝试遵循Robert S. Martin的许多重要技巧之一（“ Bob叔叔”），即“ Boy Scout Rules ”： 将代码保持在比您之前更好的状态 。 这是VSCode的免费扩展，可帮助您使此操作变得更加容易 。
尽管如此，尽管开发人员具有技能水平和最佳激励，但似乎软件开发的一成不变法则是技术债务不断累积-直到变得太多为止，然后我们必须花时间进行大量重构。 我们不愿意将其作为软件开发生命周期的一部分。
也许这归结为缺乏纪律？
所以我以前想过。 然后我遇到了Snyk.io的首席架构师Gareth Vizaji ，他用以下短语打我：
所有权是工程福祉的主要指标。
他是什么意思 他怎么能发表这样的声明？
大量研究表明，当团队成员拥有自己的劳动成果，对管理人员负责并对成功和失败承担责任时，各种各样的好事就会开始发生。
不幸的是，在实践中实现这一目标并不容易。 显然，部分原因是无法衡量工程生产率 ，并且在任何情况下，现代开发实践都可以视为鼓励不良代码拥有权。 事实是，直到现在，要正确衡量开发团队的所有权还是非常困难的……因此，我们甚至都不知道该指标的预期效果如何。
幸运的是， 最近的科学研究表明，代码所有权-开发团队中模糊的“所有权”概念的最佳间接度量-可以通过Git commit活动来度量。 这是代码库状况的一个很好的领先指标。
随着时间的推移，许多开发人员对其进行更改的代码库部分会变得混乱不堪，而很少有人使用的代码库通常处于更好的状态。 不要相信我-Microsoft的好人已经通过自己的例子研究了这一点。
资料来源：微软研究
我几乎可以听到一些人在喊着您不希望只有一个开发人员才是唯一可以触摸任何一段代码的人的情况-这种方法具有严重的副作用。 我了解您，但这不是我们提供的。
听我说到最后。
有多种形式的代码所有权适用于不同的情况。
集体所有权和缺乏所有权
集体所有权是指代码共同拥有的所有权，但是明确规定了责任和时间表。 如有必要，每个团队成员都可以从事任何子系统或服务。
非所有权 -几个开发人员对同一个子系统进行更改的情况，但是行动的协调，对质量的责任或团队内部的沟通很少。 在这样的系统中，不应期望高质量的工作。
资料来源： 微软研究
您可以通过将无所有者代码和唯一所有权添加到堆中来进一步继续该分区，但是我不想错过主要内容，因此，以下图表显示了代码所有权的形式：
集体所有权应该是您的默认选择，也是您应该争取的所有权形式。 请注意，这并不意味着您团队中只有一名开发人员有权更改代码，或者对代码的任何修改都需要其批准。 这仅意味着，团队中的每个人都应该与他讨论任何问题，这是完全清楚的，并且代码所有者很可能会处理代码审查（代码审查）。 这将使团队中的每个人都可以提高代码编写标准，并了解自己的代码是如何被修改的。
所有者负责其代码的状态，管理人员应向他询问。 这并不意味着要为泄漏到他的代码中的每个错误都需要殴打他； 这意味着所有者有权做出有关代码质量和技术债务的决定； 他们将通过附加的支持指标（例如，凝聚力和重复活动（客户流失））对这些决策负责（更多详细信息，请参见我们关于技术债务指标的文章）。
所有权缺乏或所有权薄弱是集体所有权的对立面，在大多数情况下，应避免这种所有权形式。 正如已经提到的（这听起来很明显），对于package.json这样的文件，如果没有明确定义的所有者，这是正常情况。 不必极端。
孤立的代码
缺乏所有权的最不愉快的类型，即代码所有权形式的范围的边缘之一。 您绝对不需要这种所有权形式。 不惜一切代价避免使用它……除非它当然是永远不会碰到的代码。 但是这样的代码非常罕见。
如果该代码的主要开发人员已停止对代码库进行任何更改，则该代码将被视为没有所有者。 也许他离开了组织，或者从开发人员转到了经理。 无论如何，您都会遇到严重的问题-代码也是如此。
但是，有一个解决方案。 您需要将源代码转换为最适合它的任何其他所有权形式。 为了避免在代码库中出现任何无所有者的代码，请确保您的解雇或转案案例计划包括其旧所有者将新的代码所有者引入业务过程。 您可以通过自动分配它们以查看对代码更改的请求来使它们更容易。 如果没有这种方法，您可以简单地指定合适的代码所有者。
无论选择哪种方法，都不要将无主代码保留在代码库中。 你永远不知道如果让他留给命运的命运会给他带来什么。
唯一所有权（绝对所有权）
这是代码所有权范围的另一端。 和他在一起，一切都会变得美好而艰难。
如果所有者是唯一可以更改或批准对代码进行更改的开发人员，或者实质上是所有者是过去曾经对代码进行过更改的唯一人员，则认为该代码是唯一的所有权。
小型创业公司在工作中经常会遇到类似的做法。 通常，每个开发人员负责单个文件的整个历史记录，并且期望保留该文件的所有权。 这不是世界的尽头。 毕竟，初创公司的资源有限，您需要做出一些牺牲。 但是如果开发人员有一天移动总线，那么这部分代码将是无主的。 在这种情况下，您应该有一个备份计划。
在大型工程组织中，“ 总线系数 ”低可能是一个现实问题，尤其是在代码库的关键部分，人员流动率高以及公司招募的技术债务过大的情况下。 例如，如果您离开了一个将整个手动配置的付款系统都弄糟的开发人员，那么您将很头疼-如果您想更改定价模型，或者在其代码库中发现一个导致您执行错误操作的错误，许多个月以来，他们从最大客户那里收到的钱减少了。 然后，要么有人需要聚在一起，尝试理解对代码进行更改的代码，要么您必须在支付系统上声明技术破产并从头开始重写（但是在执行此操作之前，请阅读此内容 ）。
不要让这种情况发生在您身上。
但是，有时只有代码的所有权是可以接受的，甚至是推荐的。 您可能希望为代码库的以下部分建立这种所有权形式：“如果这部分发生故障，我们可以折叠，因为这样企业将无法向我们支付薪水，否则我们将入狱”。
在这种情况下，即使您想在几个开发人员之间散布有关代码关键部分的知识以保持足够高的总线系数，您也可能想建立禁止插入拉入请求的规则，而无需相应代码的唯一所有者的批准。
总结
争取对代码库中的绝大多数文件拥有集体所有权（任何给定文件占代码所有权的50％-90％），并在需要时更加严格地提高代码所有权和减少技术债务。
好处如下：
- 更高且正确维护的代码编写标准。 在消息灵通的小团体中，坚持高标准更为容易。 这不仅适用于开发人员修改自己的代码，而且适用于由其同级编写的代码审查，并且会影响他们所拥有的部分。
- 促进沟通。 明确明确的所有权意味着团队中的每个开发人员都知道谁将最好地回答他的问题。
- 更集中和有效的重构。 如果您决定还清部分技术债务，那么拥有适当代码的强大开发人员最适合此工作。 使用所有权，连接性和重复性活动指标来概述代码库中的关注领域。 您的开发人员将明智地将其预算用于技术债务 ，再也不会再花费时间来偿还不值得的技术债务。
- 总线因素永远不会失控。 您可以使用代码所有权来组织组织中的知识共享。 如果所有权程度过高，请指派其他开发人员来检查代码和与更改代码相关的任务。 您将逐步改善所有权指标，这将导致更高的代码质量和更少的技术债务。
像一切真正值得的事情一样，创建代码所有权的工程文化（并遵循它！）需要花费时间和精力，但它会带来回报。 此因素直接影响您可以想象的几乎所有KPI工程状况。 将其嵌入您的公司文化中，从长远来看，它将成为您巨大的竞争优势。