Tracer Bullet开发

Question

我正在使用The Pragmatic Programmer中倡导的Tracer Bullet方法开发客户端服务器应用程序,并希望得到一些建议.我正在处理从客户端启动到服务器的每个用例,然后再次返回客户端以显示结果.

我可以看到两种方法:

1. 涵盖基本用例,只需编写足够的代码来满足我正在使用的用例,然后返回并充实所有错误处理.
2. 在进入下一个用例之前,尽可能充实每个用例,捕获所有异常并抛光界面.

我倾向于第一个选项,但我害怕忘记处理一些异常,并在应用程序投入生产时让它咬我.或者留下不明确的"存根"错误消息.但是,如果我采取第二种选择,那么我认为我最终会在以后进行更多更改.

问题:
当使用示踪剂子弹开发时,你采取了这两种方法中的哪一种？为什么？
或者,还有另一种方法,我错过了吗？

Answer 1

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

1. 尽快解决基本问题
2. 尽快给客户一个有用的结果

你没有"抛光"每个用例的动机可能是进一步加速.问题是,这样做是否会危及1.以及客户是否真正对"未抛光"的结果感兴趣.即使不是这样,在能够快速从客户端获得反馈方面肯定有一个优势.

我会说你的想法没问题

• 你确保隐藏在"未抛光"的部分中没有任何基本问题 - 这肯定会在错误处理时发生
• 您可以跟踪在问题跟踪器中稍后"抛光"或将TODO留在源代码中的任何内容 - 并在用例工作后仔细检查这些内容
• 用例不是那么"未经修饰",客户不能/不会给你有用的反馈

Answer 2

如果采用方法#1,您将有90%的功能非常快速地运行.但是,您的客户也会认为您完成了90%,并且想知道为什么它会花费您9倍的时间来完成这项工作.

如果你采取方法#1然后我会称之为原型,并以这种方式对待它.要把它表示为更多,除了以后会产生问题.快乐的一天场景只占工作的10%.剩下的90%是让其他场景发挥作用,欢乐日场景可靠地运作.非开发人员很难相信这一点.我通常在#1和#2之间做点什么.我试图在识别用例和所有场景方面做得相当不错.然后,我尝试确定最具体系结构影响的方案并对其进行处理.