*代码所有者*系统：这是一种有效的方法吗？[关闭]

我们团队中有一位新开发人员。我们公司正在使用一种敏捷方法。但是开发人员还有另一种经验：他认为必须将代码的特定部分分配给特定的开发人员。因此，如果一个开发人员创建了一个程序过程或模块，则认为该过程/模块的所有更改仅由他自己进行是正常的。

从好的方面来说，据推测，使用提议的方法可以节省通用的开发时间，因为每个开发人员都非常了解自己的代码部分，并且可以快速进行修复。缺点是开发人员并不完全了解该系统。

您认为该方法对于中等规模的系统（社交网站的开发）是否有效？

像许多这样的问题一样，我认为答案是：

这取决于

有理由相信，每个程序员都应该知道每一行代码的立场都是错误的。

如果我们暂时假设，对某段代码有深刻理解的人将比根本不知道的人进行更改的速度快5倍（对我的经验而言不是很大的信念），则大约需要一个月的时间的编码经验，以便对大型模块（也不是不合理的）有一个很好的理解，然后我们可以运行一些（完全虚假的和虚构的）数字：

• 程序员A：有深刻的了解
• 程序员B：无

假设程序员A每天完成1个工作单元。在5个工作日的4周内，他/她可以完成20个工作单元。

因此，程序员B从每天0.2个工作单元开始，到他/她第20天（在第21天他们和程序员A一样好）以0.96个工作单元结束，将在同一天完成11.6个工作单元20天期限。与程序员A相比，在那个月程序员B的效率达到了58％。但是，您现在拥有另一个知道该模块以及第一个模块的程序员。

当然，在一个像样的项目中，您可能有50个模块？因此，熟悉所有这些程序将花费您大约4年的时间，这意味着相对于A ... hmmm，学习程序员的平均效率为58％。

因此，请考虑以下情形：相同的程序员，相同的项目（A都知道，而B都不知道。）可以说一年有250个工作日。假设工作负载随机分布在50个模块上。如果我们将两个程序员平均分配，那么A和B在每个模块上都将获得5个工作日。根据我的一点Excel模拟，A可以在每个模块上完成5个工作单元，但是B只能在每个模块上完成1.4个工作单元。每个模块总计（A + B）为6.4个工作单元。这是因为B花费了大部分时间而没有使用他们正在处理的模块的任何技能。

在这种情况下，最好让B专注于较小的模块子集。如果B仅关注25个模块，则每个模块将获得10天的时间，每个模块总共需要3.8个工作单元。然后，程序员A可以在B不在使用的25个模块上每个花费7天，而在与B相同的模块上每个花费3天。每个模块的总生产率从6.8到7个单位不等，平均为6.9，这要高得多而不是当A和B将工作平均分配时，每个模块需要完成6.4个单元。

当我们缩小B工作的模块范围时，我们可以获得更高的效率（达到一定程度）。

训练

我还认为，对模块一无所知的人会比其他有更多经验的人打断做更多事情的人。因此，以上这些数字并未考虑到B花费在他们不理解的代码上的时间越多，A花费在询问问题上的时间就越多，有时A不得不帮助修复或解决B所做的事情。训练某人是一项耗时的活动。

最佳解决方案

这就是为什么我认为最佳解决方案必须基于以下问题：

• 您的团队有多大？让每个人的每个方面都受过交叉培训是否有意义，或者如果我们有一个10人的团队，我们是否可以确保每个模块至少被3个人知道？（拥有10个程序员和50个模块，每个程序员必须知道15个模块才能获得3倍的覆盖率。）
• 您的员工流动率如何？如果您平均每三年更换一次员工，而要真正了解系统的每个角落所花的时间要比花更长的时间，那么他们的培训时间就不够长，无法收回培训费用。
• 您真的需要专家来诊断问题吗？很多人都使用“如果那个人去度假该怎么办”的借口，但是无数次有人打电话给我，以诊断我没有经验的系统中的问题。经验丰富的人可以更快找到它，但这并不意味着您不能没有他们一两个星期。很少有软件系统对任务至关重要，因此必须在1小时而不是5小时内诊断出问题，否则世界将终结。您必须权衡这些风险。

