ソフトウェアがどのように構築されるのかを確認する

  • 9 分

最新のソフトウェア開発は、すべてをゼロから構築し、既存のコンポーネントからアプリケーションを組み立てるまで根本的に変わりました。 このコンポーネントベースのアプローチを理解することは、現代の開発環境でソフトウェアを効果的に実装および管理するために不可欠です。

コンポーネント ベースのソフトウェア モデル

今日のアプリケーションは、 元のコードと再利用可能なコンポーネントを組み合わせることによって構築されています。 開発チームは、すべての機能を記述するのではなく、次の要素からソリューションを組み立てます。

  • 元のビジネス ロジック コード: アプリケーションを区別する特定のビジネス要件、ワークフロー、および固有の機能を実装するカスタム コード。
  • オープン ソース ライブラリとフレームワーク: コミュニティによって作成および保守される再利用可能なコンポーネント。データ処理、認証、ユーザー インターフェイス、通信プロトコルなどの一般的な機能を提供します。
  • 商用コンポーネント: ベンダーが提供するサード パーティ製ライブラリ。多くの場合、特殊な機能、サポート、および保証を提供します。
  • 統合コード: コンポーネントを接続し、インターフェイスを調整し、システムのさまざまな部分間の相互作用を調整する "Glue" コード。

調査によると、 最新のアプリケーションは、プロジェクトの外部で保持されている既存のコンポーネント% 約 80 個で構成されており、開発チームによって作成された元のコード% は 20 個に過ぎません。 この構成は、ビルドから組み立てまで、ソフトウェアの作成方法に関する基本的な変化を反映しています。

ソフトウェアがこのように構築される理由

コンポーネント ベースのアプローチには、大きな利点があります。

開発速度

既存のコンポーネントを再利用すると、開発が大幅に高速化されます。

  • 実証済みのソリューション: チームは、他のユーザーが既に解決した問題を解決する代わりに、確実に動作する、戦いでテストされたコンポーネントを組み込みます。
  • 開発時間の短縮: Web アプリケーション フレームワーク、データベース ドライバー、または認証システムを最初から構築する場合、数か月または数年かかります。 既存のコンポーネントを使用すると、これを数日または数時間に短縮できます。
  • ビジネス価値に重点を置く: 開発者は、一般的なインフラストラクチャを再発明するのではなく、独自のビジネス ロジックに集中します。
  • 市場投入までの時間の短縮: チームがすべてのレイヤーをゼロから構築しているわけではありませんので、アプリケーションは運用環境に早く到達します。

品質と信頼性

適切に保守されたオープンソース コンポーネントは、多くの場合、カスタム コードの品質を超えています。

  • コミュニティ審査: 一般的なオープンソース プロジェクトでは、何千人ものユーザーが問題を特定して報告し、堅牢で信頼性の高いコードを作成しています。
  • エキスパートの開発: 多くのオープンソース プロジェクトは、特定の問題ドメインを専門とする専門家によって作成および管理されています。
  • 継続的な改善: アクティブなプロジェクトは、世界中の共同作成者から定期的な更新、バグ修正、および機能強化を受け取ります。
  • 運用テスト: 何千ものアプリケーションで使用されるコンポーネントは、さまざまな環境とシナリオでテストされています。

コスト効率

オープンソース コンポーネントを使用すると、開発とメンテナンスのコストが削減されます。

  • ライセンス料なし: ほとんどのオープンソース コンポーネントは自由に使用できます。シートごとまたはデプロイごとのライセンス コストを回避できます。
  • 共有メンテナンスの負担: バグの修正と改善はコミュニティによって提供され、組織のメンテナンス コストが削減されます。
  • 人員の削減ニーズ: Teams では、コンポーネントを通じて既存の専門知識を組み込むことができるため、すべてのテクノロジ レイヤーのスペシャリストは必要ありません。
  • 総保有コストの削減: 商用コンポーネントには直接コストがかかりますが、オープンソースの代替手段では、ライセンス料なしで同様の機能が提供されることがよくあります。

イノベーションへのアクセス

オープンソース コミュニティは、技術革新を推進します。

  • 最先端の機能: オープンソース プロジェクトでは、多くの新しいテクノロジとアプローチが最初に登場します。
  • エコシステムの効果: 一般的なフレームワークは、互換性のあるコンポーネント、ツール、知識のエコシステムを作成します。
  • 柔軟な導入: 組織は、大規模な財務コミットメントなしで新しいテクノロジを試すことができます。
  • コミュニティの知識: 広範なドキュメント、チュートリアル、コミュニティ サポートにより、導入が容易になります。

オープンソースコンポーネントとクローズドソースコンポーネント

コンポーネントには、ソース コードの可用性に基づく 2 つの基本的なカテゴリがあります。

オープン ソース コンポーネント

オープン ソース コードは、 誰でも検査、使用、変更、および多くの場合に貢献するために一般公開されています。

  • ソース コードの可視性: 実際の実装を確認し、コンポーネントのしくみを理解し、セキュリティ プラクティスを確認できます。
  • コミュニティの関与: 多くの人が改善に貢献し、バグを修正し、機能を追加することができます。
  • ライセンス管理の使用方法: オープン ソース ライセンスでは、無制限の使用から、派生製品が同じライセンスを共有する要件まで、許可される使用を指定します。
  • 透明性： セキュリティ研究者、開発者、およびユーザーは、脆弱性、バックドア、または品質の問題についてコードを監査できます。

