个人代码所有权重要吗？[关闭]

我正在与一些同事争论整个代码库的团队所有权是否比其各个组件的所有权更好。

我非常支持为团队中的每个成员分配大致相等的代码库份额。它使人们为自己的创作感到自豪，为错误筛选器提供了分配入场券的明显第一位，并有助于缓解“破窗综合症”。

它还集中了一个（或两个）团队成员对特定功能的了解，从而使错误修复更加容易。

最重要的是，它是由拥有大量投入的人而不是由委员会来决定重大决策的最终决定权。

如果有人要更改您的代码，我不主张要求获得许可；当然，也许代码审查总是对所有者负责。我也不建议建立知识孤岛：这种所有权不应该排他。

但是，当向我的同事提出建议时，我得到了很多回击，当然比我预期的要多得多。

因此，我问社区：您对在大型代码库上与团队合作有何看法？关于保持集体所有权，我缺少什么吗？

我相信，从长远来看，团队所有权会更加有益。

您只需要查看以下两种情况，以了解为什么将知识集中在最少的人数上却不那么理想：

• 团队成员遇到不幸的事故
• 团队成员遇到更好的就业机会

自然，撰写特定章节的人员将对此有所了解，但不要屈服于使他们成为唯一的知识孤岛的诱惑。孤岛 将通过长期的痛苦给您带来短期的胜利。

仅仅因为您没有编写代码段的个人所有权，因为您编写了代码，并不意味着您仍然不会拥有“为您的创作感到骄傲”的方面，等等。我认为拥有团队所有权不会很大减少任何个人对所编写代码拥有权的感觉。

最终，团队拥有代码。但是出于您提到的所有原因，我们已经为代码的特定部分指定了个人作者。每个作者对其代码部分负主要责任，对整个代码库负第二责任。

如果部分代码库出现问题，我会尝试找最初为修复程序编写代码的人。当然，没有什么可以阻止其他团队成员应用修复程序。所有团队成员都应该熟悉其他所有人的代码。但是我们总是尝试首先从原始作者那里获得修复。毕竟，他们编写了代码。他们是最熟悉的人。

我在团队环境中工作过，因为人们不会对编写的内容产生主人翁感，因此他们没有被迫编写出色的代码，而只是编写普通代码。

我出于商业立场同意在传播有关产品知识方面的理由；现实情况是，随着时间的推移，专注于任何领域的个人将变得更加精通该领域。

忽略这就是忽略科学。不幸的是，大脑无法保留所遇到的一切。它回想起在给定时刻有效和有价值的东西，甚至随着时间的推移而减少。

我倾向于同意您的看法，即拥有较大代码库中特定模块或隔离专区的所有权通常会产生更好的结果。有人在没有任何通知的情况下离开会阻碍成功吗？当然。但是，假装团队中的每个人都应该对代码库有相同的了解，这是幼稚的，无济于事。它试图保护代码。出于明显的原因，保护代码是企业的职责。企业在保护代码上所花费的精力常常会变得一样有害。

您不确定团队中的每个球员都能踢四分卫吗？我认为确保团队成员在整个代码库中的利益与尝试使团队中的每个球员都能以令人满意的水平发挥四分卫的作用相同……这并不合计。你有备份吗？当然可以。但是团队成员应该在团队中拥有一个身份。相信每个人都是一样的，是在寻求不同类型的痛苦。

我不知道个人拥有代码是个好主意。至少从某种意义上说，人们可以说“这是我的代码，我将按照自己的意愿去做”。也许最好说您应该拥有单独的代码管理权：代码应归团队所有，但是团队由一个特定的人委派责任和权限。

这样做的原因是，如果这是每个人的责任，那就不是任何人的责任。

我会出于以下原因而拥护团队所有权：

• 整个项目的代码一致性
• 促进对代码的讨论，这总是导致更好，更经过审查的解决方案
• 如果一个团队成员生病了（或更糟），则整个代码段都不会延迟
• 团队成员可以在项目的所有部分上工作，这有助于使代码审查内置到开发过程中

专业化很好-对于大型代码库，从长远来看，这可以节省大量的通信时间-但所有权不是。

我的意思是，态度应该是团队存在错误，而没有人应该说“哦，只有X可以触摸该代码，所以这不是我的问题”。如果您是团队的一员，则有责任尽可能地修复整个代码库中的错误，并正确地进行操作。X人可能是这样做的最佳选择，但是任何人都必须这样做。这自然要求以允许和邀请团队成员一起使用的方式编写代码。具有粗糙的代码将禁止这样做，因此请争取清晰，简单的代码，因为这使大多数开发人员都可以使用它。您可能需要进行同行评审，以保持这种状态。

我必须不同意您的意见：对代码库的团队所有权比对个人所有权更好。

个人所有权的明显缺点是，如果某个员工发生了某些事情（被解雇，退休，患病等），那么除非他/她编写了非常干净的代码，否则其他人可能要花一些时间才能采用该员工的代码，尤其是当他们还必须管理自己的代码时。

它们也是太多工具，可以简化团队所有权。代码审查，源代码控制–这些是鼓励团队参与整个代码库的事情。此外，如何将代码库的特定部分分配给一个人？您是否只是说只有此人才能修改此文件？

最后，我认为如果代码库的一部分损坏了，就很容易责怪负责它的人，这只会引起更多的问题。

我认为您同时需要两者，因为这两种方法之间存在紧张关系。

