コーディングするとき、あなたの経験上、より良いアプローチは何ですか?
- 問題を十分に小さな断片に分割してから、各断片を実装します。
- 問題を分解しますが、トップダウンのアプローチを使用して実装します。
- 他の？
3963 次
13 に答える
15
私はトップダウンで設計し、ボトムアップで実装する傾向があります。
実装に関しては、最小の機能部品を構築し、それらをより高いレベルの構造に組み立てることが、私にとって最もうまくいくようです. しかし、デザインに関しては、全体像から始めて、それを分解してそれらの部分を決定する必要があります。
于 2008-09-25T02:40:43.590 に答える
12
これが私がすることです：
まずドメインを理解してください。解決すべき問題を理解する。解決すべき問題について、あなたと顧客 (その顧客があなたであっても!) が同じページにいることを確認してください。
次に、問題に対する高レベルのソリューションが提案され、そこからデザインがページ上の吹き出しや箇条書きなどに変わりますが、ポイントは、デザイン可能なコンポーネントにシェイクアウトすることです。
その時点で、まだ作成されていないクラスのテストを作成し、それらのテストに合格するようにクラスを具体化します。
私はテスト優先のアプローチを使用し、動作するテスト済みのコンポーネントを構築します。それが私にとってうまくいくものです。コンポーネント インターフェイスが既知であり、それらがどのように相互に対話し、相互にサービスを提供するかについての「ルール」が既知である場合、通常は単純な「すべてを一緒にフックする」演習になります。
それが私のやり方であり、私にとってはうまくいきました。
于 2008-09-25T01:28:44.543 に答える
3
Agile Manifestoに目を通すことをお勧めします。トップダウンとボトムアップは、Built It All At Once の設計と構築に基づいています。
「包括的なドキュメントよりも機能するソフトウェア」とは、最初に構築するものは、実行できる最小の有用なものであることを意味します。上？下？ない。
若い頃は、契約によって厳密にトップダウンのプロジェクトに取り組んでいました。これはうまくいきません。確かに、うまくいきません。その結果、大量の冗長な設計とコードが得られます。無意識に適用した場合、それは健全なアプローチではありませんでした。
私が気付いたのは、アジャイル アプローチ (機能する小さな断片) は、問題を一度に把握できる部分に分解する傾向があるということです。トップダウン/ボトムアップはもはや重要ではありません。確かに、それはまったく問題ではないかもしれません。
「アジャイル開発のためにどのように分解しますか?」秘訣は、分解しなければならない大きなものを作成しないようにすることです。問題を分析すると、アクターがユースケースを達成しようとして、すべての情報を持っていないか、時間内に持っていないか、決定を実行できないなどの理由で失敗していることがわかります。
多くの場合、これらは分解が必要な大きなものではありません。そうであれば、目標の逆方向に問題を解決する必要があります。目標から、その目標を達成できるようにするもの、イネーブラーを可能にするものなど。目標は大きなものであることが多いため、一般的なビジネス目標から詳細なビジネス プロセスおよびステップまで、トップダウンになる傾向があります。
ある時点で、目標に至るこれらのさまざまなステップを概説します。分析部分（物事を分解する）を行いました。次は合成の部分です。実際に構築できるものに、私たちが持っているものを再構築します。合成はボトムアップです。しかし、夢中にならないようにしましょう。私たちにはいくつかの視点があり、それぞれが異なります。
モデルがあります。これは、多くの場合、詳細からより大きな概念モデルに組み込まれます。その後、OLTP 用に正規化されたモデルに再度分解されることもあります。または、OLAP 用に正規化されたスター スキーマに分解されます。次に、正規化されたモデルから ORM マッピングを作成します。上 - 下 - 上。
加工をしております。これは、多くの場合、ビジネス プロセスの概要から処理手順の詳細まで構築されます。次に、ソフトウェアはステップを中心に設計されます。次に、ソフトウェアはクラスとメソッドに分割されます。下 - 上 - 下。
【余談。知識のあるユーザーの場合、この分解によって新しい役職と働き方が定義されます。知識のないユーザーの場合、古い仕事は残り、古い仕事を新しいソフトウェアにマッピングするためのドキュメントを山ほど書いています。]
コンポーネントがあります。私たちはしばしば部品を見て、利用可能なコンポーネントについて知っていることを見て、一種のマッチングを行います. これは最もランダムなプロセスです。それは結晶が形成される方法に似ています - 核形成の中心があり、それらの中心の周りでデザインが固まります. ウェブサービス。データベース。トランザクション管理。パフォーマンス。音量。ソリューションの一部またはすべてを実装するコンポーネントを選択するのに役立つさまざまな機能。多くの場合、ボトムアップ (機能から製品へ) のように感じますが、トップダウンの場合もあります (「私はハンマーを持っているので、すべてを釘と呼んでいます」 == すべてに RDBMS を使用します)。
最終的には、コーディングする必要があります。これはボトムアップです。すこし。パッケージ構造を定義する必要があります。クラス全体を定義する必要があります。その部分はトップダウンでした。クラス内にメソッドを記述する必要があります。私はよくこのボトムアップを行います。つまり、メソッドを大まかに作成し、単体テストを作成し、メソッドを完成させます。次のメソッドを大まかに描いて、単体テストを書いて、メソッドを完成させます。
推進原則はアジャイルです。つまり、機能するものを構築します。詳細は、上、下、前、後、データ、プロセス、アクター、サブジェクト エリア、ビジネス価値など、マップ全体にあります。
于 2008-09-25T01:22:45.900 に答える
2
また、アジャイルな方法で、最初にテストを書きます!
次に、すべてのソフトウェアは、
- 赤 - コードはテストに失敗します
- 緑 - コードはテストに合格します
- リファクタリング - 意図を維持するコードの改善。
欠陥、新機能、変更。それはすべて同じパターンに従います。
于 2008-09-25T01:40:49.023 に答える
2
はい。それらすべてを行います。
皮肉に聞こえるかもしれませんが（すみません、元の形に戻します）、これは実際には正解がないケースです。
于 2008-09-25T01:18:53.147 に答える
1
優れたソフトウェア設計者 (私の意見では、すべてのソフトウェア開発者もある程度のソフトウェア設計者であるべきです) の魔法は、トップダウンとボトムアップを同時に実行できることにあると私は信じています。
私が指導者から教わったことは、関係するエンティティを理解するために非常に簡単なトップダウンから始め、次に作成したい基本要素を理解するためにボトムアップに移行し、次にバックアップしてどのように作成するかを確認することです。ボトムアップの結果について私が知っていることを知っているので、「彼らが真ん中で出会う」まで、1レベル下に行くことができます.
それが役立つことを願っています。
于 2009-05-13T15:25:12.600 に答える
1
トップバース・ボトムダウンのデザイン以上に考慮すべきことがあると思います。設計を管理可能な作業単位に分割する必要があることは明らかですが、優先順位付けなども考慮する必要があります。また、反復開発プロジェクトでは、前の解決策を提供した後、次の反復のために問題を再定義することがよくあります。 .
于 2008-09-25T01:29:07.443 に答える
1
デザインするときは、ミドルアウトが好きです。私はドメインをモデル化してからクラスを設計し、そこからデータベースと UI に移動するのが好きです。UI ベースまたはデータベース ベースの特定の機能がある場合は、それらも事前に設計することがあります。
コーディングするときは、可能な限りボトムアップ (最初にデータベース、次にビジネス エンティティ、次に UI) を行うのが一般的です。この方法で物事をまっすぐに保つ方がはるかに簡単だと思います.
于 2008-09-25T01:40:17.027 に答える
1
2番目のオプションは合理的な方法です。問題を理解できるチャンクに分割すると、トップダウンのアプローチにより、小さな詳細をすべて実装する前に、主要な設計上の欠陥が明らかになります。低レベルの機能のスタブを作成して、すべてをまとめておくことができます。
于 2008-09-25T01:19:34.473 に答える
0
どちらも有効なアプローチです。時々、一方が他方より自然に「感じる」だけです。ただし、大きな問題が1つあります。一部の主流言語、特にそれらのフレームワークとライブラリは、構文の強調表示、バックグラウンドタイプのチェック、バックグラウンドコンパイル、インテリジェントコード補完、IntelliSenseなどのIDEサポートに非常に重点を置いています。
ただし、これはトップダウンコーディングでは機能しません。トップダウンコーディングでは、まだ実装していない変数、フィールド、定数、関数、プロシージャ、メソッド、クラス、モジュール、特性、ミックスイン、アスペクト、パッケージ、およびタイプを常に使用します。そのため、IDEはコンパイルエラーのために絶えずあなたに怒鳴り、至る所に赤い波線があり、コードが完成しないなどの理由があります。そのため、IDEではトップダウンコーディングをほとんど禁止しています。
于 2008-09-28T04:27:40.383 に答える
0
アウトサイドインデザイン。
トップエンドで達成しようとしていることから始め、ボトムエンドで何に取り組まなければならないかを知っています。真ん中で出会うまで、両端を動かし続けます。
于 2008-09-25T01:31:50.357 に答える
0
「どちらでもない」と言っているすべての人にある程度同意しますが、誰もがスペクトルのどこかに当てはまります.
私はどちらかというとトップダウンのタイプです。高レベルの機能/ポイント/その他を 1 つ選び、それを完全なプログラムとして実装します。これにより、問題領域の範囲内で基本的な計画と構造をスケッチできます。
次に、別の機能から始めて、2 番目に使用できる元の機能からすべてをリファクタリングして、新しい共有エンティティにします。泡立てて、すすぎ、塗布が完了するまで繰り返します。
しかし、問題を聞いて、その上にアプリケーションを構築するために必要なすべてのサポート サブシステムについて考え始める、ボトムアップ型の人をたくさん知っています。
どちらのアプローチも間違っているとか正しいとは思いません。どちらも結果を出すことができます。2 つの異なる視点から問題に取り組むことができるので、協力してくれるボトムアップの人を見つけようとさえしています。
于 2008-09-25T01:56:15.087 に答える
0
私はトップダウンの変形を行います。私は最初にインターフェイスを試す傾向があり、それを機能のリストとして使用します。このバージョンの良いところは、そうでなければ文句を言うだろう IDE でも動作することです。まだ実装されていないものへの 1 つの関数呼び出しをコメント アウトするだけです。
于 2009-01-13T19:56:07.003 に答える