一般的なオープンソース コンポーネントは次のとおりです。

  • プログラミング言語とランタイム: Python、Node.js、.NET Core、Go、Rust。
  • Web フレームワーク: React、Angular、Vue.js、Express、Django、Spring Boot。
  • データベース： PostgreSQL、MySQL、MongoDB、Redis、Elasticsearch。
  • 開発ツール: Visual Studio Code、Git、Docker、Kubernetes。
  • ライブラリ： Lodash、Moment.js、NumPy、Pandas、TensorFlow。

クローズド ソース コンポーネント

クローズド ソース (独自の) コンポーネント は、ソース コードを使用できないようにする機能を提供します。

  • 二項分布: コンポーネントは、ソース コードなしでコンパイル済みバイナリまたはパッケージ ライブラリとして提供されます。
  • ベンダーコントロール: 作成する組織は、更新プログラム、機能、ライセンス条項を制御します。
  • 商用サポート: 多くのクローズド ソース コンポーネントには、プロフェッショナル サポート、サービス レベル アグリーメント、保証メンテナンスが含まれます。
  • 限定された透明性: ユーザーは実装の詳細を検査できないため、セキュリティと品質の評価がより困難になります。

たとえば、多くの商用データベース ドライバー、独自の SDK、ベンダー固有のツール、特殊な業界固有のライブラリなどがあります。

コンポーネントの分散方法

パッケージ には、コンポーネントを配布および管理するための正式なメカニズムが用意されています。

パッケージ構造

  • バイナリ コード: アプリケーションで使用できるコンパイル済みライブラリ。
  • メタデータ: 名前、バージョン、作成者、説明など、パッケージに関する情報。
  • 依存 関係： コンポーネントが機能するために必要なその他のパッケージの一覧。
  • ライセンス情報: パッケージの使用方法を管理する法的用語。
  • ドキュメンテーション： 使用手順、API リファレンス、および例。

パッケージ エコシステム

さまざまなプログラミング言語によって、パッケージ エコシステムが確立されています。

  • npm (ノード パッケージ マネージャー): 200 万パッケージを超える世界最大のパッケージ レジストリである JavaScript および TypeScript パッケージ。
  • PyPI (Python パッケージ インデックス): Python パッケージ。データ サイエンス、Web 開発、自動化などのライブラリを提供します。
  • NuGet: C#、F#、および Visual Basic アプリケーション用の .NET パッケージ。
  • Maven Central: エンタープライズおよび Android 開発用の Java パッケージ。
  • RubyGems: Web アプリケーションとオートメーション用の Ruby パッケージ。
  • Crates.io: システム プログラミング用の Rust パッケージ。

パッケージ管理ツール

パッケージ マネージャーは、依存関係の ダウンロード、インストール、更新を自動化します。

  • 依存関係の解決: 必要な依存関係を自動的に特定してインストールします。
  • バージョン管理: アプリケーションで使用するパッケージのバージョンを追跡します。
  • 更新通知: 新しいバージョンが利用可能になったときに開発者に通知します。
  • 脆弱性スキャン: 一部のパッケージ マネージャーは、セキュリティ スキャンを統合して既知の脆弱性を特定します。

コンポーネントベースの開発の影響

コンポーネントベースのアプローチは大きな利点を提供しますが、次のような課題もあります。

依存関係管理の複雑さ

  • 依存関係ツリー: アプリケーションは 20 個のパッケージに直接依存している可能性がありますが、これらのパッケージは他のパッケージに依存し、数百または数千の依存関係のツリーを作成します。
  • バージョンの競合: 異なるコンポーネントでは、互換性のないバージョンの共有依存関係が必要になる場合があります。
  • 更新カスケード: 1 つのコンポーネントを更新するには、他の多くのコンポーネントを更新する必要があります。

セキュリティに関する考慮事項

  • 継承された脆弱性: 依存関係のセキュリティの脆弱性は、アプリケーションに影響します。
  • サプライ チェーン攻撃: 悪意のあるアクターは、一般的なパッケージを侵害して、それらに依存するアプリケーションを攻撃する可能性があります。
  • メンテナンスされていない依存関係: 保守されなくなったコンポーネントは、セキュリティ更新プログラムを受け取りません。

ライセンスの準拠

  • ライセンスの義務: 各オープンソース ライセンスには要件があります。一部は無制限の商用使用を許可し、他のライセンスではソース コードを共有する必要があります。
  • ライセンスの急増: アプリケーションには、数十の異なるライセンスを持つ数百のパッケージが組み込まれる場合があります。
  • コンプライアンスの負担: 組織は、ライセンスの義務を追跡し、コンプライアンスを確保する必要があります。

運用上の依存関係

  • 外部ホスティング: 多くのアプリケーションは、障害が発生する可能性があるパブリック レジストリでホストされているパッケージに依存しています。
  • レジストリの可用性: パブリック レジストリが使用できなくなった場合、ビルドとデプロイが失敗する可能性があります。
  • パッケージの削除: 作成者は、パブリック レジストリからパッケージを削除して、それらに依存するアプリケーションを中断することがあります。

コンポーネントを使用して最新のソフトウェアを構築する方法を理解することは、オープンソース ソフトウェアを実装する際に組織が対処する必要があるセキュリティ、法的、運用上の懸念に不可欠なコンテキストを提供します。 このモジュールの残りのユニットでは、これらの懸念事項と、それらを効果的に管理するための戦略について説明します。