コードを記述する前に、アプリケーションのアーキテクチャをどのように計画しますか？
私が苦労しているのは、コードを書く前にアプリケーションのアーキテクチャを計画することです。
アプリケーションが何をする必要があるかを絞り込むための要件を収集するのではなく、全体的なクラス、データ、およびフロー構造をレイアウトし、それらの考えを繰り返して信頼できる計画を立てるための良い方法を効果的に考えますIDEを開く前にアクションを念頭に置いてください。現時点では、IDEを開いて空のプロジェクトを作成し、ビットとボブの書き込みを開始し、そこからデザインを「成長」させるのは簡単です。
UMLを収集することはこれを行う1つの方法ですが、経験がないので、ちょっと曖昧に思えます。
どのようにyoコードを書く前にアプリケーションのアーキテクチャを計画しますか？ UMLを使用する場合は、小規模なアプリケーションの開発者に簡潔で実用的な紹介をお勧めしますか？
ご意見ありがとうございます。
紙やホワイトボードに最初に書くことは本当に重要だと思います。その後、必要に応じてUMLに移行しますが、最初は手で描くだけの柔軟性に勝るものはありません。
私は次を考慮します：
- システムが何をすべきか、つまり、システムが解決しようとしている問題は何か
- 顧客は誰で、彼らの願いは何ですか
- システムと統合する必要があるもの
- 考慮する必要があるレガシーな側面はありますか
- ユーザーの介入は何ですか
- 等...
次に、システムをブラックボックスと見なし始めます。
- そのブラックボックスで発生する必要がある相互作用は何ですか
- ブラックボックス内で発生する必要がある動作、つまり、ブラックボックスがより高いレベルで目的の動作を示すためにそれらの相互作用に発生する必要があるもの、たとえば予約システムからの着信メッセージの受信と処理、データベースの更新など。
その後、さまざまな内部ブラックボックスで構成されるシステムのビューが表示され始めます。各ブラックボックスは、同じ方法でさらに分解できます。
UMLは、このような動作を表すのに非常に優れています。 UMLの多くのコンポーネントのうち2つを使用するだけで、ほとんどのシステムを説明できます。
- クラス図
- シーケンス図。
記述する必要がある動作に並列性がある場合は、アクティビティ図も必要になる場合があります。
UMLを学習するための優れたリソースは、Martin Fowlerの優れた本「UML Distilled」です（ Amazon link -そこにあるスクリプトキディリンクナチスのためにサニタイズ（-：）。 UMLの各コンポーネントの一部。
ああ。私が説明したのは、ほとんどIvar Jacobsonのアプローチです。 Jacobsonは、OOの3つのアミーゴの1つです。実際、UMLは当初、3人のアミーゴを形成する他の2人、Grady BoochとJim Rumbaughによって開発されました
Steve McConnellのCode Complete、特に「Design in Construction」に関する彼のプレゼントの章をぜひご覧ください。
彼のウェブサイトからダウンロードできます：
.NET用に開発している場合、Microsoftは Application Architecture Guide 2.0b1 を（無料の電子書籍として！）公開しました。コードを書く前にアーキテクチャを計画することに関して、本当に良い情報をたくさん提供します。
あなたが必死なら、非.NETベースのアーキテクチャにそれの大きなチャンクを使用できると思います。
私は、アーキテクチャの大部分がすでに事前に決定されているWeb開発（WebForms、現在はMVC）のほとんどをWeb開発で行っており、私のプロジェクトのほとんどは1年もかからない1人の人手によるかなり小規模な取り組みであると言って、これを前置きします。また、ビジネスオブジェクトとデータのやり取りをそれぞれ処理するORMとDALがあることも知っています。最近、私はこのためにLINQを使用するように切り替えました。そのため、「設計」の多くは、DBMLデザイナーを介したデータベースの設計とマッピングになります。
通常、私はTDD（テスト駆動開発）方式で作業します。前もって建築や設計の詳細に取り組んでいる時間はあまりありません。ストーリーを通じて、ユーザーとアプリケーションとの全体的な相互作用を収集します。ストーリーを使用して相互作用の設計を行い、アプリケーションの主要なコンポーネントを発見します。このプロセスでは、顧客とのホワイトボードをたくさん行います。ダイアグラム形式で維持するのに十分重要だと思われる場合は、デジタルカメラで詳細をキャプチャすることがあります。主に私のストーリーは、Wikiのストーリー形式でキャプチャされます。最終的に、ストーリーはリリースとイテレーションに整理されます。
この頃には、私は通常、アーキテクチャについてかなり良い考えを持っています。それが複雑な場合、または通常とは異なるもの（通常とは異なる）を使用している場合（典型的ではない）他の人と作業している場合は、（再びホワイトボードで）図を作成します。複雑なインタラクションでも同じことが言えます。ホワイトボード上でページレイアウトとフローを設計し、そのセクションが完了するまでそれを保持（またはカメラ経由でキャプチャ）します。どこに行き、何を最初に行う必要があるかについての一般的な考えが得られたら、最初のストーリーのテストを書き始めます。通常、これは次のようになります。「わかりました、それを行うには、これらのクラスが必要になります。これから始めて、これを行う必要があります。」それから私は陽気にTDDを開始し、アーキテクチャ/設計はアプリケーションのニーズから成長します。
定期的に、何度かコードを書き直したり、「これは本当に臭い」と思うようになり、デザインをリファクタリングして重複を削除したり、臭いビットをよりエレガントなものに置き換えたりします。ほとんどの場合、適切な設計原則に従って機能をダウンさせることに関心があります。既知のパターンを使用し、あなたが進むにつれて良い原則に注意を払うことはかなりうまくいくことがわかります。
http://dn.codegear.com/article/3186
私はUMLを使用していますが、このガイドは非常に便利で読みやすいと思います。別のものが必要な場合はお知らせください。
「ホワイトボード、スケッチ、ポストイットノートは優れた設計ツールです。複雑なモデリングツールは、照明よりも注意をそらす傾向があります。」 Venkat SubramaniamとAndy Huntによるアジャイル開発者のプラクティス から。
少し先を計画するほど頭が良くない。前もって計画を立てるとき、私の計画はいつも間違っていますが、今では悪い計画にn日を費やしています。私の制限は、ホワイトボードで約15分と思われます。
基本的に、正しい方向に向かっているかどうかを確認するために、できる限りの作業を行いません。
デザインで重要な質問を探します。AがBからCに移行するとき、Dにとって十分な速度ですか？そうでない場合は、別のデザインが必要です。これらの質問のそれぞれは、スパイクで答えることができます。スパイクがよく見える場合、デザインがあり、それを拡張する時間です。
できるだけ早く本当の顧客価値を得る方向にコーディングするので、顧客はどこに行くべきかを教えてくれます。
私はいつも物事を間違っているので、私はそれらを正しくするのを助けるためにリファクタリングに頼っています。リファクタリングにはリスクがあるため、単体テストを作成する必要があります。事実のために単体テストを書くのはカップリングのために難しいので、最初にテストを書きます。このようなものについて規律を保つことは難しく、異なる脳は物事を異なるように見ているので、私は仲間のコーディングを持っているのが好きです。私のコーディング仲間には鼻があるので、私は定期的にシャワーを浴びます。
それを「極端なプログラミング」と呼びましょう。
UMLは表記法です。それはあなたのデザインを記録する方法ですが、（私の意見では）デザインをすることではありません。物事を書き留める必要がある場合は、UMLをお勧めします。これは「最良」ではなく、おそらく他の人がすでに読み方を知っている標準であり、独自の「標準」の発明に勝るからです。
UMLの最良の導入は、まだ ML Distilled であると思います。これは簡潔で、使用する場所について実用的なガイダンスを提供し、全体を購入する必要がないことを明確にしているからです。役に立つUML/RUPストーリー
設計を行うのは難しいです。StackOverflowの1つの答えで実際に把握することはできません。残念ながら、そのような私の設計スキルは長年にわたって進化してきたので、私があなたを参照できるソースはありません。
しかし、私が有用であるとわかったモデルの1つは、ロバストネス分析です（グーグル、しかしイントロがあります here ）。システムがすべきことのユースケース、関与するもののドメインモデルがある場合、堅牢性分析は、2つを接続し、システムの主要なコンポーネントが必要なものを見つけるのに役立つツールであることがわかりました。
しかし、最善のアドバイスは広く読まれ、一生懸命に考え、実践することです。それは純粋に教えられるスキルではありません、あなたは実際にそれをしなければなりません。
私は何も確信していませんcan実装前に前もって計画されています。私は10年の経験を持っていますが、それは4社（1社の2つのサイトを含み、ほぼ正反対です）でしかなく、私の経験のほとんどは巨大なクラスターを見るという点でした****** **が発生します。私はリファクタリングのようなものが本当に物事を行うための最良の方法であると考え始めていますが、同時に、私は私の経験が限られており、私が見たものに反応しているかもしれないことに気付きます。私が本当に知りたいのは、最高の経験を得る方法ですので、適切な結論に達することができますが、近道はなく、人々が間違ったことをしているのを見るのに多くの時間が必要です:( 「製品の展開が成功していることから明らかなように、人々が正しいことをしている会社で働き、私が単なる逆張りの野郎かどうか、または私が思っているほど本当に頭がいいかどうかを知りたいわたし。
私はしばらくの間建築を行ってきました。 BPMLを使用して最初にビジネスプロセスを改良し、次にUMLを使用してさまざまな詳細をキャプチャします！通常、3番目のステップはERDです！ BPMLとUMLを使い終えると、ERDはかなり安定します！完璧な計画はなく、抽象化が100％になることはありません。リファクタリングを計画し、目標はリファクタリングを可能な限り最小限にすることです！
違いがあります：UMLはアプリケーションアーキテクチャに使用できますが、技術アーキテクチャ（フレームワーク、クラスダイアグラム、シーケンスダイアグラムなど）に使用される頻度が高くなります。 。
アプリケーションアーキテクチャは、いくつかの機能仕様（将来について何も仮定せずに操作の性質とフローを記述する）を取得したときに発生します実装）、およびそれらを技術仕様に変換します。
これらの仕様は、実装いくつかのビジネスと機能のニーズに必要なapplicationsを表しています。
したがって、複数の大規模な金融ポートフォリオ（機能仕様）を処理する必要がある場合、その大規模な仕様を次のように分割する必要があると判断する場合があります。
- これらの重い計算を異なるサーバーに割り当てるディスパッチャ
- これらのポートフォリオの処理を開始する前に、すべての計算サーバーが稼働していることを確認するランチャー。
- 何が起こっているかを示すことができるGUI。
- ユニットテストだけでなく、機能テストや回帰テストも容易にするために、特定のポートフォリオアルゴリズムをアプリケーションアーキテクチャの他の部分とは独立して開発するための「共通」コンポーネント。
基本的に、アプリケーションアーキテクチャについて考えることは、必要な「ファイルのグループ」を決定することです。一貫した方法で開発する（同じグループのファイルでランチャー、GUI、ディスパッチャーを開発することはできません...：同じペースで進化することはできません）
アプリケーションアーキテクチャが適切に定義されている場合、通常、各コンポーネントはconfigurationコンポーネント、つまりVCSにすべてバージョン管理できるファイルのグループの適切な候補です。 （バージョン管理システム）、つまりallそのアプリケーションのスナップショットを記録する必要があるたびに、そのファイルは一緒にラベル付けされます（再び、ラベル付けするのは難しいでしょうallシステム、各アプリケーションを同時に安定状態にすることはできません）
私は自分の考えを2つの領域に分解しようとしています。私が操作しようとしているものの表現と、それらを使って何をしようとしているのかです。
操作しようとしているものをモデル化しようとすると、一連の個別のアイテム定義を思い付きます。eコマースサイトには、SKU、製品、顧客などがあります。注文やカテゴリなど、私が取り組んでいる非物質的なものもいくつかあります。システムに「名詞」がすべて揃ったら、これらのオブジェクトの相互関係を示すドメインモデルを作成します。注文には顧客と複数のSKUがあり、多くのSkusが製品にグループ化されます。オン。
これらのドメインモデルは、UMLドメインモデル、クラス図、およびSQL ERDとして表すことができます。
システムの名詞を特定したら、動詞に進みます。たとえば、これらの各項目が注文を確定するために実行する操作です。これらは通常、私の機能要件からのユースケースに非常によくマッピングされます。これらを見つける最も簡単な方法は、UMLシーケンス、アクティビティ、コラボレーション図、またはスイムレーン図です。
これを反復プロセスと考えることが重要です。ドメインの少しのコーナーを実行してから、アクションを実行してから戻ります。理想的には、コードを書いて時間を割いて、作業を進めていきます。アプリケーションがアプリケーションよりも先に進みすぎないようにする必要があります。このプロセスは、すべての完全かつ最終的なアーキテクチャを構築していると考える場合、通常ひどいものです。本当に、あなたがやろうとしているのは、チームが開発を進めるときに共有する基本的な基盤を確立することです。チームメンバーがシステムを説明するときに使用するための共有語彙を作成するのがほとんどであり、それを行う方法に関する法律を定めているのではありません。
システムをコーディングする前に十分に考え抜くのに苦労しています。一部のコンポーネントに大まかな目を向けるだけでも、後から想像していたよりもはるかに複雑であることに気付くのは簡単すぎます。
1つの解決策は、本当に一生懸命試すことです。どこでもUMLを書きます。すべてのクラスを通過します。他のクラスとどのように相互作用するかを考えてください。これは難しいです。
私がやることが好きなのは、最初に概要を説明することです。私はUMLは好きではありませんが、要点を理解する図を描くのが好きです。それから私はそれを実装し始めます。空のメソッドを使用してクラス構造を書き出しているだけでも、以前は見落としていたことがよくあるので、デザインを更新します。コーディングしているときに、何か別のことをする必要があることに気付くので、デザインを更新します。 反復プロセスです。 「最初にすべてを設計し、次にすべてを実装する」という概念はウォーターフォールモデルとして知られており、他の人がそれがソフトウェアを実行する悪い方法であることを示していると思います。
Archimateを試してください。