効率

経験豊富なプログラマは、良いアーキテクチャと悪いアーキテクチャを簡単に見分けることができますが、それをいくつかの言葉で説明するように求められると、うまく説明できる可能性は低いでしょう。優れたアーキテクチャに対する単一の基準や単一の定義はありません。

しかし、よく考えてみると、優れたアーキテクチャが満たすべき基準をいくつか書くことができます。優れたアーキテクチャとは、まず第一に、プログラムの開発と保守のプロセスをよりシンプルかつ効率的にする論理アーキテクチャです。

プログラムのアーキテクチャが優れていれば、プログラムがどのように動作するのか、どこにコードを書けばよいのかを理解するのが常に簡単になります。適切に設計されたプログラムは、変更、テスト、デバッグ、開発が容易です。賢い人々は、優れたアーキテクチャのための次の基準を策定しました。

  • 効率;
  • 柔軟性;
  • 拡張性。
  • スケーラビリティ。
  • テスト容易性。
  • コードの保守性。

システム効率。もちろん、プログラムは、さまざまな条件下で、割り当てられたタスクを解決し、その機能を適切に実行する必要があります。どのプログラムも (書かれていれば) やるべきことをやっているように見えますが、多くの場合、まったくそうではありません。

主張したとおりに動作しないプログラムに常に遭遇するでしょう。

  • Libre Office は Microsoft Office の完全な代替品です (実際にはそうではありません)。
  • Edge ブラウザは、すべての Web 標準をサポートしています (実際にはサポートしていません)。
  • 銀行はユーザーの個人データのセキュリティを重視しています (実際にはそうではありません)。

また、パフォーマンス、信頼性、タイムリーなバグ修正、既知の脆弱性に関する情報の公開についてはまだ触れていません。

完璧な人間がいないことは明らかですが、プログラムはその主要なタスクを解決する必要があります。したがって、効率がなければどこにもなりません。

柔軟性

私の意見では、効率よりも重要なのは柔軟性です。要件の変化や新しい要件の追加に応じて、アプリケーションは時間の経過とともに変更する必要があります。既存の機能に変更を加えるのがより速くて便利になり、それによって引き起こされる問題やエラーが減り、システム アーキテクチャがより柔軟になります。

Java webinar

初心者のプログラマやアーキテクトは、現在のタスクに理想的なアーキテクチャが必要だと考えることがよくあります。いいえ。1 年以内に通知されるタスクに対して、理想的なアーキテクチャが必要です。あなたは、将来のタスクをまだ知りませんが、それがどのようなものになるのかを知っておく必要があります。

予期せぬことが常に起こるので、それらを予測しようとすることは意味がありません。ただし、そのようなタスクが表示されることを考慮する必要があります。したがって、開発プロセスでは、得られたものをどのように変更する必要があるかという観点から評価するようにしてください。

「現在のアーキテクチャ上の決定が間違っていることが判明したら、どうなるでしょうか?」、「どの程度のコードが変更されるでしょうか?」と自問してください。システムの 1 つのフラグメントを変更しても、他のフラグメントに影響を与えるべきではありません。

可能な限り、アーキテクチャ上の決定は固定化すべきではなく、アーキテクチャ上のエラーによる影響は合理的に制限されるべきです。「優れたアーキテクチャでは、重要な決定を遅らせることができ」(Bob Martin)、間違いによる「コスト」を最小限に抑えることができます。

これらのアプローチの 1 つは、アプリケーションをマイクロサービスに分割することです。既存のロジックを個別の部分に分割するのは簡単です。しかし、最大の問題は、1 つの小さな機能を実装するために、一度に数十のサービスに将来の変更を加えることです。

スケーラビリティ

スケーラビリティとは、プロジェクトに新しい人を追加することで開発時間を短縮する能力です。このアーキテクチャでは、多くの人が同時にプログラムに取り組むことができるように、開発プロセスを並列化できる必要があります。

このルールは単独で実行されているように見えますが、実際にはすべてがまったく逆です。超人気の書籍『The Mythical Man-Month』さえあり、プロジェクトに新しい人が追加されると開発時間が長くなる理由が説明されています。

拡張性

拡張性とは、システムのコア構造を壊すことなく、新しい機能やエンティティをシステムに追加できる機能です。初期段階では、基本的で最も必要な機能のみをシステムに組み込むのが合理的です。

これはいわゆるYAGNI原則です - あなたはそれを必要としません、「あなたはそれを必要としません」。同時に、このアーキテクチャでは、必要に応じて追加機能を簡単に追加できる必要があります。そのため、最も可能性の高い変更の導入に最小限の労力で済むようになりました。