如果对于任何一段代码来说，只有一个人可以使用它，那么从长远来看，这对于公司来说确实很糟糕，尤其是随着代码的增长，因为每个开发人员都会陷入失败的境地。另一方面，个人代码所有权（希望）可以缩短交付时间，因为开发人员通常更喜欢这种方法（激励性），因为开发人员非常了解代码，等等。还有一个时间问题：应该有可能根据业务需求在特定项目上重新分配开发人员，但如果每天这样做，那太可怕了（如果仅仅是因为开发人员讨厌它，还因为转换成本太重了，而您花费了大部分时间在做没有）。

国际海事组织，经理的职责之一是在两者之间找到良好的平衡。代码审查，编码标准，一套工具的标准化也应有助于减少故障问题的产生。毕竟，可维护代码的重点是解决此问题。

我认为集体代码所有权比个人代码所有权无与伦比。

我对卡车的论点并不感到烦恼-在个人所有权模型中，就失去他人而言，失去所有者的代价是昂贵的，但是这种事件很少发生，因此摊销成本很低。

相反，我认为集体代码所有权直接导致了高质量代码。这有两个非常简单的原因。首先，因为痛苦的事实是您的某些程序员不如其他程序员那么好，并且如果他们拥有代码，那么这些代码将很糟糕。使您的更好的程序员可以使用它。其次，代码审查：如果每个人都拥有代码，那么每个人都可以对其进行审查和改进。即使是优秀的程序员，如果留在自己的设备上，也会编写低于标准的代码。

我说这是基于我当前项目的经验。我们的目标是练习集体所有权，但是系统的某些部分已经变得专门化了-我和另一个人实际上是构建系统的所有者，例如，有一个人正在处理传入数据提要的大部分工作，从事图像导入的其他人，等等。在其中一些领域（尤其是我必须承认的我的领域！）中，代码质量受到严重影响-存在错误，误解，污点和骇客，这些代码根本无法在团队中引起其他人的注意。

我注意到，您可以通过拥有单独的代码所有权而获得集体代码所有权的一些好处，其中特定代码的所有权定期在不同的程序员之间移动（例如，每三个月或每个发行版-甚至每个迭代？）。 。相当于作物轮作的编程方式。那可能很有趣。不过，我不会自己尝试。

我认为团队代码所有权没有让多个贡献者了解主流子系统的基本体系结构重要。

例如，我们团队中有几个人为服务器产品制作管理网页。我们构建了一个定制的服务器端脚本引擎，以便我们可以直接从Java脚本或html调用服务器上的C函数。我认为更重要的是，我们的“网络”人员了解如何使用此引擎，而不是彼此成为其他网页应用程序的共同所有者。

我认为您在编写代码时会拥有代码的个人所有权，然后将其移交给团队。这样，每个人都承担责任并做出贡献。每个人都应该修复他们创建的编码错误。与代码审查一起，可以创建更高的标准。没有人想要别人来清理工作。

考虑更多的责任，减少所有权。毕竟，无论谁写支票，都是真正的所有者。

吉姆，我在那100％上与你同在。我在工作地点正处于完全相同的斗争中-这就是为什么我偶然发现了您的问题。

我的看法是：“当所有人拥有它时，没有人拥有它”。

对我来说，编码质量没有比所有权和责任更重要的因素。

现实生活中的例子很好地说明了这一点。您会更好地照顾哪种：私人草坪还是社区公园？很明显。

顺便说一句，不必为了“团队灵活性”而折衷。这仅表示当某人拥有某物时，他拥有该东西-且仅在一天之内。

对我而言，这取决于您团队的动力。

例如，如果您的团队没有按照标准，同行评审，有条不紊的测试进行统一，或者如果您的团队的成员之间的能力水平差异很大，那么最好寻求更强的代码所有权概念带有更多黑匣子式模块化思维方式。

缺少此功能，例如，您甚至不知道“ SOLID”的意思并想一直为该接口添加新的折衷功能以“方便”的人可能会很快破坏您精心设计的符合SOLID原理的界面。到目前为止，这是最糟糕的情况。

您可能还会遇到草率的同事，他们的错误修复想法是在不了解根本问题的情况下修复症状（例如：尝试通过仅在代码中放入替代方法来隐藏崩溃并转移致命错误来解决崩溃报告。对其他人的副作用）。在这种情况下，它并没有破坏接口设计那么糟，并且您可以通过精心构建的单元测试来保护自己的意图。

理想的解决方案是使您的团队变得更严格，以至于作者权和所有权这一概念不再变得如此重要。同行评审不仅涉及提高代码质量，还涉及改善团队合作。标准不仅要保持一致性，还可以改善团队合作精神。

但是，在某些情况下，同行评审并实际上使每个人都符合标准是没有希望的，并且会带来很多没有希望的经验不足的批评家。我想说的是，代码所有权或团队所有权是否具有更高的优先级，将取决于您的团队实际执行有效的同行评审并实际上使每个人都从中受益的能力（包括评审本身） ，从而在思想观念和标准上变得更加紧密）。在庞大，松散和/或分散的团队中，这似乎是无望的。如果您的团队能够像一个“小队”那样运作，甚至您几乎都无法说出谁写了什么，那么独占将开始显得很愚蠢。

在这种非常不理想的情况下，这种代码所有权概念实际上可能会有所帮助。它试图弥补最坏的情况，但是如果团队合作通常无法在作者的代码周围围上栅栏，它会有所帮助。在那种情况下，这会减少团队合作，但是如果“团队合作”只导致脚趾踩踏，那会更好。