インターネットで多くのことを読んでも、JAVA ソフトウェア アーキテクチャに関する情報を見つけるのは非常に困難です。しかし、ソフトウェア開発のアーキテクチャは基本的に同じです。そこで、インターネット上で他の言語のソフトウェア アーキテクチャに関する多くの記事を検索しました。ここでもう一度、ソフトウェア アーキテクチャ、特に JAVA プロジェクト アーキテクチャについての私の見解を話させてください。正しくないかもしれませんが、これが私のここ数年の総括でもあります。
1. プロジェクト外での再利用は考えないようにする
ソフトウェアの再利用性を高めたほうが良いと考える人は多いですが、プロジェクト内で特定のモジュールやメソッドを設計する際に、プロジェクト外での再利用を考慮しすぎると、必然的にその数が増えてしまいます。プロジェクトが複雑になると、開発時間のオーバーヘッドが増加します。これで次のプロジェクトのコストが削減できると言う人もいるかもしれません。ニーズは何ですか?さまざまな面で影響を与える要因は何ですか?この時点で誰がこのすべてを知るでしょう。 本当に再利用したいのであれば、現在のプロジェクトの希望的観測ではなく、プロジェクト完了後に再利用可能な部分を抽出し、修正・最適化して企業の再利用可能な資産として活用すべきです。プロジェクト外での再利用性を考慮する これは、ソフトウェアの作業に慣れていない多くのプログラマーがよく犯す間違いであり、よく考えれば考えるほど、作成したソフトウェアが設計上の効果を達成できず、基本的な機能を完了できなくなってしまいます。コードロジックプロセスの多くは、プログラム機能が完璧ではありません。
2. プロジェクト構造を頻繁に確認する
プロジェクト アーキテクチャは通常、プロジェクトの実装が開始される前に決定されるものであり、全体的な設計です。ただし、現時点では、プロジェクト要件の理解と複雑さの見積もりはまだ初期段階にあります。プロジェクトの開発プロセスにおいて、プロジェクトの理解とともにアーキテクチャを改善できなければ、プロジェクトのメンバーは必然的に間違ったアーキテクチャに従ってプロジェクトを開発することになります。したがって、プロジェクトのアーキテクチャを頻繁にチェックし、必要なリファクタリングを行う必要があります。
3. リファクタリング
これだけ書いたのに、見直すのは時間の無駄ではない、という人もいます。彼は、午後 1 回のリファクタリングで、その後数か月の開発スピードが想像を絶するほど短縮されるとは考えていなかったかもしれません。さらに、リファクタリングを通じて、既存の実装を置き換えるより簡単な方法を考えることができ、他のモジュールの開発も簡素化できます。
4. 過剰な統合を避け、各モジュールが独自の処理のみを実行できるようにします。
OA 開発の一般的な例としては、通常、業務システムには多数の承認があり、承認をユニバーサル モジュールにしようとすぐに思いつく人が多いでしょう。これは問題ありませんが、よくある問題は、承認後の業務処理を承認モジュールのビジネス ロジックに組み込んでしまう人が多すぎることです。ただし、承認が完了した後の処理については、この処理を行うモジュールが自ら処理します。
5. 過度に柔軟にならないようにする
デザインとコードは常に可能な限り柔軟であるとは限りません。一般的な例としては、ジェネリックスを使用する場合、クラスまたはメソッドはさまざまなオブジェクトで動作できますが、JAVA で一般的に使用される 3 層アーキテクチャでは、一連のクラスがもともと特定のエンティティで動作することを目的としている場合、その必要はありません。 to ジェネリック型として指定し、使用時に特定のエンティティクラスを使用するように指定します。これは余計な気がします。
6. ケーキのアイシングを軽減する機能
ページが更新されない、表示がクールになるなどの理由で業務インターフェースが複雑になると、極端な場合には業務処理に支障をきたすことになります。どんなにインターフェースが美しくても、続けていては役に立ちません。 1 つのアドバイスについては、ビジネス プロセスが正しく行われていることを確認したい場合にのみ、他のアドバイスを考慮してください。その前提条件となるのがユーザーとのコミュニケーションです。つまり、JAVAで実現されるプロジェクトは、業務処理がうまく実現されて初めて、インターフェースの美しさやユーザーの視覚を考慮することができるのです。
7. 適切に分割する
これは4と同様です。各モジュールの複雑さを可能な限り軽減し、精神的な作業を物理的な作業に変換するようにしてください。一般的な例としては、フォームには通常、追加、変更、削除、表示の機能があります。ただし、最初の 3 つの操作は通常、特定の機能ポイント、特定の状態、および特定の権限 (おそらくシステム内の唯一のインターフェイスのみ) を持つユーザーによってのみ実行されます。ただし、これら 4 つの操作をプロジェクトの隅々に分散させると、インターフェイスの数は削減できますが、インターフェイスのさまざまな状態や条件が複雑になります。インターフェイス要素を読み取り専用に設定するために必要な判断を行い、複雑さは指数関数的に増加します。ビューを分割した場合でも、複雑さは線形になります。以前のものよりも大きくなり、10*10 に変換するのがはるかに簡単になり、コンポーネント化することもできます。
8.顧客との良好なコミュニケーションを維持する
顧客とのコミュニケーションの維持に注意を払わない人が多く、顧客とのコミュニケーションはプロジェクトの需要段階でのみ必要であると考えています。顧客の要件は時間の経過とともに変化するため、これは非常に悪い習慣です。顧客とのコミュニケーションを定期的に維持することによってのみ、顧客のニーズの変化をできるだけ早く理解し、顧客のニーズにできるだけ早く対応できるようにプロジェクトの構成計画を調整することができます。
9.プロジェクト アーキテクチャとデータベース アーキテクチャの関係
多くの人は、メモリ内に実装されている限り、プロジェクト開発中にデータベースは必要ないと考えています。個人的には、これは非常に悪い開発習慣だと思います。ただし、データベースはプロジェクトの特定のニーズに応じて決定されます。しかし、プロジェクトがアーキテクチャのプロセスでデータベースのアーキテクチャをまったく考慮していない場合、プロジェクトで実装されたものがデータベースに記録されにくくなったり、データベースの設計が非常に面倒になったりする可能性があり、実質的にコストが増加します。プロジェクト開発の難しさ。さらに、プロジェクト開発プロセス中にデータベースを考慮しないと、プロジェクトがデータベースにリンクされた後に、一部のビジネス ロジックの実装の失敗、データの損失などの問題が発生する可能性があります。
もちろん、多くの人がそれぞれの建築様式に基づいて異なる建築上の意見を持っており、私の意見が正しいとは限りません。私の作品から皆さんが何かを学べることを願っています。また、皆さんが建築についての意見を共有できることを願っています。