共享代码所有权何时有用？

Question

我最近参与了几个项目，这些项目促进了共享代码所有权的想法。有时，这似乎加速了代码改进和增强。其他时候，它似乎成了自我更名的基础，正在做出改变，以支持个人编码风格，青睐的技术，或仅仅是权力/智力的演示。

如何实施共享代码所有权以避免陷阱并仍然获益？太多的厨师会破坏肉汤吗？

Answer 1

共享所有权有很多好处。以下是理想化的观点，但是你可以走很远的路，特别是当一个团队随着时间的推移编织在一起时：

• 许多大脑比一个好。编码器经常会发现错误或对每个其他代码中的奇怪问题，从而提高整体代码的健壮性。将其视为持续的同行代码审查。
• 如果开发人员遇到公共汽车或辞职，可以降低丢失关键/有价值知识的风险。
• 如果开发人员休假一周，则无需等待一周就可以修复错误。或者你不必向愤怒的程序员解释为什么在他的背部被转动时你为什么混淆了“他的”代码。
• 在整个团队中传播产品知识。调用库的人如果真正处理库中的代码并且理解它就会减少错误。一个叫黑盒子的人，他一无所知，需要更长的时间，犯更多的错误。
• 在整个团队中传播编码知识。每个人都从别人那里学习技巧和模式（即使是顶级程序员有时也可以从初中学到一些他们不知道的东西）。
• 消除编码风格 - 人们有自负，倾向于喜欢开始宗教战争，但如果他们在相同的代码库上工作，经理强制执行编码标准并介入以控制风格“战斗”，过了一会儿团队开始作为一个连贯的团队工作，代码质量提高，战斗停止发生。
• 帮助每个人感觉他们是团队的一员，没有松动的大炮。没有灵长类动物，每个人都认为他们是平等的，他们的投入是有价值的，值得的 - 这可以转化为更好的自尊。此外，当团队实现目标时，每个人都对此感到满意，当团队失败时，没有人会感受到个人责任的全部重要性。
• 程序员沟通更多，这会让你有更好的团队精神和更大的帮助他人的意愿。
• 它提高了代码质量，因为程序员知道其他人会阅读他们的代码，所以他们倾向于将它们全部放在一个更整洁的状态以避免尴尬。他们也知道他们必须让他人的代码易于理解，所以他们开始为其他人编写代码来维护，而不是为自己编写代码。

可能的缺点包括：

• 关于编码风格或实施方法的微小意见分歧的战斗和宗教战争
• “太多的厨师破坏了肉汤” - 有时保持设计清洁和专注的最佳方法是只让一个人策划它。这并不一定意味着他们完成所有工作，只要所有团队成员都了解愿景并遵循建筑师的设计。代码评论在这里非常强大。
• 并非所有程序员都是平等的。当您的团队能够提供良好的清洁代码时，可能会令人沮丧，但也许有一个人无法达到团队其他成员提供的质量。这可以滋生不满并分裂一个团队，因为他们可以感觉到他们的精彩创作被破坏了。
• 那些根本不想成为团队成员或觉得自己比其他人更好的程序员可能会非常具有破坏性。

我会说在所有这些情况下，当你让这些人分享所有权时，事情通常会变得更好。有时不够快，但如果让一个孤独的人留下孤独的人，他将永远不会学习如何成为一名团队成员。如果你让弱势群体离开团队，他们将如何学习和加强他们的技能？如果某人沟通能力差，孤立他的帮助会怎样？最终，你需要一个团结一致的团队，他们都对代码库有着广泛的了解，并且让成员分开并专注于小型专业领域永远不会实现这一目标。

Answer 2

在不利方面： -

• 共享所有权下的代码与最弱的团队成员/审核者一样好
• 弱团队成员可能会引入一个糟糕的公共结构，这种结构变得不可逆转，因为一些不可变的外部系统在检测到之前就变得依赖于它。在现实世界中，我已经看过很多次了。
• 除了巴士事件之外，一个像神一样的神谕将几乎总能解决任务关键的时间依赖的褐色 - 东西 - 点击 - 旋转的东西 - 在很多千斤顶的时间内发出问题全交易。

