Windows 机密最后擒获的小鸡

Raymond Chen

当项目即将结束时，团队通常会玩一个非正式游戏，称为“最后擒获的小鸡”。在这个游戏中，团队成员“相互谦让”，避免负责对项目进行最终的更改，因为从原则上来说，如果您这个时候没出错，项目可能就会早些发布（实际情况很少如此，但它的确是此游戏的动机）。竞争完全是虚拟的—没有人实际记分，“赢家”也很快会被遗忘。

除非您是那个赢家。

Windows 团队的一名高级成员向我坦言，在 Windows 的早期阶段，他曾连续两次赢了这个游戏。第二次尤其引人注意，因为更改是在已经开始制造之后才出现的。整个制造过程不得不取消，然后重头再来。

但是，连接三次赢得这个游戏的企图遭到终结。第三次尝试最终排名第二。头筹由我的另一名同事拔得，他不仅赢得了为 Windows 2000 设立的这场比赛，并且之后还通过在 Windows XP 中夺冠启动了一个新的时代。

“最后擒获的小鸡”游戏的一个不寻常之处是：最终中标的往往是那些工作有序的人们（因而常常出乎您的意料）。注意，并非由于他们的代码较差。由于他们准备充分，所以更容易在最后捕捉到漏洞，甚至能从正常不由他们负责的组件中找出错误。

后期审验是一项重要工作，因为原本将开发人员与主体分隔开来的隔离因素已不再存在。正常情况下，审验的过程如下所示：

• 对子项目进行审验。
• 子项目的生成实验室在夜间处理更改，然后于清晨生成一个版本。
• 子项目的测试团队将用一周甚至更长时间钻研代码，然后才同意将此审验发布到主件中。

采用这种方式，如果您犯了任何错误，更可能在它们成为项目的正式组成部分之前就将其找出。有些子项目非常大以至于他们通过递归方式应用此原则，创建子项目的子项目，以便在将其更改发布到所属的更大子项目中之前独立实施验证。

但是，当项目进入最后阶段且发布管理团队决定采用您的修改时，时间正一分一秒地逝去，已没有时间从容不迫地执行数周的更改确认过程。整个项目中都有负责定期构建整个项目（而不仅仅是自己的子项目）的开发人员，他们清除障碍，以在私有发布服务器上创建磁盘映像并确认已满足构建约束条件（例如，他们要做的一件事情就是确保 CD 映像不会大到一张 CD 都装不下！）。

如果团队发现自身处于需要进行最终审验的形势中，它通常会寄希望于准备充分的团队成员—如果不存在这样的人员，该团队会从附近团队中征召准备充分的人员给予协助。

现在玩一个名为 Cyrano 的小游戏。团队向准备充分的开发人员提供更改，开发人员构建磁盘映像，确认构建约束条件，然后将测试团队引向私有发布服务器。如果测试团队恰好发现一个问题，开发团队提出新的修改，将其交给准备充分的开发人员，由他们重新开始此周期。

换句话说，准备充分的开发人员充当该团队的一人式虚拟构建实验室。所有人都满意后，该开发人员进行审验。这就是那些准备充分的人员最终在“最后擒获的小鸡”游戏中获胜的原因。并非因为他们陷入某个问题的圈套之中，而是因为他们准备好帮助那些陷入圈套中的人们。

Raymond Chen 的网站 The Old New Thing 及同名书籍 (Addison-Wesley, 2007) 讨论了 Windows 的历史、Win32 编程以及分解咖啡机。