トレーサの弾丸の開発

Question

私はThe Pragmatic Programmerで提唱されているトレーサの弾丸のアプローチを使用してクライアントサーバーのアプリケーションで作業して、いくつかのアドバイスをしたいと思います。私は、クライアントの開始からサーバーまでの各ユースケースを通して、結果を表示するためにクライアントに再び戻っています。

私は続行するには2つの方法で見ることができます

：

1. がちょうど バック を行くと、すべての肉付けそして、私が働いている ユースケースを満たすのに十分なコードを書いて、基本的なユースケースをカバーエラー処理 。
2. 次のユースケースに進む前に、すべての例外をキャッチしてインターフェイスを研磨して、可能な限り の各ユースケースを作成します。

私は最初の選択肢に傾いていますが、私はいくつかの例外を処理することを忘れて、アプリケーションが生産中のときにそれを噛んでいるのを恐れています。または、不明瞭な「スタブ」エラーメッセージを残す。しかし、私が2番目の選択肢を取った場合、後でさらに変更を加えることになります。

質問：
これらの2つのアプローチのうちのどれを取るのですか？
また、別のアプローチがありますか？

Answer 1

私の理解では、トレーサー弾丸方法はできるだけ早く

としてクライアントに有益な結果を与えるできるだけ早く

などの2つの主要な目標

1. アドレス根本的な問題を抱えているあなたそれぞれのユースケースを「研磨」しない動機づけはおそらく2倍になるでしょう。問題は、そうすることで、あなたが1を危険にさらすかどうか、そして顧客が実際には「未練りの」結果に興味を持っているかどうかです。そうでなくても、クライアントからのフィードバックを素早く得ることができるベングには利点があります。

   私は、あなたが「玄米」の部分に隠れて任意の根本的な問題がないことを確認してください

   • 限り、あなたの考えはOKだと思います - これは間違いなくエラーが
   • を処理して起こることができます後でissueトラッカーで "磨く"ことが必要なものを追跡するか、またはTODOをソースコードに残しておくことで、ユースケースが機能している間に慎重に実行する必要があります。
   • ユースケースは、あなたに役立つフィードバックはありません

Answer 2

アプローチ1を実行すると、機能の90％がかなり早く動作します。しかし、あなたのクライアントはあなたが90％完了したと思って、なぜ仕事を終えるのにあなたが9倍かかるのだろうと思うでしょう。

アプローチ1をとった場合、私はプロトタイプ以上のものを呼び出し、そのように扱います。それ以上のものとしてそれを表現することは、後で問題を引き起こすだけです。幸せな日のシナリオは仕事のほんの10％です。残りの90％は他のシナリオを稼働させ、幸せな日のシナリオは確実に機能するようになっています。非開発者にそれを信じさせるのは非常に難しいです。私は通常＃1 &＃2の間で何かをします。私は、ユースケースとすべてのシナリオを識別するのにかなり良い仕事をしようとしています。次に、最も構造的に影響を与えるシナリオを特定し、そのシナリオを処理します。

Answer 3

私はあなたが正+負のテストケース

1. 正のテストケース（これらは、ユーザーストーリー/機能文書/機能仕様で言及されます）
の組み合わせを使用することができるトレーサー弾のためのお勧めします
2. 負のテストケース（BAUシナリオに期待できる共通ネガティブなシナリオ） （レアビジネスシナリオを慎重に検討した後に残ることができます。）

これらのテストケースは、テストを自動化するためにspecflowを使用して実行されました。

テストケースでの一般的な否定的なシナリオの組み込みは、基礎となるコードを使用して連続的な開発を行うことができるという十分な確信を提供します。

ここに経験を共有http://softwarecookie.wordpress.com/2013/12/26/tracer-bullet/