NGINX から最新のアプリケーションを開発するための原則。 パート1

皆さん、こんにちは。 コース開始に向けて PHPバックエンド開発者、伝統的に役立つ資料の翻訳を共有します。

ソフトウェアはますます複雑になる一方で、ますます多くの日常タスクを解決します。 マーク・アンドレッセンがかつて言ったように、それは世界を飲み込みます。

その結果、アプリケーションの開発と提供の方法はここ数年で劇的に変化しました。 これらは地殻変動であり、その結果、一連の原則が生まれました。 これらの原則は、チームの構築、設計、開発、およびエンド ユーザーへのアプリケーションの配信に役立つことが証明されています。

原則は次のように要約できます。 アプリケーションは小規模で、Web ベースであり、開発者中心のアーキテクチャである必要があります。。 これら XNUMX つの原則を念頭に置くと、エンド ユーザーに迅速かつ安全に配信でき、簡単にスケーラブルで拡張可能な、堅牢なエンドツーエンド アプリケーションを作成できます。

提案された各原則には多くの側面があり、保守と使用が容易で信頼性の高いアプリケーションを迅速に提供するという最終目標に各原則がどのように貢献するかを説明します。 それが何を意味するかを明確にするために、その反対の原則と関連して原則を見ていきます。たとえば、「必ず使用してください」 小ささの原理'。

この記事が、成長を続けるテクノロジー スタックのコンテキストでの設計への統一されたアプローチを提供する、最新のアプリケーションを構築するための提案された原則の使用を促進することを願っています。

これらの原則を適用すると、次のようなソフトウェア開発の最新トレンドを活用できるようになります。 DevOps アプリケーションの開発と配信、コンテナの使用 (例: デッカー) およびコンテナ オーケストレーション フレームワーク (たとえば、 Kubernetes)、マイクロサービスの使用 (マイクロサービス アーキテクチャを含む) nginxの и ネットワーク通信アーキテクチャ マイクロサービスアプリケーション向け。

最新のアプリケーションとは何ですか?

最新のアプリケーション? モダンスタック? 「モダン」とは一体何を意味するのでしょうか？

ほとんどの開発者は、最新のアプリケーションが何で構成されているかについて一般的な概念しか持っていないため、この概念を明確に定義する必要があります。

最新のアプリケーションは、React JavaScript ライブラリを使用したユーザー インターフェイス、Android または iOS 用のモバイル アプリケーション、API を使用して別のアプリケーションに接続するアプリケーションなど、複数のクライアントをサポートします。 最新のアプリケーションは、データやサービスを提供するクライアントの数が無制限であることを意味します。

最新のアプリケーションは、要求されたデータとサービスにアクセスするための API を提供します。 API は不変かつ定数である必要があり、特定のクライアントからの特定のリクエストのために特別に記述されてはなりません。 API は HTTP(S) 経由で使用でき、GUI または CLI で使用できるすべての機能へのアクセスを提供します。

データは、JSON などの一般的に受け入れられている相互運用可能な形式で利用できる必要があります。 API は、RESTful API や GraphQL が適切なインターフェイスを提供するように、クリーンで組織化された方法でオブジェクトとサービスを公開します。

モダン アプリケーションはモダン スタック上に構築され、モダン スタックはそのようなアプリケーションをサポートするスタックです。 このスタックを使用すると、開発者は HTTP インターフェイスと明確な API エンドポイントを備えたアプリケーションを簡単に作成できます。 選択したアプローチにより、アプリケーションは JSON 形式でデータを簡単に送受信できるようになります。 言い換えれば、最新のスタックは、次の XNUMX 要素アプリケーションの要素に対応します。 マイクロサービス.

このタイプのスタックの一般的なバージョンは、以下に基づいています。 Java, Python , Node, ルビー, PHP и Go。 マイクロサービスアーキテクチャ nginxの は、前述の各言語で実装された最新のスタックの例を表しています。

私たちはマイクロサービスのみのアプローチを推奨しているわけではないことに注意してください。 皆さんの多くは、進化が必要なモノリスを扱っている一方で、マイクロサービス アプリケーションに向けて拡張および進化している SOA アプリケーションを扱っている人もいます。 さらに、サーバーレス アプリケーションに移行しているものや、上記の組み合わせを実装しているものもあります。 この記事で概説されている原則は、いくつかの小さな変更を加えるだけで、これらの各システムに適用されます。

原則

モダン アプリケーションとモダン スタックが何であるかについて共通の理解が得られたので、次はモダン アプリケーションの開発、実装、保守に役立つアーキテクチャと開発原則について詳しく見ていきましょう。

