3

概要:

TDの設計と開発にどのようなモデルと図を含めたり、提供したりしましたか。また、その理由は何ですか。

詳細:

新しい4開発者プロジェクト。TDDの採用/期待において、経営陣が「バイイン」から「アクション」に段階的に移行することを徐々に進めているショップで。私は(開発者)新しいプロジェクトのテスト駆動設計を望んでいます。いくつかのモデルと図が作成された後、管理者はテスト駆動開発を喜んで許可します(これらは、重要な開発が始まる前に詳細な設計を顧客に伝えるためにUIモックアップを補完します)。

それで、その文脈を考えると、どのモデルと図が合理的であると思いますか?このプロジェクトの成果物は、些細なことでも過度に複雑でもないWebアプリです。要件ドキュメントがあります(あいまいな場合もありますが、テストを作成するための良いスタートです)。

しかし、これまでのTDDの経験(TDDを使用してソロで行った非常に欠陥の少ないプロジェクトの1つと、あちこちで設計を成熟させるピアテストのオーサリング)により、テスト駆動設計の次に進みたいと思っています。

モデル/図を作成するプロセス(いくつかのクラスモデルといくつかの高レベルのユースケースとシーケンス図を提供するように見えます)は、TDDが提供しない設計上の洞察を私たち(開発者)に提供しないようです。技術的/複雑であるため、開発者以外の人が提示されたときにそれらを効果的に無視する(読んでください:盲目的に受け入れる)のではないかと心配しています。

TDの設計と開発におけるモデルと図の包含と除外の境界線はどこにありますか?

4

4 に答える 4

3

「計画は何もない、計画はすべてだ」という軍の発言があります。ダイアグラムが、システム設計がどのように想定されているか、どの領域を網羅することを意図しているか、およびそれがどのように進行するかについて、顧客との有用なコミュニケーションを作成する場合、計画の実践は価値があります。

TDDが示唆しているのは、ゴムがコーディングの道に出会ったときに、その設計が変更される可能性があるということです。問題は、それらの変更が発生したときにそれらの変更を伝えることがどれほど重要になるかということです。ただし、複雑なアーキテクチャでは、TDDのコンテキストであっても、固定計画ではなく計画であることがわかっている限り、事前の計画が重要です。元の設計につながる考え方は、TDDが何を発見したか、それに対応するために物事をどのように変更する必要があるかを理解するために参照できるものです。

その後、振り返って、最終製品が事前の計画とどの程度異なっていたかを経営陣に指摘し、何が変わったかを確認できます。おそらく、早い段階で設計を確定しても、思ったほど貢献しなかったことを指摘できます。 。

于 2009-08-13T16:10:46.897 に答える
1

個人的には、私の設計ドキュメントがTDDと別の開発モードで変わるとは思いません。私は高レベルのユースケースから始めて、非常に具体的な機能的なユースケースドキュメント(クラス図、アクティビティ図などの他のすべての付随ドキュメントと一緒に)ができるまでゆっくりと作業を進めていきます。

これらのホワイトボックスのユースケースができたら、次の2つのことを知っておく必要があります。

  1. コードが何をすべきか。
  2. コードは何をすべきではありません。

次に、アプリケーションをコーディングして、本来あるべきことを実行します...そして、テストをコーディングして、すべきでないことを実行しないことを確認します。

于 2009-08-13T15:08:21.130 に答える
0

TDDは、固定モデルと図に依存するべきではありません。そうしないと、リファクタリングのプロセスが制限または中断されます。

したがって、モデルが本当に必要な場合は、シーケンス図などの高レベルの図を使用して、アプリのナビゲーションを説明します(クラス図よりも変更される可能性は低くなります)。

もう1つのポイントは、高レベルのアーティファクトは、システムの機能を検証するためのテストルーチンを作成する際に顧客を支援できることです。

于 2009-08-13T15:15:35.113 に答える
0

誰も気にしないと思われるドキュメントを生成する必要があるため、開発チームに本当に役立つものを検討する必要があります。

  • ドメイン駆動設計モードで、基本的なモデルオブジェクトを示すいくつかのドキュメントを作成します。不明確な概念を解決し、用語を合意するためにできることを実行してください。これらの問題は両方とも、TDDであるかどうかに関係なく、開発サイクルで「無駄」を引き起こします。

  • プロジェクトの最大のリスクはどこにあるかについて話し合います。これらのリスクを軽減するのに役立つ図と、その前後の説明はありますか?

  • (これを作成しました)テスト用の「フィクスチャデータ」の基本セットを設計します。すべての重要な関係とケースをキャプチャする最小限のデータセットは何ですか?これは非伝統的なアーティファクトであるため、おそらくまだこれを持っていません。しかし、開発にはしばらく時間がかかります。一度入手すると、テストの作成がスピードアップし、実際には有用なコミュニケーションドキュメントであるという副作用が生じる可能性があります。テストの作成を容易にするために、前回のプロジェクトでフィクスチャデータのミニポスターを作成しました。

于 2009-09-02T06:49:13.063 に答える