嗨，伙计，别碰我的代码！

如果你曾经在任意一家大公司工作过，你或许会遇到这种情况，不希望别人触碰自己的代码，尤其是当别人修改了你的代码，这一行为让人很恼火！

今天有幸遇到了来自微软研究院，苏黎世大学和加利福尼亚大学的David，就代码的所有权问题进行了深度的访谈。David的结论是基于Win7和Vista开发的一个调查，调查结果显示出问题的地方主要在于代码被二流开发者动过。

别碰我的代码！软件质量对所属人的影响

引用：

在微软，我们发现当越来越多的人操作同一个二进制文件的时候，出错的可能性会更高。

经过我们的观察和项目经理的讨论，我们发现当没有一个明确的内容指标，代码贡献者将代码传播给更多的开发者，这将加大了沟通障碍，目标失调，不一致的接口和语义，所有的这些情况都会导致软件质量下降。

沟通：

作者提到共享所有权会造成大量沟通及协调成本：开发组件能够创建一个隐形的团队从而让语义和设计组件等知识共享。协调在软件开发中是众所周知的问题，实际上，另外三个问题在Curtis研究院被提出“缺乏沟通协调能力”，在工作中需要创建一个共享和积累知识贯穿于所有的团队成员中。很多案例表明由于缺少沟通导致任务延期。如果这个团队成员很少关注团队或者组件，他们或许无法获取对无错误组件需要更改的知识。

结果：

根据Windows系统上两个版本针对所有权问题的数据分析得出以下结果：

1. 即使通过制定尺寸、更改和复杂度等规则进行控制，大量的次要代码贡献者对预发布和正式版本的失败仍有不可推卸的责任。
2. 拥有较高水平的顶级代码贡献者通过控制组件来控制相同的指标从而降低失败率，但当项目中的次要贡献者(二流开发者)数量增多时，这种正面效果会显著减低。
3. 代码所有权预览版发布失败要比发行版失败的连带关系更强。
4. 在Windows 7系统中所有权措施和代码标准措施显示跟发行版失败的连带关系较弱。

建议：

最后，在实践过程中针对拥有较强的所有权问题或者与我们的调查结果相一致的情况下，根据我们的调查结果制定了以下建议，所有的这些研究结果表明均可执行：

对于二流开发者作出的更改应该具有更严格的审查规范。二流开发者比优秀的开发者更应该被严格审查，这是因为优秀开发者在实际开发中能够清晰的解释出代码的来源。如果情况允许，代码主要贡献者应该执行代码审查工作。如果他们无法执行所有检查，那么他应该专注于其主要贡献的那部分代码是否被更改过。

潜在的二流开发者（比二流开发者更高一层但比顶级开发者低）应该将有变动的地方与开发人员进行沟通交流。二流开发者在二进制文件中主要参与的工作是修改二进制依赖文件，二流开发者们应该联系主要贡献者并且将自己的所需告之他们，而不是按照需求直接修改，这样以便让具有更高水平的专业人士负责或提出建设性的解决方案。

低所有权的组件应该优先获得/分配QA资源。Metrics度量标准比如Minor和Ownership这样的度量标准应该和源代码管理标准结合在一起使用来鉴定、检查二进制文件，因为这些二进制文件很有可能在发布后还存有很多的问题，当面对质量控制努力有限的情况下需要优先处理二进制文件。