0

TDD のアイデアは素晴らしいですが、設計が事前に提案されていない場合に複雑なシステムを実装する方法について頭を悩ませようとしています。

たとえば、支払い処理アプリケーション用に複数のサービスがあるとします。事前にある程度しっかりとした設計がない場合、開発が複数の開発者間でどのように進行するか、または進行できるかを理解できません。

誰かがこの方法でシステムを組み立てるための例と高レベルの手順を提供できれば素晴らしいことです. TDD がどのようにしてよりシンプルで堅牢なコードにつながるかはわかりますが、1) さまざまな開発者を共通のアーキテクチャ ビジョンに結び付ける方法、および 2) 防止するために動作を抽象化できるシステムをもたらす方法についてはわかりません。コードの大部分をリファクタリングする必要がある (たとえば、長期的な開発ロードマップに基づいて、さまざまな支払い方法や価格モデルを受け入れる)。

リファクタリングは、データ モデルの変更が顧客と会社のリスクを増大させる実稼働システムの大きなオーバーヘッドであると私は考えています。

明らかに、TDD の専門家が発見した何かが欠けている可能性があります....

4

3 に答える 3

2

私見、それはチームの構成とリスクに対する欲求に依存します。

  • チームが数人の経験豊富で優れた設計者で構成されている場合は、形式ばらない「アーキテクチャ」フェーズが必要です。それは、ナプキンの落書きの裏側かもしれませんし、ホワイトボードに数時間書き込んだ後、アイデアを証明するために猛烈なコーディングを行ったのかもしれません。チームが分散している場合、および/またはスキルの低いデザイナーが多数含まれている場合は、全員が独自の道を歩む前に、設計段階でより多くの時間/労力 (思考と文書化) を投入する必要があります。
  • 次に考えられるのはリスクファーストです。プロジェクトに対するリスクを継続的に評価し、エクスポージャー/影響を計算し、緩和計画を立てます。最初に、リスクが高く、元に戻すのが難しい決定に焦点を当てます。決定が簡単に元に戻せる場合は、それに費やす時間を減らします。

熟練した設計者は、小さなステップでアーキテクチャを進化させることができます...彼らがいる場合は、明示的な設計段階で厳密さを和らげることができます

于 2012-06-04T06:49:44.783 に答える
1

TDD には事前の設計が必要になる場合がありますが、事前に大規模な設計を行う必要はありません。コードを書き始める前に設計がどれほど完璧であると考えていても、ほとんどの場合、TDD の力によるリアリティ チェックに合格せず、TDD セッションの途中でバラバラになってしまいます (または、コードが壊れてしまいます)。絶対に元の計画に曲げたい場合）。

TDD の大きな力は、まさに、テストやリファクタリングを記述して設計を改善できることです。したがって、事前に詳細について可能な限り最小限の仮定をして、小さくて単純なものから始める必要があります。

実際にできることは、ペアで (または、作成しようとしているものの全体像についての合意が本当に必要な場合はチーム全体で) いくつかの UML 図をスケッチし、これらの図を出発点として使用することです。あなたのテスト。ただし、最初のいくつかのテストを作成したらすぐにこれらのモデルを削除してください。これらのモデルは、有益ではなく有害であり、もはや真実ではないビジョンに固執するよう誤解を招く可能性があるためです。

于 2012-06-04T13:18:49.323 に答える
0

まず第一に、私は TDD の第一人者であると主張しているわけではありませんが、あなたの質問の情報に基づいたいくつかの考えを以下に示します。

上記の #1 に関する私の考え: あなたが言及したように、アーキテクチャ設計を事前に行う必要があります。これなしで成功できる方法論は考えられません。アーキテクチャは、チームに結束とビジョンを提供します。前もって十分な設計を行いたいと思うかもしれませんが、それはあなたがどの程度アジャイルになりたいかによって異なります。開発者チームは、コーディングを開始する前に、システムのさまざまなコンポーネントをどのように組み合わせるかを知る必要があります。

誰かがこの方法でシステムを組み立てるための例と高レベルの手順を提供できれば素晴らしいでしょう

サービスで構成されるシステムを構築する場合は、サービス インターフェイスとそれらが交換するメッセージを定義することから始めます。これは、システムのさまざまなコンポーネントがどのように相互作用するかを定義します (これは、事前設計の例です)。これがあれば、さまざまな開発リソースを割り当てて、サービスを並行して構築できます。

＃2については。TDD の利点の 1 つは、リファクタリング中に「セーフティ ネット」が提供されることです。コードは単体テストでカバーされているため、コードを変更する場合、特に継続的インテグレーションを実行している場合 (ほとんどの人が TDD アプローチで行っている場合)、何かが壊れているかどうかがすぐにわかります。この場合、新しい動作に対応するように単体テストを適応させるか、単体テストがパスするようにコードを修正する必要があります。

コードの大部分をリファクタリングする必要がないように、動作を抽象化できるシステムになります。

これは、たとえば戦略パターンを使用して、動作を抽象化および置換できるようにするための設計次第です。TDD は、設計が苦しむ必要があることを規定していません。機能要件を満たすために必要なことだけを行うように求めているだけです。システムが新しい支払い方法または価格設定モデルに適応できる必要があるという要件がある場合、それが設計のポイントになります。TDD を正しく実行すると、要件を満たしていること、および設計が正しい方向に進んでいることを確認できます。

リファクタリングは、データ モデルの変更が顧客と会社のリスクを増大させる実稼働システムの大きなオーバーヘッドであると私は考えています。

ソフトウェア設計の問題の 1 つは、それが厄介な問題であることです。つまり、リファクタリングはほぼ避けられません。はい、リファクタリングは本番システムではリスクがありますが、そのリスクを軽減でき、TDD が役に立ちます。また、しなやかな設計とカップリングの少ないシステムも必要です。コードをテスト可能に設計しているため、TDD は結合を減らすのに役立ちます。また、テスト可能なコードを作成することの副産物の 1 つは、システムの他の部分への依存を減らすことです。実装をモックまたはスタブに置き換えることができるインターフェイスにコーディングする傾向があります。これの良い例は、データベースへの呼び出しを、既知のデータを返すモック/スタブに置き換えることです。単体テストでデータベースにアクセスしたくありません。ここで、TDD アプローチでは優れたモッキング フレームワークが非常に貴重であることを言及できると思います ( Rhino モックとMoqどちらもオープンソースです)。

真の TDD の専門家がいて、あなたに知恵の真珠を与えてくれるはずです...個人的には、TDD アプローチなしで新しいプロジェクトを開始することは考えません。

于 2012-06-04T02:36:03.833 に答える