原則の XNUMX つは「小さなアプリケーションを作成する」ように聞こえますが、そう呼んでおきましょう。 小ささの原理。 多くの可動部分で構成される非常に複雑なアプリケーションがあります。 さらに、小さな個別のコンポーネントからアプリケーションを構築すると、アプリケーション全体の設計、保守、操作が容易になります。 (「シンプルにする」ではなく「単純化する」と言ったことに注意してください)。

XNUMX 番目の原則は、開発者が実装中のインフラストラクチャや CI/CD の懸念から解放されながら、開発中の機能に集中できるように支援することで開発者の生産性を向上させることができるということです。 つまり、私たちのアプローチを一言で言えば、 開発者に焦点を当てた.

最後に、アプリケーションに関するすべてをネットワークに接続する必要があります。 過去 20 年間にわたり、ネットワークが高速化し、アプリケーションがより複雑になるにつれて、私たちはネットワーク化された未来に向けて大きな進歩を遂げてきました。 すでに説明したように、最新のアプリケーションは、多くの異なるクライアントによってネットワーク経由で使用される必要があります。 ネットワーク思考を建築に適用すると、次のような大きな利点があります。 小ささの原理 そしてアプローチのコンセプトは、 開発者指向.

アプリケーションを設計および実装するときにこれらの原則を念頭に置くと、製品の開発と提供において紛れもない利点が得られます。

これら XNUMX つの原則をさらに詳しく見てみましょう。

小ささの原理

人間の脳は、同時に大量の情報を認識することが困難です。 心理学では、認知負荷という用語は、情報を記憶に保持するために必要な精神的努力の総量を指します。 開発者の認知的負荷を軽減することは、アプリケーション全体の現在の複雑なモデルや開発中の機能を頭の中に留めておくのではなく、問題の解決に集中できるため、優先事項です。

アプリケーションは次の理由で分解します。

• 開発者の認知的負荷の軽減。
• テストの加速と簡素化。
• アプリケーションの変更を迅速に配信します。

開発者の認知的負荷を軽減する方法はいくつかありますが、ここで小規模の原則が役に立ちます。

そこで、認知的負荷を軽減するための XNUMX つの方法を紹介します。

1. 新しい機能を開発する際に考慮しなければならない期間を短縮します。期間が短いほど、認知的負荷は低くなります。
2. XNUMX 回限りの作業が実行されるコードの量を削減します。つまり、コードが減り、負荷が減ります。
3. アプリケーションに増分変更を加えるプロセスを簡素化します。

開発期間の短縮

方法論が確立されていた時代に戻りましょう。 waterfall が開発プロセスの標準であり、アプリケーションの開発または更新にかかる期間は XNUMX か月から XNUMX 年が一般的でした。 通常、エンジニアはまず製品要件 (PRD)、システム参照文書 (SRD)、アーキテクチャ計画などの関連ドキュメントを読み、これらすべてを XNUMX つの認知モデルに統合し、それに従ってコードを作成します。 要件、つまりアーキテクチャが変化したため、認知モデルの更新についてチーム全体に常に知らせるために多大な努力が必要でした。 最悪の場合、このアプローチでは単に仕事が麻痺してしまう可能性があります。

アプリケーション開発プロセスにおける最大の変化は、アジャイル手法の導入でした。 この方法論の主な特徴の XNUMX つは、 agile 反復的な開発です。 これはひいてはエンジニアの認知的負荷の軽減につながります。 開発チームにアプリケーションを XNUMX つの長いサイクルで実装するよう要求するのではなく、 agile このアプローチを使用すると、フィードバックを受け取りながら、迅速にテストしてデプロイできる少量のコードに集中できます。 アプリの認知負荷は XNUMX か月から XNUMX 年に移行し、大規模なアプリに対するより曖昧な理解をターゲットとした XNUMX 週間の追加または機能変更のための膨大な仕様が必要になりました。

大規模なアプリケーションから、次のスプリントまでに XNUMX つの機能のみを念頭に置き、XNUMX 週間のスプリントで完了できる特定の小さな機能に焦点を移すことは、大きな変化です。 これにより、常に変動する認知負荷を軽減しながら、開発の生産性を向上させることができました。

方法論において agile 最終的なアプリケーションは、元のコンセプトをわずかに修正したバージョンになることが予想されるため、開発の終点は必然的に曖昧になります。 明確で正確なのは、特定の各スプリントの結果のみです。

小さなコードベース

