我正在使用 The Pragmatic Programmer 中提倡的 Tracer Bullet 方法开发客户端服务器应用程序并想要一些建议。我正在研究每个用例，从客户端启动到服务器，然后再次返回客户端以显示结果。
我可以看到两种继续进行的方法:
- 涵盖基本用例，只需 编写足够的代码来满足 我正在处理的用例，然后返回 并充实所有错误处理 稍后。
- 尽可能充实每个用例 可能的话，在继续之前捕获所有异常并完善界面 下一个用例。
我倾向于第一个选项，但我担心忘记处理一些异常，并在应用程序投入生产时让它困扰我。或者留下不清楚的“ stub ”错误消息。然而，如果我选择第二种选择，那么我想我最终会做出更多的改变。
问题:
当使用曳光弹开发时，您会采用这两种方法中的哪一种？为什么？
或者，我还缺少另一种方法吗？
最佳答案
据我了解，Tracer Bullet 方法有两个主要目标
- 尽快解决根本问题
- 尽快为客户提供有用的结果
您不“完善”每个用例的动机可能是为了进一步加快速度。问题是这样做是否会危及 1. 以及客户是否真的对“未经修饰”的结果感兴趣。即使没有，beng 能够快速获得客户反馈肯定有一个优势。
我想说你的想法是可以的，只要
- 您要确保“未完善”的部分中没有隐藏任何根本问题 - 这肯定会在错误处理中发生
- 您可以在问题跟踪器中跟踪稍后需要“完善”的任何内容，或者通过将 TODO 保留在源代码中 - 并在用例运行后仔细检查这些内容
- 用例并没有那么“粗糙”，以至于客户无法/不会为您提供有用的反馈
关于methodology - 曳光弹开发，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/743815/