这就是为什么我认为“取决于”。您不想在中间的两个程序员（每个10个）之间拆分20个模块，因为那样您就没有灵活性，但是您也不想在所有50个模块上交叉训练10个程序员，因为您损失了很多效率，您不需要那么多冗余。

这是一个可怕的主意。短期内它可能会更快，但是它会鼓励记录不良的，难以理解的代码，因为只有编写该代码的编码器才负责维护该代码。当有人离开公司或去度假时，整个计划就会变得毫无用处。这也使分配工作负载变得非常困难。当一个编码器“拥有”的代码出现两个紧急错误时，会发生什么？

您应该作为一个团队进行编码。人们自然会被分配任务，并专注于某些领域，但是应该鼓励而不是劝阻分担工作和共同努力。

这取决于问题的范围。

如果是一般性的东西（即简单的CRUD操作等），那么我同意Tom Squires（任何人都应该能够对其进行处理和编辑）。

但是 ...

如果有问题的解决方案需要领域专业知识（过去已经投入了很多时间，或者在实施之前需要做很多研究，因为这是您在工作要求中列出的专门知识，并非项目中的每个人都拥有），那么绝对应该为代码的这一部分分配一个所有者。话虽如此，任何人都应该能够根据需要对其进行修改，但是拥有项目该领域的人员应始终对其进行审查。

您不想让整个团队（或团队中的许多人）研究和学习相同的主题（浪费的周期）。指派一个所有者，但让他们记录他们的学习和设计，也许让他们进行有关该技术的非正式（或正式，无关紧要）的培训课程。

这是一个可怕的主意。我曾在一家使用这种方法的公司工作，这几乎是大量技术债务的秘诀。最重要的是，两个头脑几乎总是比一个头脑好。为什么？因为除非您是个白痴，否则您会知道自己不是一个完美的程序员，并且不会发现所有的错误。这就是为什么您需要一个团队的原因-更多的眼睛从不同的角度看相同的代码。

归结为一件事：纪律。您知道几个真正的程序员受过严格的编码风格训练吗？当您不遵守纪律进行编码时，您会采取捷径（因为稍后将“对其进行修复”）并且代码的可维护性受到影响。我们都知道“以后”永远不会到来。事实：当您立即向团队中的同伴负责时，采用快捷方式就比较困难。为什么？因为您的决定会受到质疑，并且总是很难证明捷径的合理性。最终结果？您将生成更好，更可维护的代码，这些代码也将更强大。

优势在于，并非每个人都需要研究和理解所有内容。缺点是，这使每个人都必须拥有自己的代码区域，而没有人知道如何维护它。

一个折衷方案是每个代码区域至少拥有2个所有者。然后有人可以去度假，找新工作或退休，仍然有人知道密码（并可以培训新的第二人称）。并非每个人都需要学习一切，这会更有效率。

不要一直有两个（或三个）人在一起工作。切换出不同区域的配对，因此在相关程序区域与其他人一起工作时，也会无意间共享知识。

是的，从短期来看，它的效率略高。这样就结束了好处。这甚至远远超过不了成本。

当他正在度假，出乎意料地生病，离开或被众所周知的公共汽车撞到时，会发生什么？当您想利用资源来更快地完成一项工作时，会发生什么？代码审查的有效性如何？经理，尤其是不在代码库中的经理，如何知道开发人员是在努力工作还是在努力？谁会注意到技术债务是否开始流失？

以我的经验，喜欢这种工作方式的人充其量是光荣的猎人，最坏的时候是懒惰的人。他们喜欢成为遇到特定问题的唯一伙伴，并且他们希望自己的代码保持私密性。他们经常喜欢快速编写代码，而不考虑可读性。

这并不是说，在一个由50个开发人员组成的团队中，每个人都应该了解所有代码，但是5-7个团队应该拥有一个足够大的模块以保持这些人员的工作能力。任何人都不应该拥有任何东西。

