代码所有权是一种代码气味吗？
自从我读到这是有争议的编程观点中的答案。之后，我就一直在思考这个问题：
你的工作就是让自己失业。当你为你的雇主编写软件时，你所创建的任何软件都应该以这样一种方式编写，即它可以被任何开发人员获得，并且可以用最少的努力来理解。它设计得很好，写得清晰一致，格式化很干净，记录了它需要的地方，按预期每天构建，签入存储库，并进行适当的版本化。如果你得到了被公共汽车撞到、下岗、被解雇或离职，你的雇主应该能够在一分钟内取代你，下一个人可以代替你的角色，拿起你的代码，并在一周内启动并运行。如果他或她做不到，那你就惨败了。有趣的是，我发现拥有这个目标使我对我的雇主更有价值。我越是努力成为一次性的人，我对他们就越有价值。
在其他问题(比如这一个 )中也有过一些讨论，但我想再提一次，从更直接的角度讨论“这是一种代码味！”观点--这一点还没有被深入讨论过。
我已经做了十年的专业开发者了。我有一份工作，代码编写得很好，可以被任何优秀的新开发人员相对较快地获得，但在大多数情况下，在工业中，很高水平的所有权(个人和团队所有权)似乎是正常的。大多数代码库似乎缺乏文档、流程和“开放性”，这使得新开发人员能够快速地获取和处理它们。似乎总是有很多不成文的小技巧和黑客，只有非常熟悉代码库(“拥有”它)的人才会知道。
当然，这很明显的问题是:如果那个人退出或者“被公共汽车撞了”怎么办？或者团队层面上:如果整个团队在团队午餐外出时都会食物中毒，而他们都会死呢？你能用一组相对不痛苦的新随机开发人员取代团队吗？-在我过去的几项工作中，我根本无法想象会发生这样的事情。这些系统充满了技巧和技巧，以至于你“只需要知道”，你雇佣的任何新团队都需要比盈利的商业周期(例如，新的稳定版本)更长的时间才能让事情重新开始。总之，如果该产品不得不放弃，我就不会感到惊讶了。
很明显，一次输掉一支球队是非常罕见的。但我认为，这一切还有一个更微妙、更险恶的问题--这一点让我开始思考这条主线，因为我以前从未见过在这些术语中讨论过。基本上:我认为对代码所有权的高度需求通常是技术债务的一个指标。如果在系统中缺乏流程、沟通、良好的设计、大量的小技巧和技巧，你“只需要知道”等等--这通常意味着系统正逐渐陷入越来越深的技术债务之中。
但问题是，代码所有权通常被描述为对项目和公司的“忠诚”，是对你的工作“承担责任”的一种积极形式，所以直接谴责它是不受欢迎的。但同时，等式的技术债务方面通常意味着代码库的开放程度越来越低，使用起来也越来越困难。尤其是随着人们继续前进，新开发人员不得不取代他们的位置，技术债务(即维护)成本开始飙升。
因此，在某种意义上，我实际上认为，如果对代码所有权的高度需求被公开看作是一种工作气味(在流行的程序员想象中)，这对我们的职业来说是一件好事。它不应被视为“在工作中承担责任和骄傲”，而应更多地被视为“通过技术债务来巩固自己和创造人为的工作保障”。
我认为这个测试(思想实验)基本上应该是:如果这个人(或者说是整个团队)明天从地球表面消失了，该怎么办？这是一个巨大的--可能是致命的--对这个项目的伤害，还是我们能够引进新的人，让他们阅读文档，帮助他们玩几天的代码，然后在几周内重新开始工作(然后在一个月左右的时间内恢复充分的生产力)？
回答 5
Software Engineering用户
发布于 2011-06-19 00:12:36
我认为我们必须在代码所有权之间做出区别：
- 从责任的角度来看，
- 从代码样式/黑客等角度来看。
必须鼓励第一个办法。如果没有人对低质量的代码和错误负责，那么坏的事情就会发生。这并不意味着每次都必须将与您自己代码相关的bug分配给您:如果代码编写正确，任何人都可以在代码的任何部分修复该错误。但是，如果您没有任何关于您所做的错误的反馈，您将一次又一次地产生相同的错误。
代码所有权可能对管理人员和开发人员，特别是开发人员都有很大帮助。如果我知道产品中80%的bug在我的代码中，而我们是项目的三个开发人员，而其中75%的bug与SQL注入有关，那么下次我会更加小心地编写代码，并为正确地编写数据库查询做出额外的努力。
第二种(代码样式/黑客等的代码所有权)基本上是件坏事。它给产品带来了什么？它没有提高产品的质量，但降低了源代码的一致性，并使最近难以维护。
对于许多大型项目，人们不会在同一段代码上工作一辈子。在这里，我甚至没有谈论像开发人员被公共汽车撞到的可怕的事情:我不认为在这种情况下，代码所有权是首要问题。但很多次要的想法发生了:人们从开发迁移到管理或其他工作，或者选择其他项目，或者从事其他工作，或者开始使用另一种语言(如果一个项目中使用了多种语言)等等。
项目的一段代码也可以在另一个项目中重用，开发人员希望修改代码的某些部分以适应新的需求，而无需征求代码前作者的意见。
这是暗号味吗？这取决于你所说的代码气味是什么意思。对我来说，关键在于项目的整体一致性和正确的管理。在一个好的项目中，
- 代码样式指南被强制执行，以帮助以后更容易地理解代码，
- 更有经验的开发人员不会违反less原则，从而帮助经验较少的同事理解源代码。
总之，代码所有权必须通过版本控制来跟踪，但您不能说代码是由您或团队中的其他人编写的。
Software Engineering用户
发布于 2011-06-19 00:23:21
首先，我们需要定义什么是“代码所有权”。
当一段(部分)代码处于早期开发过程中时，通常需要指定一两个人为“所有者”，因为：
- 最初没有明确的规范或要求，开发人员(S)需要自己收集信息。在收集和记录这些调查结果之间存在时间差距。
- 避免在代码段被主动修改时进行冲突的编辑。
- “所有者(S)”是指能够报告该作品发展进展的人。
通常，每个任务只有一个所有者。双用户可以通过双编程实现。在没有任何狭义的“代码所有权”的情况下这样做是不切实际的。
注意：
关于开发过程中的其他问题，请参见@MainMa的回答。在这些情况下，“代码所有权”是一个更大问题的症状，即:架构的次优选择，编码风格的不一致，以及普遍缺乏代码质量。
一旦一篇文章被写进代码库并被接受(“完成”)，就会出现更普遍的“代码所有权”问题。
- 谁是能够回答有关这段代码/这部分功能的所有问题的专家？
- 这些知识是否在有形的构件中被捕获，如需求文档、单元测试、验收测试、更改日志、项目wiki等？
领域知识的某些部分(对客户需求的默示理解、与神秘系统的兼容性问题等)很难形式化为书面规范。因此，当发生灾难事件时，一定程度上会出现领域知识的损失。
随着领域知识的丢失，您还将失去专家回答者谁可以解释系统的细节。在这方面，失去专家是一件普遍的坏事。这些知识早该被捕捉到的。
这并不意味着“专家”的存在是不好的:认为专家是书面知识的“宝库”。专家回答问题的速度往往快于查阅和消化书面知识。
然而，有时“代码所有权”指的是项目的活跃开发人员为阻止外部人员修改代码而设置的障碍。
- 谁能对这段代码进行更改？
- 去修复明显的虫子？
- 才能使代码满足其他一些要求？
- 完全按照自己的口味重写代码？
有好的障碍，也有坏的障碍：
- 良好的屏障
- 领域知识-您对需求和体系结构/编码风格的理解如何？
- 编程和设计技能-您是否具备提高项目设计和代码质量的技能？
- 坏壁垒
- 您不在最初的开发团队中，因此不允许您进行更改。
- 只有补丁是受欢迎的。功能增强不受欢迎。
在这种情况下，编辑其他项目的源代码的特权不应该基于代码所有权，而是应该基于优点。
最后，格雷厄姆·李(Graham)的回答指出，知识和架构的碎片化是由部门化造成的。
在这种情况下，“代码所有权”是部门化的症状之一。第二个症状是“对其他团队的项目缺乏兴趣”。作为一个组织，管理人员需要采取步骤，鼓励团队和部门之间的知识转让和协作。
Software Engineering用户
发布于 2011-06-19 00:09:27
更隐秘的是，一些公司(我曾在一家公司工作)围绕功能团队组织他们的管理结构:您管理Windows客户端开发人员，她管理安装程序团队，他管理后端开发人员等等。这不仅导致了您所描述的强大的代码所有权，而且还将其视为业务的工作方式。它把软件架构变成了一场政治斗争。
这有问题吗？它是如果架构是-或变得-次优。如果安装程序只是客户端的一个用例，就不可能说安装程序工作得更好，或者开发成本更低，因为这将夺走团队及其经理的控制权。各功能模块之间的划分已经成为工程部门运作方式的事实，要改变这些事实需要大量的巨变。
顺便说一句，如果上面的讨论没有明确说明，我对你的问题的回答是肯定的。代码所有权是一种代码嗅觉，因为它可以阻止有好想法的聪明人--甚至是那些在需要的时候可以使用的人--在代码上工作。显然，拥有控制来阻止变化无常的变化是件好事，但是如果你有一个工程师，他能看到如何修复一个bug，并且有时间去做，你就不应该仅仅因为别人写了错误代码就阻止那个工程师.
https://softwareengineering.stackexchange.com/questions/85235
复制相似问题
腾讯云开发者
