代码所有权是代码的味道吗？

自从我在有争议的编程观点线程中阅读此答案以来，我一直在思考以下问题：

你的工作是使自己失业。

在为雇主编写软件时，所创建的任何软件都应以任何开发人员都可以选择并以最小的努力理解的方式编写。它经过精心设计，清晰一致地编写，清晰地格式化，记录在何处，按预期每日生成，检入存储库并进行适当版本控制。

如果您遇上公共汽车，下岗，解雇或下班，您的雇主应该能够在短时间内通知您，然后下一个人可能会担任您的职务，接管您的代码，并做好准备。一周之内就可以跑步了。如果他或她做不到，那您就惨败了。

有趣的是，我发现有了这个目标使我对雇主更有价值。我越努力成为可抛弃型产品，我对他们就越有价值。

而且在其他问题（例如这个问题）中也进行了讨论，但是我想再次提出来从更空白的角度讨论“ 这是代码的味道！ ”的观点-尚未真正涵盖深入。

我从事专业开发已经十年了。我曾经做过一项工作，代码编写得足够好，可以被任何体面的新开发人员相对迅速地拿到，但是在行业中的大多数情况下，似乎拥有很高的所有权（个人和团队所有权）规范。大多数代码库似乎都缺乏文档，流程和“开放性”，而这将使新开发人员可以选择它们并快速使用它们。似乎总是有很多不成文的小技巧和黑客，只有非常了解代码库的人（“拥有”它）才知道。

当然，明显的问题是：如果该人退出或“被公交车撞上”怎么办？还是在团队层面上：如果整个团队在团队午餐时外出时食物中毒，而他们全都死了怎么办？您是否可以相对轻松地用一组新的随机开发人员代替团队？-在过去的几份工作中，我完全无法想象这种情况的发生。这些系统充满了诡计和技巧，以至于您“ 只需要知道 ”，以至于您雇用的任何新团队所花费的时间远远超过可盈利的业务周期（例如，新的稳定版本）才能使事情恢复正常。简而言之，如果不得不放弃该产品，我不会感到惊讶。

显然，一次输掉整个团队是很少见的。但是我认为所有这一切中还有一个更微妙和危险的事情-这就是让我开始思考这个话题的要点，因为我以前从未看到过这些术语的讨论。基本上：我认为对代码所有权的高度需求通常是技术债务的指标。如果您“必须知道”系统中缺乏流程，沟通，良好的设计，许多小技巧和小技巧，等等-这通常意味着系统正在逐渐陷入越来越深的技术负担。

但是问题是-代码所有权通常被表示为对项目和公司的“忠诚”，是对工作“承担责任”的积极形式-因此，完全谴责它是不受欢迎的。但是，与此同时，等式的技术债务方面通常意味着代码库变得越来越不开放，并且使用起来更加困难。特别是随着人们的前进和新开发人员的到位，技术债务（即维护）成本开始飙升。

所以从某种意义上说，我实际上认为，如果对代码所有权的高度需求被公开认为是一种工作气味（在流行的程序员想象中），这对我们的职业而言将是一件好事。与其将其视为工作中的“承担责任和自豪感”，不如将其视为“通过技术债务巩固自己并创造人为的工作保障”。

我认为测试（思想实验）基本上应该是：如果这个人（或者实际上是整个团队）明天要从地球上消失，该怎么办？这是否会对项目造成巨大的伤害甚至是致命的伤害，还是我们可以招募新人员，让他们阅读doccos和帮助文件并使用代码几天，然后再返回在几周内完成业务（一个月左右即可恢复全部生产力）？

我认为我们必须在代码所有权之间有所作为：

• 从责任的角度来看，
• 从代码样式/ hacks等角度来看。

必须鼓励第一个。如果没有人对低质量的代码和错误负责，那么不好的事情将会发生。这并不意味着必须每次都将与您自己的代码相关的错误分配给您：如果正确编写了代码，则任何人都可以在代码的任何部分修复该错误。但是，如果您对所执行的错误没有任何反馈，则会一次又一次产生相同的错误。

代码所有权可能对管理人员和开发人员（尤其是开发人员）都有很大帮助。如果我是三位开发人员从事该项目时知道产品中80％的错误是在我的代码中，而这些错误中的75％与SQL注入有关，那么下次我将更加谨慎，并且付出额外的努力来正确编写数据库查询。

第二个问题（来自代码样式/黑客等的代码所有权）主要是一件坏事。它带给产品什么？它不会提高产品的质量，但是会降低源代码的统一性，并导致近期难以维护。

对于许多大型项目，人们不会一生都在使用同一段代码。在这里，我什至不谈论可怕的事情，例如开发人员被公交车撞到了：在这种情况下，我不认为代码所有权是头等大事。但是发生了许多次要的想法：人们从开发迁移到管理或其他工作，或者选择其他项目，或者从事其他工作，或者开始使用另一种语言（如果项目中使用了几种语言），等等。

一个项目的一段代码也可以在另一个项目中重用，并且在另一个项目上工作的开发人员希望修改代码的某些部分以适应新的需求，而无需征求前代码编写者的意见。

它有代码味吗？好吧，这取决于代码气味是什么意思。对我而言，这完全取决于项目的整体一致性和正确的管理。在一个好的项目中

• 强制执行代码样式准则，以帮助以后更轻松地理解代码，
• 经验丰富的开发人员不会违反KISS原则，因此有助于经验较少的同事以后理解源代码。

