methodology - 曳光弹开发

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 4 年前。

Improve this question

我正在使用 The Pragmatic Programmer 中提倡的 Tracer Bullet 方法开发客户端服务器应用程序并想要一些建议。我正在研究每个用例，从客户端启动到服务器，然后再次返回客户端以显示结果。

我可以看到两种继续进行的方法:

1. 涵盖基本用例，只需编写足够的代码来满足我正在处理的用例，然后返回并充实所有错误处理稍后。
2. 尽可能充实每个用例可能的话，在继续之前捕获所有异常并完善界面下一个用例。

我倾向于第一个选项，但我担心忘记处理一些异常，并在应用程序投入生产时让它困扰我。或者留下不清楚的“ stub ”错误消息。然而，如果我选择第二种选择，那么我想我最终会做出更多的改变。

问题:
当使用曳光弹开发时，您会采用这两种方法中的哪一种？为什么？
或者，我还缺少另一种方法吗？

Answer 1

据我了解，Tracer Bullet 方法有两个主要目标

1. 尽快解决根本问题
2. 尽快为客户提供有用的结果

您不“完善”每个用例的动机可能是为了进一步加快速度。问题是这样做是否会危及 1. 以及客户是否真的对“未经修饰”的结果感兴趣。即使没有，beng 能够快速获得客户反馈肯定有一个优势。

我想说你的想法是可以的，只要

• 您要确保“未完善”的部分中没有隐藏任何根本问题 - 这肯定会在错误处理中发生
• 您可以在问题跟踪器中跟踪稍后需要“完善”的任何内容，或者通过将 TODO 保留在源代码中 - 并在用例运行后仔细检查这些内容
• 用例并没有那么“粗糙”，以至于客户无法/不会为您提供有用的反馈