TDD または反復モードでアプリケーションを構築するための最も好ましい設計パターンを持つようなものはありますか?
5 に答える
7
質問を書き直すことができると思うので、これらの言葉でより理にかなっています。
「テスト駆動型およびインクリメンタル開発戦略を使用する際に、柔軟性を実現するために役立つアーキテクチャ パターンと戦略はどれですか?」
私の答えは次のようになります: クラスとコンポーネントを切り離すのに役立つパターン:
制御の反転と依存関係の挿入- クラスとコンポーネント間の依存関係を、実行時 (または起動時) まで解決される特定の実装から切り離しておくのに役立ち、まだ実装されていない機能と単体テストの両方にスタブを使用できます。
Facades - コンポーネント間の相互作用のために明確に定義されたインターフェイスを提供するコンポーネントを分離し、結合を減らすのに役立ちます。
ファクトリおよびその他の作成パターン- オブジェクトのインスタンス化を担当するコードのセクションで柔軟性を提供します。
また、漸進的および反復的な開発のマントラの 1 つは、「機能する可能性のある最も単純なことを行う」であることも忘れないでください。オーバーエンジニアリングしないでください。
あなたが尋ねたことによると、それは理にかなっていますか？
于 2008-09-23T09:07:24.303 に答える
4
異なるものを混ぜないでください。該当する場合はパターンを使用し、時間と労力を節約し、コードをより標準的に見せます。それはあなたの開発方法論とは何の関係もありません！
ただし、アプリケーションアーキテクチャでいくつかのことを強調したい場合があります。
- 物事を非常にモジュール化してください。緩い結合を受け入れます。
- モジュール間の明確な概念上の境界を定義します。概念的には、最初は明確で、自然に感じる必要があることを意味します。それについて尋ねられたランダムなプログラマーは、「うわー、あなたがそれをどのようにしたかは明らかです！」と答えるべきです。
- 小さく始めます。ZOMG-this-will-be-the-best-and-most-universal-class-library-and-program-and-whateverを作成しようとしないでください。物事を機能させてから拡張しますが、必要な場合に限ります。
- YAGNIを納得させてください（あなたはそれを必要としないわけではありません）。やらなければならないことがわからないことはしないでください。それは先延ばしか何かを意味するものではありません。「わからない、将来役立つかもしれない」「技術的には派手」「万が一に備えて含める」などの理由でやらないという意味です。
- 乾かす-繰り返さないでください。コードの重複の問題に遭遇しないように注意してください。コードジェネレーター、優れた抽象化、およびチーム全体の生産的なコミュニケーションについて考えてください。
于 2008-09-23T09:00:46.220 に答える
2
それが意味のある質問かどうかはわかりません。しかし、私はそれが私を止めることはできません...
選択したアジャイル プロセスの下でアプリケーションが進化するにつれて、特定のパターンがアプリケーションの設計の側面に適切であることが明らかになる可能性は十分にありますが、 Ron Jeffriesの言葉を引用すると (誤解ではないことを願っています) 、「コードが教えてくれます」。
編集：しかし、決定的な答えが必要な場合は、ブリッジしてください。それは良いことです。または訪問者、私もそれが好きです。または、「F」で始まるもののほとんど。:)
于 2008-09-23T08:39:14.073 に答える
-1
デザイン パターンは、特定のタイプの問題を解決するのに役立つツールです。パターンの使用は、開発方法論ではなく、要件の範囲によって定義された問題によって管理されます。
于 2008-09-23T08:39:42.637 に答える
-3
Python や Ruby などの動的言語を使用して開発する: そもそも「デザイン パターン」の理由である、他の言語が持つ多くの問題と戦う必要はありません。
動的言語と自動テストを組み合わせることで、非常に迅速に結果が得られるため、どの方向に進むべきかがわかります。パフォーマンス上の理由から、またはすでに構築した動的ソフトウェアを翻訳できるものは何でも、静的言語を使用する必要があることに気付いた場合。
于 2008-09-23T08:37:11.863 に答える