使用示踪剂子弹有哪些好的标准？

我最近是第一次阅读The Pragmatic Programmer，并且遇到了Tracer Bullets的概念。我意识到我过去曾经根据这种模型进行编码，只是有点像我在大脑中“敏捷”地工作一样。

他们仅给出一个示例，说明他们过去曾在哪里使用过它。情况被确定为“示踪者子弹”的良好候选人的方式是

有许多未知数，并且有许多不同的环境，而且没人能确定GUI的行为方式。

这似乎是大量项目启动的方式，尤其是当您与非技术人员合作开发对冲基金的典型业务应用程序时（例如）。

我之所以使用它，是因为它只是感觉很对，而不真正知道它的名字或对我解释了什么。我知道，如果我试图让每个人都在一个房间里并让他们预先指定所有东西（或至少某些东西），那将是一场彻底的灾难，但这又是一种感觉...

任何人都可以提出一些更具体的标准来确定何时采用此模型？

您需要有一个项目，在这里您可以仅凭一小部分功能就能了解自己是否步入正轨。通常，这对于诸如基本的GUI设计之类的事情是可行的，但是对于结果未知的事情则很难（例如，如果您正在设计数据挖掘应用程序，并且工具的形状将取决于数据中出现的哪种模式）。

您还需要处于可以承受多次迭代的情况。这会花费时间和开发成本（当然，如果您订阅敏捷开发流程，这当然会有所帮助），但是就用户的接触而言，成本更加困难。如果您向用户展示太多设计，他们将很快精疲力尽，并且反馈的质量将大大下降。因此，您要么需要庞大的用户群，要么要仔细选择您的（微型）发行版。

我要说的是，实际上只有一个基本因素可以确定Tracer Bullet方法的实用性：应用程序的体系结构和设计中不确定性的数量和范围。

由于该技术的主要（即使不是唯一）目标是消除此类不确定性，因此，如果您没有任何不确定性或与架构或设计无关，则不会从中受益匪浅。一个没有体系结构约束的未开发项目是一个典型的例子，当从Tracer Bullet开始几乎是唯一明智的选择，而对于一个具有一些新功能要实现的成熟项目，这可能会浪费时间（尽管需求可能存在不确定性，将这些需求清除的范围更多地是一般敏捷或迭代开发的领域。

我在《Ship It！》一书中遇到了Tracer Bullet开发的概念。，由务实的程序员编辑。

我想您所提到的问题是指《实用程序员：从行家到大师》一书。我还没有看过那个，也不知道那里的TBD是如何呈现的。在发货！，其中一章（共20页）专门针对TBD。他们特别以一个具体的例子谈论他们的经验：一家生物技术公司的数据挖掘应用程序。基本上，他们解释说，拥有漂亮的抽象层（使用TBD设计）可以帮助他们通过并行化每一层来消除性能瓶颈。

我认为，TBD有两点：

• 通过隔离系统对象来创建软件体系结构，并让开发人员协作以定义这些系统对象之间的接口
• 使用模拟对象以确保体系结构是可持续的（尽早测试体系结构）

我认为，无论如何，第一点是构建软件的一种很好的方法。第二点很有趣：由于初始架构在实践中不起作用，因此有可能阻止项目的完全重写。