软件代码著作权 多少行代码_代码拥有权–谁应该拥有代码？

软件代码著作权 多少行代码

建立和管理任何开发团队的一个关键决定是就如何划分代码所有权达成一致：谁将负责编写什么代码； 团队可以并且应该分担多少工作； 以及谁将负责代码质量。 您采用的方法将对团队的绩效和成功产生直接影响，并对代码的形式和质量产生长期影响。

Martin Fowler描述了团队中代码所有权的三种不同模型 ：

1. 强大的代码所有权 -每个模块都是某人专有的，开发人员只能更改其拥有的代码，如果他们需要更改他人的代码，则需要与该所有者交谈并首先获得所有者的同意-除非在紧急情况下。
2. 弱代码所有权–仍将模块分配给所有者，但允许开发人员更改其他人拥有的代码。 所有者应注意他人所做的任何更改，开发人员应在更改其他人的代码之前先征得他们的许可，这可以被视为共享的托管模型，其中个人被迫共享与他人共同拥有自己的代码； 或代码管理 ，团队拥有所有代码，但一个人要负责特定代码的质量，并负责帮助其他人进行更改，审查和批准所有主要更改，或与其他开发人员结对必要。 布拉德·阿普尔顿 （ Brad Appleton）表示，代码管理员的工作不是对代码片段进行所有更改，而是“从概念上和结构上保护该代码的完整性+一致性，并广泛地散布有关它的知识和专业知识，以其他”。
3. 集体代码所有权 –代码库由整个团队拥有或共享，每个人都可以自由地进行他们需要或想要进行的任何更改，包括重构或重写其他人最初编写的代码。 这是极端编程中产生的模型，整个团队在其中负责代码的质量和完整性以及理解和保留设计。

反对强大/个人代码所有权的争论

Fowler和其他XP倡导者（例如Kent Beck）不喜欢强大的个人代码所有权，因为这在团队内部造成了人为的障碍和依赖性。 如果您需要等待某人进行更改甚至批准更改，则工作将停滞不前，而且所有人通常可以成为整个团队的关键途径。 这可能会鼓励开发人员提出自己的解决方法和妥协方案。 例如，与其适当地更改API（这将涉及对其他人的代码的更改），他们可能不愿意更改，例如将某些内容填充到现有字段中。 或者他们可能会复制某人的代码并添加所需的内容，从而使将来的维护工作变得更加困难。

其他反对强所有权的论点是，这可能导致某些开发人员的防御和保护主义（“嘿，别碰我的代码！”），他们将对代码的任何批评视为人身攻击，在团队和不鼓励审稿人提供反馈并不鼓励重构工作； 以及本地过度优化，如果开发人员有太多时间花在完善和完善他们的宝贵代码上，而又没有考虑更大的前景。

当然，要考虑一个 “ 被卡车撞到的因素 ” –如果离开团队的人是唯一从事一段代码工作的人，它将对生产力产生影响。

病房坎宁安。 XPers的原始作者之一也认为， 共享代码时拥有所有权的骄傲 ，因为每个人的工作总是向团队中的其他每个人展示。

反对集体代码所有权的争论

但是，也有人反对集体代码所有权。 Mike Spille的帖子列出了团队尝试“过度共享”代码时遇到的一些问题：

• 不一致。 没有可识别的最重要的体系结构，只有针对单个问题的单个解决方案。 大量重复努力的结果，通常导致行为不一致
• 虫子。 人们无法真正理解的“重构”代码破坏了原始代码中的细微差别。
• 不断进行“ The Blame Game”游戏。 人们对错误的React非常敏感，他说：“当我编写它时，它就起作用了，但是自从Joe重构它以来……好吧，这就是他的问题。”
• 交货缓慢。 没有人在任何特定领域都拥有任何专业知识，因此人们花费更多的时间来尝试理解他人的代码，而花更少的时间编写新代码。

Matthias Friedrich在“ 关于集体代码所有权的思考”中认为，只有在具备适当条件的情况下，集体代码所有权才能起作用：

• 团队成员的技能水平相似
• 程序员认真工作并互相信任
• 代码库处于良好状态
• 已有单元测试来检测有问题的更改（尽管到目前为止只有单元测试可用）

请记住，集体代码所有权来自极限编程。 成功的团队所有权取决于每个人都对领域和设计有了解，并保持高水平的技术纪律：不仅编写非常好的自动化测试作为安全网，而且每个人在整个代码库中遵循一致的代码约定和标准和成对工作，因为希望你们中的一个知道代码，或者至少有两个头脑，您可以尝试帮助彼此理解它并减少错误。

