代码审查是一种促进快速协作、知识共享和卓越质量的实践，这些是开源项目的典型特征。代码审查社会结构是项目的决定性特征。 开源项目的最佳社会结构是什么？
在本文中，我们通过分析三种常见模型来研究这个问题：终身仁慈独裁者 (BFDL)、层级结构和社区模型，并使用两种图论指标来量化它们的鲁棒性和信息传输能力。
量化它们的属性
我们可以使用社交网络理论中定义的指标评估图 1-3 中的模型。 在这些模型中，每个节点代表一个人，每条边代表一次代码审查。
图可视化中的节点大小通过信息传输的度量标准 接近中心性 进行缩放。 接近中心性是一种标准化度量，其值范围从零到一，量化到代码审查网络中所有其他人的平均距离的倒数。 当接近中心性较高时，知识可以很好地传播。 高接近性意味着许多同行的经验和知识被传递，因此个人贡献因网络规模而得到加强。
图可视化中的节点的颜色是根据它们对维护网络内通信的临界程度进行映射的。 蓝色节点具有较低的 中间中心性，红色节点具有较高的中间中心性，紫色色调节点介于两者之间。 中间中心性是通过审查者的最短路径数量的标准化度量。 具有高中间中心性的节点反映了该网络的鲁棒性较差——如果这些节点出现故障，网络中的通信将会崩溃。
模型如何运行
图 1 中的 BDFL 模型在信息传输（接近中心性）方面表现非常好，但缺乏鲁棒性。 由于中央 BDFL 节点参与所有审查，因此他们会传授他们的知识并传递来自网络中每个其他参与者的信息。 但是，中央 BDFL 节点也是一个单点故障。 如果 BDFL 更换工作、去度假、发现一种新的编程语言、被公共汽车撞倒、被外星人绑架等，网络将会崩溃。 中心节点的度，即执行的代码审查的数量，也非常高。 这可能会导致 精疲力竭 并使网络难以扩展。
虽然图 2 中的层级结构可以扩展而无需任何单个节点具有高学位，但它在鲁棒性和信息传输属性方面均失败。 网络容易受到层级结构顶端损失的影响。 并且信息传输（可视化为节点大小）在整个网络中都很差。
虽然图 3 中的社区代码审查结构缺乏图 1 或图 2 中的规律性，但它既具有高的信息传输能力，又非常强大。 虽然没有明确的 BDFL 或层级结构的顶部，但领导者仍然会出现在这种结构中。 领导角色由行动决定，例如执行的审查数量，而不是他们在网络中的位置。 但是，在这种自由形式的组织中，还有其他要求。 需要更高数量的通信——边比其他模型更多。 此外，这种情况需要工具和客观标准才能做出有效的决策； 是否合并补丁可能取决于它是否通过所有 单元测试、是否已达到标准测试 代码覆盖率、是否通过自动样式检查等，而不是“丹中尉说了算”。
结论
我们已经看到，在有效传播知识的能力以及人们不断变化的生活状况或不良表现或精疲力竭的脆弱性方面，社区代码审查结构在数学上优于集中式或层级式系统。 当然，这些不是唯一重要的因素——例如，这些模型没有捕捉到个人经验水平的价值。
图 4：真实项目 Insight Toolkit (ITK) 的代码审查网络。 与其他图形一样，节点的大小与其接近中心性相关，节点的颜色按其中间中心性进行编码。 边的宽度与审查数量有关。 单击以查看完整的可视化。
此外，真实项目不会干净地归类为这些理想化模型之一； 大多数是所描述的模型或其他模型的混合体。 基于真实数据的示例是 Insight Toolkit 的代码审查结构，如图 4 所示。 声称在 BDFL 模型下运行的项目无法在没有一些分布式工作负载的情况下进行扩展。 声称在社区结构下运行的项目受到终身运营的影响。
最后，重要的是要记住，代码审查结构是次要的，重要的是执行代码审查的人的质量和数量。 开源社区中代码审查的实践是相互学习和相互服务的机会。
本文中提供的分析和可视化的源代码 可在 GitHub 上获得。 图 4 中的数据和可视化来自 描述 ITK 在可重复研究中作用的文章。
2 条评论