共享代码所有权仅在团队中的每个人都具备高技能，并且不会通过知识差距进行错误调用时才有效。换句话说，团队中的每个人都需要成为所有代码的专家，并充分了解他们的更改对系统的影响，这些系统可能从手边任务的狭隘视图中看不到。

Answer 3

编码标准肯定会有所帮助，特别是在持续集成和/或源代码管理签到策略的支持下。

首先，定义标准并让团队就这些标准达成一致（管理层打破关系）。

其次，使用自动化工具（最好使用IDE挂钩）来处理代码格式化。

第三，使用自动静态分析工具检查合规性。这些不仅可以验证格式，还可以检查代码复杂性指标，命名约定，最佳实践等。可以根据您团队的规则自定义更好的格式。如果可能，请查找允许通过元数据（例如属性）抑制不适当警告的内容。大多数规则都有例外，你想隐藏误报的“噪音”。

第四，将静态分析与源/修订控制系统集成，以便在签入时运行。某些系统允许拒绝不通过策略的签入。另一个选项（不相互排斥）是设置一个在签入时自动构建的持续集成服务器;它可以运行静态分析并通知所有开发人员任何故障。

Answer 4

• 通过配对，测试和清理代码进行通信：当您没有足够的时间来编写技术文档或系统发生如此大的变化时，您无法跟上需要编写技术文件。

• 敏捷团队没有一个“建筑师形象”，它决定了一切如何融合在一起。 敏捷团队成员对事物的态度更加民主，设计更具协作性。这意味着更多的沟通，以及仅通过书面文件难以维持的通信类型和数量。 （并不是说你不需要文件 - 但必须面对面和共同影响方向配对。）

• 共享所有权对于需要共享公共核心代码库的分布式团队非常有用。在我工作的分布式团队中，我们将远程协作者发送到我们的总部，以便在公共代码上与我们配对，这样他们就可以获得足够的知识和信心，可以在远程站点上工作，同时代码的原始作者正在睡觉一个不同的时区。结果：不需要等待远程专家。

• 您正在构建需要多种不同类型专业知识的东西，并且没有一个团队成员是所有这些领域的专家。

• 项目整合了两个或多个复杂的子系统，每个子系统中的专家在团队成员中分布不均。

• 由分包商实施，但其他一些团队将采用该系统进行维护。双方需要配对并影响其可持续发展的方向。

Answer 5

我认为修正案是：

• 编码标准，消除 美学斗争，还有许多其他好处。
• 共同承诺， 如果有人正在进行更改 没有改进设计或实施 一些必需的功能然后 团队应该打电话给他们。 毕竟，如果你是在浪费时间 摆姿势而不是继续 朝着你正在影响的目标迈进 团队表现。同伴压力可以 然后采取行动。

您还应该评估自己。人们自然倾向于认为一个人不同意的行为是不合理的。很多时候，只是缺乏激励对方的经验，有时候必须通过他们自己的自我投资。

Answer 6

我发现共享代码所有权与问题跟踪和编码指南结合使用时效果很好。即人们处理问题（在开发会议期间分配），这可能涉及任何身体代码和指南中提到的许多“风格”问题。这似乎是非常有效的，似乎没有你提到的人们没有充分理由改变代码的问题。

Answer 7

我对共享代码所有权有好的和坏的经验。

感觉很好：

 
• 代码由多个人使用，例如utilites和interfaces。
 
• 程序员具有相当的资格和知识水平。
 
• 所有所有者都需要共享代码中的内容。

在以下情况下感觉很糟糕：

 
• 代码不稳定（原型设计或重构时）。业主应该先稳定它。
 
• 强制执行政策。团队会模拟它并讨厌执法者。
 
• 代码编写得很糟糕。它需要修复，而不是共享。

一般来说，共享所有权并不是一个好主意。最好在感觉自然时分享，并在没有代码时为自己保留代码。

Answer 8

你应该读这个。代码所有权并不像您想象的那么好。

https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450#.ldlpppzh2