認知的負荷を軽減するための次のステップは、コードベースを減らすことです。 一般に、最新のアプリケーションは大規模です。堅牢なエンタープライズ アプリケーションは、数千のファイルと数十万行のコードで構成される場合があります。 ファイルの編成方法によっては、コードとファイル間のリンクや依存関係が明らかになる場合もあれば、その逆の場合もあります。 使用するライブラリや、デバッグ ツールがライブラリ/パッケージ/モジュールとカスタム コードをどの程度区別できるかによっては、コードの実行自体のデバッグでも問題が発生する可能性があります。

アプリケーションのコードの実用的なメンタル モデルの構築には膨大な時間がかかり、開発者に再び大きな認知的負担がかかることになります。 これは、大量のコードがあり、その機能コンポーネント間の相互作用が明確に定義されておらず、機能境界が尊重されないために注目オブジェクトの分離が曖昧になることが多い、モノリシック コード ベースに特に当てはまります。

エンジニアの認知的負荷を軽減する効果的な方法の XNUMX つは、マイクロサービス アーキテクチャに移行することです。 マイクロサービス アプローチでは、各サービスは XNUMX つの機能セットに焦点を当てます。 一方、サービスの意味は通常定義されており、理解可能です。 サービスの境界も明確です。サービスとの通信は API を介して行われるため、あるサービスで生成されたデータを別のサービスに簡単に渡すことができることに注意してください。

他のサービスとの対話は、通常、REST の使用など、シンプルでクリーンな API 呼び出しを使用する少数のユーザー サービスと少数のプロバイダー サービスに限定されます。 これは、エンジニアの認知的負荷が大幅に軽減されることを意味します。 最大の課題は、サービス相互作用モデルと、複数のサービス間でトランザクションなどがどのように発生するかを理解することです。 その結果、マイクロサービスを使用すると、コードの量が減り、明確なサービス境界が定義され、ユーザーとプロバイダーの間の関係が理解できるようになるため、認知的負荷が軽減されます。

小さな段階的な変更

原則の最後の要素 小ささ 変更管理です。 開発者にとっては、コード ベース (おそらく自分自身の古いコードであっても) を見て、「これはクソだ、すべて書き直す必要がある」と言いたくなるのが特に誘惑です。 これが正しい決定である場合もあれば、そうでない場合もあります。 開発チームにはグローバルなモデル変更の負担がかかり、それが膨大な認知負荷につながります。 エンジニアは、必要な機能を段階的にではあるがタイムリーに展開できるように、スプリント中に加えられる変更に集中することをお勧めします。 最終製品は事前に計画されたものと似ていますが、クライアントのニーズに合わせていくつかの修正とテストが行​​われます。

コードの大部分を書き直す場合、他のシステムの依存関係が影響するため、変更を迅速に提供できない場合があります。 変更の流れを制御するために、機能の非表示を使用できます。 原則として、これは、機能が実稼働環境にあるものの、環境変数設定 (env-var) やその他の構成メカニズムを使用して使用できないことを意味します。 コードがすべての品質管理プロセスを通過した場合、そのコードは潜在的な状態で本番環境に導入される可能性があります。 ただし、この戦略は、機能が最終的に有効になった場合にのみ機能します。 そうしないと、コードが乱雑になり、開発者が生産性を高めるために対処しなければならない認知的負荷が増えるだけです。 変更管理と段階的な変更自体は、開発者の認知負荷を手頃なレベルに保つのに役立ちます。

単純な追加機能の導入であっても、エンジニアは多くの困難を乗り越えなければなりません。 管理側としては、チームの不必要な負担を軽減して、重要な機能要素に集中できるようにすることが賢明です。 開発チームを支援するためにできることは XNUMX つあります。

1. 方法論を使用する agileチームが主要な機能に集中しなければならない時間枠を制限するためです。
2. アプリケーションを複数のマイクロサービスとして実装します。 これにより、実装できる機能の数が制限され、認知負荷を維持する境界が強化されます。
3. 大規模で扱いにくい変更よりも段階的な変更を優先し、小さなコードを変更します。 追加直後に表示されない場合でも、機能の非表示を使用して変更を実装します。

仕事に小規模の原則を適用すると、チームはより幸せになり、必要な機能の実装に集中し、質的な変更をより迅速に展開できる可能性が高くなります。 しかし、これは作業がより複雑にならないという意味ではありません。逆に、新しい機能の導入にはいくつかのサービスの変更が必要になる場合があり、このプロセスはモノリシック アーキテクチャでの同様のプロセスよりも困難になる可能性があります。 いずれにせよ、小型化アプローチを採用することの利点にはそれだけの価値があります。

最初の部分の終わり

間もなく、翻訳の第 XNUMX 部を公開する予定です。皆様からのコメントをお待ちしています。 オープンデー、今日の20.00時に開催されます。

出所： habr.com