4

アジャイルを使用している場合でも、プロジェクトの実装を開始する前に、高レベルのアーキテクチャが必要になります。

高レベルのアーキテクチャとは、プロジェクトを小さな部分、インフラストラクチャ、分散型/Web ベース/シック クライアントなどに分割することを意味します。

このトピックに関する書籍や記事はありますか??

4

5 に答える 5

4

私は Kent Beck と何度かこの議論をしましたが、彼はあなたが間違っている、これらのアーキテクチャ上の決定を下す必要はない、あるいは可能な限り単純なものを選ぶべきだと言うでしょう。そこから作業を進めてください。

私が見る問題は、STTCPW が実際には機能せず、多くのやり直しが必要になることを発見する前に、長い道のりをたどることができるということです。段階的に適切に物事を進めている場合、またはリスク主導型モデルを使用して、最もリスクの高い決定を最初に検討している場合は、これらのことを比較的早期に発見できることを願っていますが、保証はありません。

その反対側は、多くのアジャイル プロジェクトが、Ruby on Rails や J2EE など、ほとんどのアーキテクチャが事前に決定されているコンテキストにあるということです。これらのシステムは、環境が決まっているため、リスクを大幅に軽減します。

このトピックに関する特定の本は知りませんが、書くことを考えています。これは、アジャイル コミュニティでまだほとんど議論の余地があります。

おそらく私のお気に入りのフォーラムは、Martin Fowler の blik i とInfoQです。

于 2008-12-20T00:29:10.183 に答える
3

このトピックに関する優れた記事は、「アーキテクトが必要なのは誰?」です。マーティン・ファウラー著。

私の個人的な見解では、アーキテクチャに関する決定を前もって行う必要は、思っているよりもはるかに少なくて済みます。合理的な見積もりを出すのに十分なだけのことをすれば、うまくいくはずです。

ただし、設計力に細心の注意を払い、リファクタリングを上手に行う必要があります。あなたはできるだけ早くそれを実践し始めたいと思うでしょう. 事前にアーキテクチャを考え出していなかったので、多くの機会が得られるはずです。;)

あなたは間違った決定を下すでしょうか？はい。アーキテクチャを変更するには時間がかかりますか。もちろん。

しかし、事前にアーキテクチャを考えようとしないことで、多くの時間を節約することもできました。また、プロジェクトの開始時には情報量が最も少ないため、事前のアーキテクチャは実際には「適切」ではありません。運が良ければ、それは「ただ」やり過ぎであり、後で変更したほうがよいという決定も行われる可能性が高くなります。

リスクに関しては、最も重要な機能の開発を最初に開始する必要があることを忘れないでください。そうすれば、アーキテクチャは実際、最も重要な機能を最適にサポートするように構築されます。これは、まさにあるべき姿です。

このトピックに関する良い本は、Robert Martin の「Agile Software Development - Principles, Patterns, Practices」です。

于 2008-12-21T01:39:29.777 に答える
1

これはアジャイルの重要な問題であり、まだ誰も解決していないと思います。最初のアーキテクチャの決定は成功に不可欠であり、Kent Beck が理想的に言うように、十分な情報が得られるまで決定を延期することをお勧めします。

もちろん、彼がそう言えるのは、彼がクライアントを選ぶことができ、その自由度を要求できるからです。プロジェクトの 3 か月後に実装言語を変更することは、彼にとっては問題ないかもしれませんが、ほとんどの場合、それは選択肢ではありません。かなり早い段階でいくつかの決定を行う必要があり、それらは正しくなければなりません。不十分な情報で作業し、経験と知識を最大限に活用する必要があります。

ほとんどのアーキテクチャ テキストには、必要な機能を表す英文から始まり、名詞を分解し、最終的には動詞を分類子の意味表現に分解し、最終的に実際のコード行に変換するプロセスがあります。

アジャイルではこれを簡単に行うことはできません。ユーザー ストーリーは詳細が不十分であり、機能要件の他のソースがないため、分解には向いていません。

少なくともリリース計画を作成し、どのストーリーがどのイテレーションで実装される可能性が高いかをある程度把握するまでは、UML のようなものは (少なくとも自分のメモを残すこと以外は) 避けることをお勧めします。この時点で、詳細なアーキテクチャ作業を開始できます。

その前に、いくつかの決定を下す必要があります。管理できる最善の方法は、できることの詳細を特定することだと思います。

  • 非機能要件が何であるか、
  • どの規格に準拠する必要があるか、
  • どの既存システムと連携する必要があるか、およびそれらの API
  • 展開プラットフォームがどうなるか、
  • 対象の運用チームがどのようなスキルを持っているか、

そのようなこと。多くの場合、これらの制約は、高レベルのコンポーネントとそれらが存在する場所を確信できる期待される配信に十分に組み込むことができます。

私が強くお勧めするのは、ユーザー インターフェイスに関する情報アーキテクチャの作業を行うことです。UI は壊れやすく、変更するのに費用がかかります。ワイヤフレーム表現は、利害関係者と議論して貴重な回答を得ることができるほど、完成した記事に十分近いものです。

ただし、優れた情報アーキテクトが必要であり、ユーザー ストーリーの IA の変更を定期的に調べて、それらのすべてが適切に評価されるようにする必要があります。

UI 以外の作業については、ソリューションの中核となる概念のいくつかについて慎重に検討してください。多くの場合、トランザクションの境界やトランザクションの安全性に関する要件などは、それぞれに具体的に何が含まれているかを知らなくても、非常に明確に識別して述べることができます。取引の種類。特にトランザクションとデータの安全性に関する制約と成功基準についていくつかのステートメントを作成し、利害関係者に同意してもらいます。

最後に、各反復の開始時に、詳細なモデリングとアーキテクチャの作業を行うことができます。これは、ここで実際の機能分解が行われるためです。この作業の事前反復に時間をかけることを強くお勧めします。反復のための実際のコーディングの開始時に、作成しようとしているすべてのクラス、それがどこに存在し、何と通信するかについて明確な考えを持っている必要があります。これがないと、開発チームの調整ができません。

于 2008-12-28T10:47:53.050 に答える
1

一般的なアーキテクチャでは、たとえば次のようなものがあります。

また、Java などのプラットフォーム固有の書籍もあります。

  • Sun 認定アーキテクト for JEE スタディ ガイド
  • Broemmer: J2EE のベスト プラクティス

ウィキペディアには、ソフトウェア アーキテクチャに関するポインタのかなり包括的なリストがあります。

于 2008-12-20T00:27:28.283 に答える
0

機能分解について話し合っているようです。

ボトムアップとトップダウンの両方のアプローチがあります。プロジェクトを両面から考えるのが好きです。一番下から始めると、クラスとそのメソッドについて考えることができるので、これは特に重要です。上から始めると、プログラムがどのように流れるかを考えることができます。

試す：

大規模な C++ ソフトウェア設計 (Addison-Wesley Professional Computing シリーズ)、John Lakos 著 (ペーパーバック - 1996 年 7 月 20 日)

于 2008-12-20T01:33:18.743 に答える