如果你的团队超过两个人怎么办？
仅仅因为两个人知道系统的一部分并不意味着它不应该被记录下来。
我很高兴知道，我不必记住系统中的每一个细节，因为这些信息除了存在于我的脑海中之外，没有任何其他地方存储。
对于小型系统，这种方法可能有效，但随着系统变得越来越大，你会限制自己和同事们的能力。我宁愿将我的记忆容量用于新系统，而不是记住旧系统的所有细节。
你有没有玩过“传话游戏”？我认为你不应该在你的代码库中玩这个游戏。
无论您是否使用成对编程，都应独立决定可交付成果的集合。
六个月或两年后，所有参与者可能会进入不同的项目（或不同的公司）。您想能够回来并使用设计文档吗？那就制作它。如果您不想回来，或者设计足够简单，以至于通过规格和代码您可以在没有明确的设计文档的帮助下理解它，则可以跳过它。
但是不要依赖两个人在一年后向您解释设计。
维护。你不能期望团队始终保持不变，没有新成员加入或老成员离开。设计文档确保那些在项目中新加入、需要在未来几年内维护项目的人能够获取有关已做出的决策、为什么选择该方法以及如何实施的信息。对于项目的长期成功来说，拥有这样的文档非常重要，可以通过传统文件、源代码注释、单元测试和其他各种方法来提供。
“设计文档”是什么意思，这取决于你的理解。
如果你有功能测试——特别是行为驱动开发（BDD）测试、Fitnesse或FIT测试，那么它们肯定是一种“活跃文档”……它们不仅具有回归测试的价值，而且还有其他价值。
如果你编写用户故事并将其分解为任务，并将这些任务写在卡片上供成对完成，那么你正在进行一种文档编写方式……
这些是我在XP团队中使用的两种主要文档形式，这些团队会对所有生产代码进行配对。
我发现另外一种非常方便的文档是一个半页左右的项目要点列表，向人们展示如何为开发机器设置构建环境。你应该在使用过程中不断维护这个列表。
谁知道第一行代码是什么？答案是没有人知道，因为它还没有被写出来。之所以还没有被写出来，是因为没有人知道该怎么做，因此需要一个设计文档。
人们的经验可能与代码同步，就像你所说的那样。但设计决策并没有全部被编码捕捉到——只有所做出的选择。
根据我的经验，要真正理解代码为什么是这样设计的，你需要了解哪些设计选择没有被选中，已尝试但失败的方法等。你可以希望“中国耳语”传递正确，但由于没有记录以刷新记忆或纠正错误......
......或者，你可以撰写有关设计及其达成方式的文档。这样，你就可以避免未来维护程序员将你带入歧途。