システムのアーキテクチャが柔軟で拡張可能である (つまり、変更と進化が可能である) という要件は非常に重要であるため、別の原則である「オープン/クローズ原則」として定式化されることもあります。オープンクローズ原則は、 5 つの SOLID 原則のうちの 2 番目です。つまり、ソフトウェア エンティティ (クラス、モジュール、関数) は拡張に対してオープンである必要がありますが、変更に対してはクローズされている必要があります。

言い換えれば、システムの既存の部分を書き換えることなく、システムの動作を変更および拡張できる必要があります。

これは、既存のコードを変更することなく、新しいコード (拡張機能) を記述することで動作の変更や新しい機能の追加を実現できるようにアプリケーションを設計する必要があることを意味します。

この場合、新しい要件の出現は既存のロジックの変更を必要としませんが、主にそれを拡張することによって実装できます。この原則は「プラグイン アーキテクチャ」(Plugin Architecture) の基礎です。これを実現するための技術については後で説明します。

サーブレットとフィルターを覚えていますか? 実際、サーブレットを使用してすべて同じロジックを実装できるのに、なぜフィルターが必要であり、また別のインターフェイスが必要だったのでしょうか?

さまざまなサービス機能を別のレイヤーに移動できるようにしたのは、フィルター (サービス サーブレット) の概念の発明です。また、将来的には、フィルターの動作を変更するときに、サーブレットを変更する必要がなくなりました。

フィルターが発明される前は、リクエストのリダイレクトを担当するサービス ロジックはすべてサーブレット自体の中にありました。そして多くの場合、ロジックに 1 つの小さな変更を加えると、すべてのサーブレットを調べて、すべてのサーブレットにさまざまな変更を加える必要が生じます。

テスト容易性

Java バックエンド開発者の場合、サーバー アプリケーションは多くの場合、一連のメソッドを REST API として公開します。そして、すべてのメソッドが意図したとおりに機能することを確認するには、テストでカバーする必要があります。

一般に、API テスト カバレッジは良いスタイルです。これにより、API が意図したとおりに実際に実行していることを確認できます。また、さらに重要なことは、サーバー ロジックに変更を加えて、誤って何かを壊していないことを簡単に確認できることです。

テストを書き始めるとすぐに、プライベート メソッド、強結合、静的クラスと変数など、ほとんどのコードはまったくテストできないことに気づくでしょう。

「コードが機能するのになぜテストが必要なのですか?」と初心者は疑問に思うでしょう。

「テストできないのに、なぜ動作するコードが必要なのでしょうか?」と専門家は尋ねるでしょう。

テストが簡単なコードにはバグが少なく、信頼性が高くなります。しかし、テストはコードの品質を向上させるだけではありません。ほとんどすべての開発者は、最終的には、「優れたテスト容易性」の要件も自動的に優れた設計を導く指針となるという結論に達します。

以下は、『理想のアーキテクチャ』という本からの引用です: 「クラスの "テスト容易性" の原則を、優れたクラス設計の "リトマス試験紙" として使用してください。テスト コードを 1 行も書かなくても、この質問には 90 秒で答えることができます。」ケースの % は、彼のデザインがどのように「良い」か「悪い」かを理解するのに役立ちます。」

テストに基づいてプログラムを開発するための全体的な方法論があり、これはテスト駆動開発 (TDD) と呼ばれます。もちろん、これはもう一方の極端です。コードを書く前にコードを書いてください。

コードの保守性

原則として、多くの人がこのプログラムに取り組んでいます - 辞める人もいれば、新しい人が来ます。IT企業におけるプログラマーの平均勤務期間は1年半です。つまり、5 年前のプロジェクトに取り組んだ場合、最初からそれに取り組んでいたのは同僚の 20% だけということになります。

他人が書いたプログラムを維持し、開発するのは非常に困難です。プログラムがすでに作成されている場合でも、エラーを修正したり、軽微な修正を加えたりするなど、プログラムの保守を継続する必要があることがよくあります。そして多くの場合、これは執筆に参加していない人々によって行われなければなりません。

したがって、優れたアーキテクチャでは、新しい人がシステムを比較的簡単かつ迅速に理解できるようにする必要があります。プロジェクトは次のとおりである必要があります。

  • よく構成されています。
  • 重複を含めないでください。
  • 適切にフォーマットされたコードを用意してください。
  • 文書を含めることが望ましい。
  • プログラマーにとって標準的で使い慣れたソリューションを適用する必要があります。

取り組んでいるプロジェクトを5 段階評価で簡単に評価できます。これらの要件ごとに2 点を数えてください。そして5つ以上取れたらラッキーです。

プログラマには、驚かないという原則があります。システムが奇抜であればあるほど、他の人が理解するのは難しくなります。通常、ユーザー インターフェイスに関連して使用されますが、コードの作成にも適用できます。