其他答案至少指出了三个问题。但我想尝试将它们一起对待。这两个问题是：

• 专业知识：团队中的某人对特定领域有详细的了解；这种知识独立于该领域在项目中的具体实施
• 领导力：尽管建设项目的工作可能会在许多开发人员之间共享；路线图以及有关重要实施细节的即时决策都在特定的团队成员或团队中的几个成员手中。
• egoless代码：实施项目的特定方式不依赖于团队中任何特定开发人员的编码风格，实践或知识；并且通过严格遵守众所周知的编码样式或维护良好的规范，任何新的团队成员都有同等的机会像经验丰富的开发人员一样了解项目的方式和原因。

当主题仅是专业知识之一时，项目的成功可能取决于对领域的高度了解。但这并不取决于特定专家对该领域的了解。专家虽然也许稀少而且很有价值，但实际上仍然可以互换。从他们的领域知识的角度来看，一位经验丰富的税务会计师对税务计划软件项目同样有用。问题成为专家将其知识转移到项目中的能力之一。

当主题仅是领导者之一时，项目的成功主要取决于项目负责人所做出决策的一致性和洞察力。尽管我们倾向于青睐在该领域具有经验或被证明是项目负责人的项目负责人，但这有时是次要的。如果一个案件的决定与下一个案件的决定是一致的，并且团队迅速执行每个决定，那么“领导者”可能会每天变化。如果工作正常；项目负责人不必“做出”很多决定，因为团队已经知道要做出什么决定。

我认为问题不是真正的egoless代码，但是在不讨论此问题的重要性的情况下很难谈论代码所有权。维护项目可能是开发周期的大部分。理解此问题的方法是想知道如果某些开发人员不得不立即离开它会发生什么。如果必须更换整个团队会怎样？如果由于依赖于某些关键参与者而使该项目受到怀疑，那么您将面临失败的巨大风险。即使您永远不会失去一个团队成员，简单的事实就是需要一个或几个开发人员来推进项目，这意味着您可能无法像选择更多开发人员那样高效地工作。

当代码具有应处理的问题时，代码所有权往往会阻止重构，创建开发瓶颈并引起自我问题。

我确实建议在更改之前咨询代码作者，即使高标准的代码应有足够的文档记录，单元测试，集成测试和系统测试，以使这种冗余成为可能，但仍然可以接受别人的意见。

由于很多原因，这很糟糕，我在一家商店工作，他们试图将其从此更改为更合理的外观，并且很难看。

这是不好的原因：

• 如果代码所有者休假并且他们的东西中弹出一些大错误，那么尝试学习代码并修复错误将非常困难且耗时
• 如果代码所有者离开公司，那么他们的项目将受到严重挫败，因为所有遗产和部落知识才刚刚走出大门
• 文档很差。如果我是唯一用它编写代码的人，为什么要记录它？与此相关的问题是，任何被迫创建的文档也可能很糟糕，因为没有人对代码有足够的了解，无法真正说明文档是否完整甚至准确。
• 当每个人都有自己的小沙箱时，很容易引发代码圣战，就像其他人提到的那样，这很快就会变得非常愚蠢。问题所在是两个人必须一起工作时，两个人都不习惯妥协。
• 由于上述观点，团队合作技能永远不会形成，人们永远不必与他人合作。
• 领地很容易形成，小小的王国是由零花钱装成的，根本不给公司买任何东西。您不知道这些事情是否会发生，直到为时已晚，因为模块或工具X是Bob的责任，这让您感到困扰，他甚至应该询问Bob在其代码中的工作。
• 代码审查和同行审查受苦，因为没人对代码一无所知。如果您不知道代码，那么您将无法发现不正确的地方，并且仅限于注释文本格式和命名约定。
• 如果您为我工作...公司拥有代码，而不是您。我们为自己的工作和成就以及编写的内容感到自豪，但这是一个集体的事情，就像您的团队在一场艰难的比赛中获胜一样。任何为公司工作的员工都平等地拥有该代码，并且在工作过程中可以以他们喜欢的任何方式对其进行编辑，以实现公司的目标。

