虽然这个标题听起来可能很极端,但迈克尔麦克莱在 1994 年公开提出了类似的句子:
如果Guido被公共汽车撞了? (Guido van Rossum 是 Python 语言的创造者)
这个问题导致了公共汽车因素的产生,也称为公共汽车问题、卡车因素、卡车因素,甚至彩票因素。
虽然网络上有几个略有不同的定义,但我们可以将它们总结为:
公共汽车因素是需要丧失行为能力的总人数,例如被公共汽车撞到,这样项目就会被搁置一旁。
为了使这一点更具描述性, Bus Factor 分数是对对您的项目至关重要的人的估计,如果没有他们,项目将会停滞不前。如果这些人因任何原因从项目中消失(例如“意外”甚至休假、被解雇或离开项目),那么没有人能够维护该项目。
最低可能的 Bus Factor 分数仅为 1,这意味着如果一个人离开项目,它将停滞或死亡。从更技术的角度来看,这可以被认为是项目中的单点故障。更大的总线因子分数是可取的,但并不总是容易实现。
2021 年底,PHP 社区收到了令人遗憾的消息,即在实施了无数错误修复、功能和维护 PHP 10 年后,主要贡献者之一: Nikita Popov决定专注于使用完全不同的语言和社区(Rust & LLVM),其中他已经分开了几年。
与 Python 语言的历史相似,该决定表明 PHP 语言存在一个非常大的问题,即 Bus Factor 分数如此之低。它将支持约 78% 网络的语言的未来置于危险境地。
为了改善目前的状态,从事 PHP 工作的人和公司联手发起了一项新计划: PHP 基金会。
PHP 基金会是一个非营利组织,其使命是确保 PHP 语言的长寿和繁荣。
基金会做出的第一个决定是雇佣/赞助新的开发人员来开发 PHP 核心组件。这样他们就可以开始将 Bus Factor 分数提高到更安全的水平。这是社区需要采取的许多步骤之一,以使 PHP 的未来安全稳定。
我工作过的很多公司,从初创公司到公司,都经常受到总线因素的严重打击。他们的许多团队(大多数时候不是故意的)陷入了NIH (Not Invented Here) ,这导致了维护方面的问题,并且新人的入门级别更高,因为越来越多的东西是由可以离开项目的人创造的任何时候。这通常会导致高额技术债务(我将在稍后的帖子中尝试解释)。
较低的 Bus Factor 分数通常是快速增长时间的一部分,因为只有少数开发人员创建了大部分功能,而这些功能后来成为日益复杂的项目的基础。大多数公司在这样的增长过程中开始了大规模的招聘计划,但这并不能单独增加总线因素。
每个新成员都应该与她/他正在加入的项目中的一位高级人员进行至少 30 分钟的结对编程会议。在此类会议期间,经验不足的人应该完成大部分编码工作,而资深导师则以身作则并提出可能有助于实现任务目标的部分。
当您确定Bus Factor 人员时,您应该关注他们如何分享他们在您的项目中这些年来积累的知识。他们的知识是您团队最大的价值之一。让他们更多地专注于编写文档、创建备忘单、进行内部演示以及在与队友的一对一会议中分享知识。他们应该减少对编程的关注。
虽然团队采用代码审查文化是为了提高代码质量和审查过程,但不太明显的结果是项目中人员之间的直接知识共享。审查绝不能像给予批准印章一样。他们应该指出为什么以这种方式做某事,而不是另一种方式,从而导致前辈和其他队友之间从前辈的角度就可以采取不同的做法进行建设性的讨论。评论必须引起讨论。
快速增长的公司的问题通常是快速增长的技术债务,这会导致 Bus Factor 得分较低。一种有效的技术是通过将项目拆分为更小、更专用的项目来降低项目的复杂性。这导致较低的入门级、更快的采用和更容易的维护。所有这些点都可以非常有效地增加整体总线系数。在降低项目复杂性期间必须避免的最大问题是始终让团队(即使是小团队)参与重构,以避免在新的子项目中产生相同的问题。
这可能是提高 Bus Factor 分数的最有效方法,但也是最困难和最危险的方法。您需要深入计划每一种可能性,以防止失去团队士气。 “洗牌”不应该是强制的,而是定期向团队成员提出,比如:每两个季度一次;队友不能太频繁地更换团队,因为他们需要像新人一样入职。如果计划和执行得当,您的团队将在不同领域获得更广泛的经验,分享与其他团队合作时学到的知识。
为您的开发人员规划培训预算也可以提高 Bus Factor 分数,因为人们将获得更广泛的经验,并扩大您的团队以在公司层次结构中的每个资历级别中拥有更多的人。
提高团队的 Bus Factor 分数并不容易、便宜或快速。在某些情况下,您不希望(甚至不能)轻易提高该分数,例如当项目包含敏感数据并且您不能信任新员工开始处理它时。但是现在您知道了一些可以帮助您防止由于“公共汽车事故”而导致您的运营陷入停顿的基础知识。