程序员请处理好你的“巴士因子” 我第一次听说巴士因子这个词是在2013年的一次协作专题学术讨论会上。简言之，它指的是为了使1个软件开发维护全部无法进行下去，须要有多少个团队成员被车压死——1个很妙的概念，至少我是这么想的。而我马上就意识到，我的软件的巴士因子是1，也就是我，于是，我想，应该花时间思考一下为什么会成为这样，我应该用某种方式让我的软件传播出去。
那么，巴士因子仅仅是1个让我们去思考如何开发软件的黑色幽默术语吗？两个星期后，我的朋友，还可以是我的同事，就被一辆重型货车撞了。我不打算说出她的名字，我不想因为这篇文章导致有人跳出来在搜索引擎上搜索注意她的信息——尽管如果真的想找出她也不须要太多的侦探科技。我最后一次见到她是在她的博导的葬礼上——还可以是我的朋友和同事——还可以是正当壮年，在新年那一天从楼梯上摔下来。全都是这么突然，巴士因子对这个我来说已经不是1个轻率儿戏的词语。它开始像鬼魂一样纠缠着我。
对和他们的死亡的评论，有的是“45年积攒的宝贵经验就这样没了”，有的说“目前没人知道这些卫星是如何工作的了”。我知道这些并不都是实话。他们俩都在欧洲航天局卫星项目组工作，那里有严格的工作制度。也就是说，会有1个Algorithm Theoretical Baseline Document(算法理论基本文档ATBD)，这是一本很厚的，详细的文档说明，它能准确的告诉你卫星是如何工作的。还有源代码，伪代码，还有1个很大的团队，都能接替他们的工作。如果没有意外，他们留下的工作将会继续下去。
尽管如此，我们仍然应该认真想想如何处理我们的研究工作。一次意外的死亡并不是像我们想象的那样遥不可及。为了避免这种意外事故造成的影响，我想到了以下几点。首先，密码——如果我不在了，我的同事如何能进入我的计算机？然后是准备1个备忘录。有时我找到自己的文件都很困难，如果能更好的整理它们？然后是这最主要的一块，软件本身。
所以，这就是我下一步要做的。我会单独拿出时间来整理这套软件，将散乱的东西整理到一起，发布时要附带所有必要的文档。我会坚持要求我的学生在去做其它新任务前也要这样做。好的习惯目前就要开始，我们要让它成为日常工作的一部分——以防万一。
IT之家附：
在软件开发中，软件项目的巴士因子是指对某些信息集中于某1个人，或少数几个人的1个不那么尊重的度量指标。设“巴士因子”=N，如果有N个人被巴士撞到，无法工作，就会导致项目混乱以致于无法继续。
所谓“被巴士撞到”只是个比方。也能够是某个人换了工作、生了孩子、改变了生活方式或生活状况（中了彩票决定不再工作），其影响都是一样的。