最大的问题实际上是人员问题和文档。这个人有一天会离开，男孩会把您的日程表向左推几个星期。

更好的方法是让每个人都熟悉代码库的每个部分（如果真的很大且很多种，则要了解六个部分），以便他们可以

• 修复该区域的任何缺陷
• 添加次要或中等的新功能或增强功能

每个人对某些事情的了解往往比其他人要多一些，因此对于两个或三个难题可以结合在一起，或者事实上的专家可以接受。在这种情况下，我曾在小组中工作过，效果非常好。不仅没有上面列出的缺点，而且由于我们不是在寻找专家，因此人员配备也更加可预测。

唯一代码所有权的赞成者是，“代码所有者”可以比其他人更快地做事，但这只有在每个人都是非重叠项目的“代码所有者”时才成立。换句话说，如果人们旋转，“唯一代码所有者”的优势就会消失。

见卡车号又称巴士系数

公共汽车系数（也称为卡车系数，或公共汽车/卡车号）是对单个团队成员中信息集中程度的度量。总线系数是关键的开发人员的总数，这些人员需要丧失能力（例如，受到公共汽车/卡车的撞击），才能使项目陷入混乱而无法继续进行；该项目将保留其余团队成员都不熟悉的信息（例如源代码）。较高的总线系数意味着，在项目必然失败之前，需要将许多开发人员撤职。

“乘公交车撞”可能有多种形式。这可能是一个人从事新工作，生了一个婴儿，改变了他们的生活方式或生活状态，或者实际上是被公交车撞了：效果是一样的...

与许多事情一样，这是一个很大的“依赖”。如果严格要求“没有其他人可以使用该代码”，那么可能就很糟糕了。如果它是“所有者必须在接受更改之前进行代码审查”，那么这将是一件好事，这取决于所有者是否愿意接受外部更改。

缺点是严重的。您团队的“卡车数量”几乎变为1。

回顾一下，“卡车数量”简单定义为“在失去执行某些关键任务所需的知识之前，卡车可能会撞上多少团队成员（最坏的情况）”。

开发人员专注于子学科是很自然的，而且在某种程度上值得鼓励。如果每个人都必须知道与该项目有关的所有事情，那么什么也做不了，因为每个人都将学习其他人所做的事情，它为什么起作用以及如何在不中断它的情况下进行更改。此外，如果开发人员打算在不同区域执行不同的操作，则更改发生冲突的可能性较小。因此，通常有两个或三个主要在项目的特定子系统中工作的开发人员或开发人员对并很好地了解它是很好的。

但是，如果仅一个人应该触摸特定的代码行，那么当那个人退出，被解雇，休假或最终住院时，该行代码将被证明是导致错误的原因必须解决的问题，其他人必须深入了解代码。如果除了编写它的人以外，没有其他人曾经看过它，那将需要一些时间才能达到一定的理解水平，使开发人员可以进行修正该错误的更改而无需付出更多。TDD可以提供帮助，但只能通过告诉开发人员他们做出了“错误”的更改；同样，开发人员必须了解哪些测试正在执行哪些代码，以确保失败的测试不会试图做出错误的断言。

我并没有把它发挥到极致，但是我更喜欢代码责任。您编写损坏的代码，应该修复它。这可以在个人，对或团队级别上完成。它可以防止将您的混乱传递给其他人进行清理。这也适用于更改。

工作量和计划问题将覆盖此问题。推迟修复一个主要的错误是愚蠢的，因为罪魁祸首正在两个星期的假期中。

我们的目标不是让您的团队玩“怪罪游戏”，也不是让错误计数过高（无论如何，它们都不尽相同）。它基于谁最后检查了代码或让主管做出决定并将其分配给某人，而不是遍历代码的每一行。

更好的程序员可能最终会修改很多其他人的代码，无论您如何分配它。