集体代码所有权的另一个问题是所有权分布得很薄。 贾斯汀·休利特（Justin Hewlett）谈到了公地悲剧问题：人们会照顾自己的院子，但是有多少人会在公园或街道上捡走别人的垃圾，即使他们走在那个公园或那条街上每天？ 如果代码属于每个人，那么总会有“其他人”来照顾它-不管那个“其他人”可能是谁。 作为开发人员，您承受着很大的压力，您可能永远也不会再碰到这段代码，所以为什么不尽快获得所需做的任何事情，然后继续进行下一步工作，然后让“其他人担心重构或编写额外的单元测试，还是……？

现实世界中的代码所有权

除了10年前在一个团队中进行纯XP和集体代码所有权的实验外，我一直与遵循个人（强或弱）代码所有权的团队合作或与他们合作。 一个（或两个）人拥有不同的代码段，并对该代码进行全部或大部分繁重的工作。 因为只有最了解代码的人员才能完成大部分工作或最重要的工作，才有意义。 这不仅仅是因为您希望工作“做得正确”，有时您对谁去做工作没有真正的选择。

正如Ralf Sudelbucher指出的那样 ，集体代码所有权假定所有编码工作在一个团队中都是可以互换的，但这并不总是正确的。

由于技术的原因，某些工作不可互换：系统的不同部分可以用不同的语言和不同的体系结构编写。 您必须先学习语言和框架，然后才能开始理解需要解决的其他问题。

或可能是因为存在问题空间。 当然，在任何“ 只是键入 ”的项目上总会有编码：众所周知的熟练手工作，例如脚手架工作，编写另一个Web表单或另一个CRUD屏幕，修复报告或转换文件格式，这些工作必须可以在团队中工作了一段时间，并且知道在哪里找到东西以及如何完成事情的人，或者与认识这一点的人结对的人，都可以做到。

但是其他软件开发涉及解决硬域问题和技术问题，这些问题和技术问题需要花费大量时间才能正确理解-在其中可能需要数天，数周，数月甚至数年的时间才能将自己完全沉浸在问题空间中，从而知道该怎么做，在这里，任何人都不能只是跳入并开始编码，甚至在结对编程情况下也无济于事。

当您将魔术师的学徒放到他们不了解的代码上时，最严重的灾难就会发生。 在一个典型的项目中，并不是每个人都知道所有信息，除了在过去的一两年中几乎没有业务范式转移的某些成熟领域之外。

吉姆·科普林
代码所有权

我遇到了一个为大型计算机动画工作室管理软件开发的人。 他的团队有几个专业的开发人员，他们做过PHD并在毕业设计上制作了动画头发，这就是他们所做的一切，即使您真的很聪明，也需要多年的学习和经验才能了解他们的工作方式。做。

许多科学技术工程领域也是如此-也许没有那么深入地专业化，但是它们涉及到非凡的工作，通才，甚至胜任的通才不能轻易或胜任地完成。 对医疗设备或航空电子设备，机器人或武器控制进行编程； 或您在解决问题方面处于领先地位的任何业务领域，都将高级统计模型应用于大数据分析或金融交易算法或风险管理模型； 或超级计算，大规模计算和并行编程 ，或者编写操作系统内核或解决密码问题，或者在用户体验（UX）设计方面做得很好。 并非每个人都了解需要解决的问题，不是每个人都在乎问题，也不是每个人都能很好地解决这些问题。

所有权和正确行事

如果您希望正确完成工作，或者需要第一次正确完成工作，则应该由以前从事过代码工作，知道它并证明自己可以完成工作的人员来完成。 并非只对代码有肤浅了解的人。 微软和其他公司的研究工作表明，随着越来越多的人触摸同一段代码，出现误解和错误的可能性就会越来越大，而在一段代码上完成最多工作的人则是最少的人。错误。

Fowler在后来的有关“ 转变为代码所有权 ”的帖子中谈到了这一点，他分享了一个同事的故事，该同事将团队从集体代码所有权转移到薄弱的个人代码所有权，因为较弱或经验不足的程序员在核心部分犯了错误。代码，影响质量，速度和团队士气。 他们更改了所有权模型，因此任何人都可以在代码库中工作，但是如果他们需要更改核心代码，则必须在非常了解代码部分的人的帮助下进行。

在确定所有权方法时，您必须在灵活性和质量，团队所有权和个人所有权之间进行权衡。 使用个人所有权，您可能会遇到严重的问题和对关键人员的依赖，并且您必须提防卡车。 但是，您可以以更少的人员完成更多的工作，更快，更好。

参考： 代码所有权–谁应该拥有代码？ 来自我们的JCG合作伙伴 Jim Bird在Building Real Software博客中获得。

翻译自: https://www.javacodegeeks.com/2013/05/code-ownership-who-should-own-the-code.html

软件代码著作权 多少行代码