methodology - 曳光弾の開発

Question

The PragmaticProgrammerで提唱されているTracerBulletアプローチを使用して、クライアントサーバーアプリに取り組んでいます。アドバイスが必要です。クライアントでの開始からサーバー、そして再びクライアントに戻って結果を表示するまで、各ユースケースを処理しています。

続行するには2つの方法があります。

1. 基本的なユースケースをカバーし、私が取り組んでいるユースケースを満たすのに十分なコードを記述し、後で戻ってすべてのエラー処理を具体化します。
2. 次のユースケースに進む前に、すべての例外をキャッチしてインターフェイスを磨きながら、各ユースケースを可能な限り具体化します。

私は最初のオプションに傾倒していますが、いくつかの例外を処理するのを忘れて、アプリが本番環境にあるときにそれが私に噛み付くのを恐れています。または、不明瞭な「スタブ」エラーメッセージを残すこと。ただし、2番目のオプションを選択すると、後でさらに変更を加えることになります。

質問：
曳光弾の開発を使用する場合、これら2つのアプローチのどちらを採用しますか。その理由は何ですか。
または、私が見逃している別のアプローチはありますか？

Answer 1

私が理解しているように、Tracer Bullet メソッドには 2 つの主な目標があります。

1. 根本的な問題にできるだけ早く対処する
2. できるだけ早くクライアントに有用な結果を与える

各ユース ケースを「洗練」しない理由は、おそらく 2. をさらに高速化するためです。問題は、そうすることで 1. を危険にさらすかどうか、そしてクライアントが実際に「洗練されていない」結果に関心があるかどうかです。そうでない場合でも、クライアントからのフィードバックを迅速に得ることができるという利点があることは確かです。

限り、あなたのアイデアはOKだと思います

• 「洗練されていない」部分に隠れている基本的な問題がないことを確認します。これはエラー処理で確実に発生する可能性があります。
• 後で課題トラッカーを使用するか、ソース コードに TODO を残すことで、「洗練」しなければならないことをすべて追跡します。
• ユースケースは、クライアントが有用なフィードバックを提供できない/提供しないほど「洗練されていない」わけではありません。

Answer 2

アプローチ 1 を採用すると、機能の 90% がかなり迅速に機能するようになります。しかし、あなたのクライアントは、あなたが 90% 完了したと考え、仕事を終えるのになぜ 9 倍の時間がかかるのか不思議に思うでしょう。

アプローチ＃1を採用する場合、私はそれをプロトタイプにすぎないと呼び、そのように扱います. それ以上のものとして表現することは、後で問題につながるだけです。幸せな日のシナリオは、仕事の 10% にすぎません。残りの 90% は、他のシナリオを機能させ、ハッピー デイ シナリオを確実に機能させています。開発者ではない人にそれを信じさせるのは非常に困難です。私は通常、＃1と＃2の間で何かをします。私は、ユースケースとすべてのシナリオを特定するのにかなり良い仕事をしようとしています. 次に、アーキテクチャに最も影響を与えるシナリオを特定し、それらに取り組みます。