维基百科说Bug Driven Development（BDD）是一种反模式。 Raja Shankar Kolluru完美地解释了为什么。然而，Florian Rappl认为不是。 Ben Winding相信这比TDD更好。简而言之，BDD有点像在飞行中尝试建造飞机，基于乘客的抱怨。 没有人会这样建造飞机（也许波音和空客除外）。然而，实践BDD的软件团队可能表现出更高的生产力。
如果一个软件团队遵循一个简单的原则，那就是每一项工作都被构想为一个投诉，那么它就是在做BDD。
这是2002年，由Mozilla发起的。
如果你听取Mozilla的建议，你的问题跟踪系统中不会有功能请求、问题或任务，只会有bug报告。它们可能听起来像是“机翼着火了！”——一个完美的投诉——或者“飞机没有按摩浴缸！”——一个以投诉形式提出的完美功能请求。问题也可能看起来像投诉：“不清楚如何系上安全带。”无论是来自测试者还是客户，格式都是相同的：“我不喜欢它。”
BDD对项目能够带来的主要好处是降噪。我可以想到两个原因。
- 同样，程序员必须说服投诉人问题已解决。他们不能只用文本回答来关闭工单。他们需要展示对代码库的相当显著的贡献。不能有噪音。
一个好的投诉会指出某个有形物品中的缺陷。一个好的投诉的好解决方法是对那个有形物品的一个补丁。很明显，在软件项目中，源代码是有形的。
在一个纪律严明的团队中，每个工单都是一个报告缺陷的 bug 报告，指出源代码中的缺陷。每个 bug 报告都会导致一个补丁——对源代码的一个贡献。没有噪音。团队专注并展示最佳的生产力。
BDD 也有一个主要的缺点。可能很难训练团队使用它。采用 BDD 可能需要改变他们的心态。他们必须从制造噪音者转变为发现缺陷者。
Jeff Atwood 在他关于投诉驱动开发的博客文章中，从商业角度解释了这一点。他建议，与其实施你认为正确的东西，不如给你的客户一个草稿，让他们去投诉。你关于他们实际会投诉什么往往是错误的。他们投诉得越多，你倾听得越好，你提供的价值就越大。
Translated by ChatGPT gpt-3.5-turbo/42 on 2025-05-25 at 13:27
