求解！卡车有关问题：一个项目组集体外出，不幸被卡车撞上。有多少人受伤使项目不得不停止

求解！卡车问题：一个项目组集体外出，不幸被卡车撞上。有多少人受伤使项目不得不停止？
最坏的情况是一个，表示很不理解，这是与结对编程相关的一个问题，哪位大神知道，还望指点!
------解决方案--------------------
最坏的情况是一个，表示系统的每个模块或业务只有一个人了解，那么一旦这个人缺席，比如请假，比如有急事去处理，那么所有和他相关的工作都停止了，如果发生在其他人的工作需要在他的工作之上进行的时候那么造成的影响更大，结对编程可以解决某一块代码只有一个人掌握的问题，其实如果不采用结对编程，平时多做些代码复查工作的话也能在很大程度上解决这类问题。
------解决方案--------------------
这是一个伪命题。

如果接口定义清晰，那么我们可以立刻重建有bug的程序部分——而不用修复它。

结对是什么？结对是在每一天都会发生很多次的事情。例如一个人上午进行过2次，下午进行过3次结对编程。有些人以为结对编程就是两个人长期（比如说两个月）结对，这是曲解。

结对编程是个及时发现那些“菜鸟为什么会窝工”并且立刻鞭挞他们的方法，并不会解决什么人员受伤问题。如果知道一点皮毛就算是“解决”了问题，那么其实任何交流似乎都能“解决”问题。但是这就回到了说空话的老路上了去了。

总这这个问题其实是个伪命题。只要项目开发过程中注重解决协同问题（非常喜欢交互解决bug而不是把代码归一个人所有），那么伤几个人也都能让项目得到修改和发布。
------解决方案--------------------
实际中，至少在国内的软件公司中，太菜的程序员多得是。结对仍然会得到菜菜的垃圾代码。特别是，你会发现，有些程序员拼凑的程序连他们自己都不会改——因为他根本不习惯于从网上抄来代码之后搞懂代码。

关键点地是项目经理的设计和督促。由于设计是通用的，因此一个人写了A，往往就看懂B，因为使用相同的接口完成低级的一点工作。而如果没有写过A，可能就看不懂B，因为大多数程序员的水平都是喜欢“捡便宜、捞干饭、现学现卖”而不喜欢真正进行研发。于是当B出现问题而没人修复时，项目经理或者产品经理首先要想到谁写过A，然后让写过A的程序员来重新做一个B（而不是修复它）。

这样的程序员结对，效率并不高。而经常培训和改变他们，才是提高其开发效率的根本途径。