很多进行持续集成实践的软件开发团队，都会在开发人员的工位附近的显著位置，摆放一个大显示器，接上持续集成流水线。一旦流水线运行出现问题，比如编译错误或自动化测试运行失败，就会显示告警的红色画面，提醒开发人员及时修复。
但我在不少开发团队看到的实际情况却是，大部分这样的流水线健康显示屏，就是一个摆设。开发人员根本就不关注。即使显示屏变红好几天了，也无人修复（如图1）。
图1 带有红色告警的持续集成流水线健康状态显示屏
持续集成流水线健康状态显示屏的初衷是好的。因为它仿照了丰田公司造汽车时在流水线上设置安灯系统以提升质量的做法。即流水线上任何一位工人，只要发现汽车出现质量问题，就会拉安灯绳，停下流水线，提醒组长过来和他一起解决问题。这样能极大减少返工成本，提升产品质量。
一般来说，流水线健康显示屏成效差的主要原因，是流水线上根本就没有运行有效的自动化测试，而只是运行基本的编译和打包任务。而如果编译和打包出现问题，一般都由开发组长来修复，所以开发人员就不再关注了。要是开发组长平时开会很忙，就会出现好几天都没空修复的情况。
一些企业的IT部门，会请咨询师帮助开发人员掌握编写有效的自动化测试的技能，并将测试运行在流水线上，且要求开发人员无论是谁，只要看到了流水线健康显示屏出现红色告警，或听到警报器鸣响，就要立即去修复。制定这样的持续集成流水线纪律，能解决上述问题吗？
未必。
开发团队持续集成流水线纪律落地的实际成效，还取决于在同一流水线上工作的开发人员数量。数量越少，效果越好。在同一流水线上工作的开发人员，意味着他们的代码最终都会合并到这条流水线上。
上述预测，是根据社会心理学的责任稀释假说做出的。责任稀释假说，指“目睹紧急情况的人越多， 他们中任何一个人出面干预的可能性都越小”。这个假说由社会心理学家Bibb Latané 和 John Darley 提出，并在他们于1968年所做的实验中获得支持。
启发这个假说和实验的，是1964年发生在美国的深夜女子遇害案。“1964 年的一个深夜，年轻女子Kitty Genovese在返回公寓（如图2）时，在一场持续 45 分钟的袭击中惨遭杀害。《纽约时报》报道称，38 名公寓居民要么从窗户看到袭击，要么听到吉诺维斯的尖叫声，但没有人试图帮助她，甚至都没人报警。尽管我们现在知道《泰晤士报》夸大了无所作为的目击者数量（Cook，2014；Pelonero，2014），但这次谋杀报道生动地捕捉到了公众的恐惧，并在当时迅速传遍全美。“(Aronson, E.; Wilson, T. D.; Sommers, S. R.; 2021)
图2 年轻女子Kitty Genovese于1964年的某个深夜在自己公寓附近遇害的那条小道（图片源自维基百科）
出于对人们见死不救原因的好奇，Bibb Latané和John Darley这两位在纽约大学任教的社会心理学家，决定研究一下遇害女子Genovese的邻居所处的社会情境。他们在1968年，用实验模拟了一个人命关天的紧急情况。实验结果发现，当受试者面临要出人命的紧急情况，并意识到周围有4个旁观者时，只有31%的概率会去施救。若旁观者下降为2人，施救的概率上升到62%。当周围没有旁观者，施救的概率会达到85%（如图3）。
图3 实验结果发现，当受试者面临要出人命的紧急情况，并意识到周围有4个旁观者时，只有31%的概率会去施救。若旁观者下降为2人，施救的概率上升到62%。当周围没有旁观者，施救的概率会达到85%（图片源自Aronson, E.; Wilson, T. D.; Sommers, S. R.; 2021）
责任稀释假说，能解释为何丰田公司的安灯绳的成效，要好于持续集成流水线健康显示屏。因为丰田汽车生产线上发现汽车质量问题的工人，身边没有旁观者，所以工人出手拉安灯绳的概率会很高。而一个由多位开发人员共用的持续集成流水线健康显示屏所展示的质量问题，最先的发现者却是机器。团队虽然制定了持续集成流水线纪律，但当多位开发者同时看到流水线质量告警，就会出现责任的稀释，出手修复问题的概率会降低。
责任稀释假说和实验，给了开发人员有效进行持续集成实践的两点启发。当然，这两点启发的前提，是开发人员编写了有效的自动化测试，并运行在流水线上。
第一，工作在同一条流水线上的开发人员数量，如果控制在2～3人左右，那么开发人员主动解决流水线所发现的软件质量问题的概率，会高于开发人数更多的情况。有人担心2～3人的开发团队是不是人太少了。在2022年之前是这样的。但从今年开始，有了熟悉编程的类似ChatGPT强大的人工智能的帮助，再加上使用领域驱动设计DDD进行服务的拆分，组建2～3人的开发团队，已经不再是梦想。
第二，工作在同一条流水线上的开发人员数量，如果难以将控制在2～3人左右，假设人数有5人，那么可以将给这5人共用的持续集成流水线健康显示屏撤掉，再为每位开发人员单独安装一个仅供自己看的流水线健康显示屏。同时要求每位开发人员，当向流水线合并代码后，需要观察自己那块流水线健康显示屏变为健康的绿色，才算合并成功。若发现红色警报，因为只有她/他一人在场，周围没有旁观者，那么她/他主动修复流水线所发现的问题的概率会达到最大。
以上就是将社会心理学的研究成果，运用到做软件的人的工作中的一个实例。
如果你想验证第二点启发是否有效，可以做一个有对照组的实验。为了简便起见，可以针对同一个开发团队做实验。即在多位开发人员共用流水线健康显示屏的情况下，统计开发人员主动修复流水线所发现的问题的概率。然后将公共显示屏换成个人显示屏，并按上述第二点启示的描述，要求开发人员主动修复流水线问题。此时再统计一下开发人员主动修复流水线所发现的问题的概率。前后对比概率，就能验证你的开发团队的持续集成红色告警实践，是否支持责任稀释假说。
如果你觉得本文对你和其他做软件的人有用，欢迎点赞、评论和转发。你的这些鼓励，会激励我继续写下去。
参考书目
Aronson, E.; Wilson, T. D.; Sommers, S. R.; 2021; Social Psychology 10th Edition Global Edition; Pearson
Cook, K.; 2014; Kitty Genovese: The murder, the bystanders, the crime that changed America. New York: W. W. Norton.
Pelonero, C.; 2014; Kitty Genovese: A true account of a public murder and its private consequences. New York: Skyhorse Publishing.