总之，必须通过版本控制来跟踪代码所有权，但您不能说您或团队中的其他人编写了一段代码。

首先，我们需要定义什么是“代码所有权”。

当一段（部分）代码处于开发的早期阶段时，通常需要指定一个或两个人作为“所有者”，因为：

• 最初，没有明确的规范或要求，开发人员将需要自行收集信息。这些发现的收集与记录之间存在时间差距。
• 在主动修改代码段时，避免编辑冲突。
• “所有者”是可以报告功能开发进度的人员。

通常，每个任务只有一个所有者。配对编程可实现双重所有者。如果没有任何狭义的“代码所有权”，那么这样做是不切实际的。

注意：有关开发过程中的其他问题，
请参阅@MainMa的答案。在那些情况下，“代码所有权”是更大问题的征兆，即：体系结构选择欠佳，编码风格不一致以及通常缺乏代码质量。

一旦将一段代码写入并接受到代码库中（“完成”），就会出现更一般的“代码所有权”问题。

• 谁能回答有关此代码段/此功能部分的所有问题的专家？
• 是否已将这些知识捕获在有形的工件中，例如需求文档，单元测试，验收测试，变更日志，项目Wiki等？

领域知识中总会有一些部分（对客户需求的默契，奥术系统的兼容性问题等）很难被正式化为书面规范。因此，当发生灾难事件时，必须预料到某些领域知识的损失。

随着领域知识的丢失，您还将失去可以解释系统详细信息的专家答复者。在这方面，失去专家是普遍的坏事。该知识应该早已被捕获。

这并不意味着“专家”的存在是不好的：将专家视为书面知识的“缓存”。专家通常可以比查找和消化书面知识更快地回答问题。

但是，有时“代码所有权”是指项目的活跃开发人员为阻止外部人员修改代码而设置的障碍。

• 谁可以更改这段代码？
  • 要修复明显的错误？
  • 为了使代码满足其他一些要求？
  • 要完全按照自己的喜好重写代码？

障碍有好有坏：

• 良好的障碍
  • 领域知识-您对要求和体系结构/编码样式的理解程度
  • 编程和设计技能-您是否具有提高项目设计和代码质量的技能
• 障碍重重
  • 您不是最初的开发人员团队的成员，因此不允许您进行更改。
  • 仅错误修正是受欢迎的。不支持功能增强。

在这种情况下，编辑其他项目源代码的特权不应基于代码所有权，而应基于绩效。

最后，@ Graham Lee的答案指出了由部门化导致的知识和体系结构的分散。

在这种情况下，“代码所有权”是部门化的症状之一。第二个症状是“对其他团队的项目缺乏兴趣”。作为一个组织，管理人员将需要采取措施鼓励团队和部门之间的知识转移和协作。

更阴险的是，一些公司（我曾在一家公司工作过）围绕职能团队来组织其管理结构：您管理Windows客户端开发人员，她管理安装程序团队，他管理后端开发人员，等等。这不仅导致您描述的强大代码所有权，而且将其作为业务运作的方式加以体现。它将软件架构变成一场政治斗争。

这有问题吗？架构是-或变成次优。如果仅作为客户的用例，就不可能说（例如）安装程序会更好地工作或开发成本更低，因为这将控制权从团队及其经理那里移开。功能模块之间的划分已成为有关工程部门运作方式的事实，要改变这些事实需要花费很多精力。

[顺便说一句，如果上面的讨论不清楚，我对你的问题的回答是肯定的。代码所有权是一种代码味道，因为它可以阻止有好主意的聪明人-甚至只是在需要时有空的人-从事代码工作。显然，有控制措施来阻止反复变化是一件好事，但是，如果您有一位工程师可以看到如何修复错误并有时间去解决它，那么您就不应因为其他人编写了错误代码而阻止了该工程师。 ]

从稍微不同的角度解决您的问题，代码所有权不是代码的味道。相反，它是一种管理和资源的气味。

考虑一下代码气味的含义。这是一个隐喻，它告诉您在查看代码时，代码和/或软件的设计并不完全正确，但是问题可能不那么明显，以至于您无法理解。确切的问题可能是，但是无论如何，您可能都有一个好主意。在家里，如果有异味，请顺着鼻子走，直到找到问题的根源，然后再采取措施。同样，如果代码有问题，您可以调查并更改它，直到问题不再那么严重，或者像某些人说的那样精美或精心编写。

另一方面，代码所有权可能是一个严重的问题。这表明缺乏监督，并且有风险，如果代码所有者离职，则该公司将无法再获得有关代码及其解决的特定问题的知识。这与实际代码本身无关。基本上，这归结为风险管理情况，导致我们保留数据备份，并且同样适用于任务所有权或公司其他领域的文档所有权。

我认为可以将其他业务问题描述为气味很好，但绝对不能暗示仅由于存在气味而与代码有关。

我将代码所有权定义为对您编写的代码承担个人责任，但要了解其他人将来会在您的代码中工作。如果您以这种方式考虑问题，您将不太可能编写hack，因为a）该模块中的错误可以追溯到您身上，b）团队成员将来可能很难修改代码。

几个月前，我在博客上写了一篇文章，其中我争辩说，按照我的定义，如果没有代码所有权，那么代码库通常会成为“ 公地悲剧”的牺牲品。

根据您对代码所有权的定义，我同意拥有仅作者可以使用的代码是不好的。