コードの再利用

ソフトウェア開発（および一般的なコンピュータプログラミング）において、コードの再利用（ソフトウェアの再利用とも呼ばれる）とは、再利用の原則 に従って、既存のソフトウェアまたはソフトウェアの知識を使用して新しいソフトウェアを構築することです。 ^{[1] [2] : 7}

コードの再利用は、選択したプログラミング言語の複雑さに応じてさまざまな方法で実現できます。その方法は、コードのコピーアンドペースト（スニペットなど）のような低レベルのアプローチから、^[3]単純な関数（プロシージャまたはサブルーチン）またはモジュール（ライブラリなど）に編成された一連のオブジェクトまたは関数^{[4] [2] : 7}またはカスタム名前空間、および高レベルのパッケージ、フレームワーク、またはソフトウェアスイートまで多岐にわたります。

コードの再利用は依存関係を意味し、コードの保守性を難しくする可能性があります。^[要出典]少なくとも1つの研究では、コードの再利用により技術的負債が軽減されることがわかっています。^[5]

アドホックコードの再利用は、プログラミングの初期の頃から実践されてきました。プログラマーは、コード、テンプレート、関数、およびプロシージャのセクションを常に再利用してきました。しかし、ソフトウェアの再利用がソフトウェア エンジニアリングの研究分野として認められたのは、ベル研究所のダグラス マキロイがソフトウェア業界を再利用可能なコンポーネントに基づいて構築することを提案した 1968 年になってからです。

コードの再利用は、ソフトウェア製品の開発プロセスで何らかの形ですでに作成されている資産を活用することで、時間とリソースを節約し、冗長性を減らすことを目的としています。 ^[6]再利用の重要な考え方は、一度に作成されたコンピュータプログラムの一部を、後で作成される他のプログラムの構築に使用できる、または使用する必要があるというものです。

コードの再利用は、再利用可能な資産の別個に管理されたバージョンの作成を意味する場合があります。コードは再利用のために選択される最も一般的なリソースですが、開発サイクル中に生成される他の資産、たとえばソフトウェアコンポーネント、テストスイート、設計、ドキュメントなども再利用の機会を提供する場合があります。^[7]

ソフトウェアライブラリは、コード再利用の良い例です。プログラマーは、プログラムの一部を再利用できるように内部抽象化を作成したり、独自に使用するカスタム ライブラリを作成したりすることがあります。ソフトウェアをより簡単に再利用できるようにする特性には、モジュール性、疎結合、高い凝集性、情報の隠蔽、関心の分離などがあります。

新しく記述されたコードが既存のコードの一部を使用するには、何らかのインターフェース、つまり通信手段を定義する必要があります。これらには通常、サブルーチン、オブジェクト、クラス、またはプロトタイプの「呼び出し」または使用が含まれます。組織では、このようなプラクティスはドメイン エンジニアリング (ソフトウェア製品ラインエンジニアリングとも呼ばれます)によって形式化および標準化されます。

既存のプログラムの以前のバージョンを次のバージョンの開始点として使用するという一般的な方法も、コード再利用の一形態です。

いわゆるコードの「再利用」には、既存のプログラムからコードの一部またはすべてを新しいプログラムにコピーするだけのものがあります。このアプローチにより、組織は新製品の市場投入までの時間を短縮できますが、その後、カット アンド ペースト プログラミングによって発生するコード重複の問題の多くに悩まされることになります。

多くの研究者が、再利用をより速く、より簡単に、より体系的にし、通常のプログラミング プロセスの不可欠な部分にしようと取り組んできました。これらは、オブジェクト指向プログラミングの発明の背後にある主な目標の一部であり、オブジェクト指向プログラミングは、形式化された再利用の最も一般的な形式の 1 つになりました。やや後の発明は、ジェネリック プログラミングです。

もう 1 つの新しい手段は、ソフトウェア「ジェネレータ」を使用することです。これは、ユーザーが選択した一連のパラメータに基づいて、特定のタイプの新しいプログラムを作成できるプログラムです。このようなシステムの研究分野は、生成プログラミングとメタプログラミングです。

動機と推進要因に関して、再利用には次のようなものがあります。

• 機会主義的 – プロジェクトを開始する準備をしているときに、チームは再利用できる既存のコンポーネントがあることに気付きます。
• 計画的 – チームは、将来のプロジェクトで再利用できるようにコンポーネントを戦略的に設計します。

再利用はさらに次のように分類できます。

• 内部再利用 – チームは独自のコンポーネントを再利用します。チームがプロジェクトにとって重要なコンポーネントを制御したい場合、これはビジネス上の決定である可能性があります。
• 外部再利用 – チームはサードパーティのコンポーネントのライセンスを取得することを選択できます。サードパーティのコンポーネントのライセンスを取得すると、通常、社内で開発する場合のコストの1～20%のコストがかかります。^[8]チームは、コンポーネントの検索、学習、統合にかかる時間も考慮する必要があります。

再利用の形式や構造に関しては、コードは次のようになります。^[9]

• 参照 – クライアント コードには再利用されたコードへの参照が含まれており、そのため、それらは異なるライフ サイクルを持ち、異なるバージョンを持つことができます。
• フォーク – クライアント コードには再利用されたコードのローカル コピーまたはプライベート コピーが含まれており、単一のライフ サイクルと単一のバージョンを共有します。

フォーク再利用は、コードの重複の一種であるため、各コピーですべてのバグを修正する必要があり、再利用されたコードに加えられた機能強化はすべてのコピーに手動でマージする必要があり、そうしないと古くなってしまうため、推奨されないことがよくあります。しかし、フォーク再利用には、分離、再利用コードを変更する柔軟性、パッケージ化、展開、バージョン管理の容易さなどの利点があります。^[9]

体系的なソフトウェア再利用は、生産性を高め、ソフトウェア産業の品質を向上させるための戦略です。概念は単純ですが、ソフトウェア再利用を実際に成功させるのは困難です。その理由として挙げられているのは、ソフトウェア再利用が、それが実装されるコンテキストに依存しているということです。体系的なソフトウェア再利用に関連して対処する必要があるいくつかの問題点は次のとおりです。^[10]

• 明確かつ明確に定義された製品ビジョンは、ソフトウェア製品ライン(SPL)にとって不可欠な基盤です。
• 進化的な実装戦略は、企業にとってより実用的な戦略となるでしょう。
• 成功を確実にするためには、継続的な経営サポートとリーダーシップが必要です。
• SPL エンジニアリングをサポートするには適切な組織構造が必要です。
• プロジェクト中心の企業から製品中心の企業への考え方の転換が不可欠です。

コード再利用の非常に一般的な例は、ソフトウェア ライブラリを使用する手法です。さまざまなプログラムでは、さまざまな既知の形式間で情報を変換したり、外部ストレージにアクセスしたり、外部プログラムとインターフェイスしたり、一般的な方法で情報 (数値、単語、名前、場所、日付など) を操作したりするなど、多くの一般的な操作が必要です。新しいプログラムの作成者は、操作を実行するためにプログラム内に直接まったく新しいコードを記述して「車輪の再発明」を行う代わりに、ソフトウェア ライブラリのコードを使用してこれらのタスクを実行できます。ライブラリ実装には、十分にテストされており、異常なケースや難解なケースをカバーできるという利点がよくあります。欠点としては、パフォーマンスや目的の出力に影響を与える可能性のある詳細を微調整できないこと、ライブラリの取得、学習、構成に時間とコストがかかることなどが挙げられます。^[11]

デザイン パターンは、繰り返し発生する問題に対する一般的な解決策です。デザイン パターンは、具体的なものというよりは概念的なもので、ニーズに合わせて変更できます。ただし、抽象クラスとインターフェイスは、特定のパターンを実装するために再利用できます。

開発者は通常、サードパーティのアプリケーションやフレームワークを介して大規模なソフトウェアを再利用しますが、フレームワークは通常ドメイン固有であり、アプリケーションファミリにのみ適用されます^{[引用が必要]}。

関数型プログラミングでは、以前はデザイン パターンやフレームワークが使用されていた多くの場合、高階関数を使用できます。

レトロコンピューティングには、単にレトロプログラムが古いコンピューター、またはその エミュレーター上で実行されるというだけの理由で、コードの再利用が含まれます。

コンピュータセキュリティでは、コードの再利用はソフトウェアの悪用方法として採用されています。^[12] 攻撃者がプログラムの制御フローを変更するために直接コードを入力できない場合、たとえばW^Xなどのコードインジェクション防御が存在する場合、攻撃者は制御フローをメモリ内に存在するコードシーケンスにリダイレクトすることができます。

コード再利用攻撃の例としては、return-to-libc攻撃、リターン指向プログラミング、ジャンプ指向プログラミングなどがある。^{[12] [13]}

オブジェクト指向の範囲では、コンポーネントは、一連の共同クラス (または 1 つのクラスのみ) とそのインターフェイスを表します。インターフェイスは、コンポーネントの置き換えを可能にする役割を果たします。再利用可能なコンポーネントは、コンポーネント ソース コード管理テクノロジ (CSCM) を使用して、SCM リポジトリ間で分離および同期することもできます。^{[引用が必要]}

「コードの再利用」という概念は、ソフトウェア以外のエンジニアリング アプリケーションにも適用できます。たとえば、コンピュータ支援設計におけるパラメトリック モデリングにより、再利用可能な設計を作成できます。標準化により、相互運用可能なパーツが作成され、さまざまな状況で再利用できるようになります。^{[引用が必要]}

コードの再利用は、再利用されるコンポーネントへの依存につながります。ロブ・パイクは「少しの依存よりも少しのコピーの方が良い」と意見を述べています。彼がGoogleに入社したとき、同社はコードの再利用に重点を置いていました。彼は、Googleのコードベースは、コンパイル速度と保守性の点で、以前のポリシーの結果にまだ苦しんでいると考えています。^[14]

再利用可能なコードは通常、作成と設計に多くの労力を必要とします。Fred Brooks は、エッセイ「The Tar Pit」と「No Silver Bullet」で、その労力に関連する大幅に高いコストについて論じています。 誤解は、そのコストが回収されるメカニズムを注意深く理解せずに労力が費やされることが多いというものです。 正当化は、物理的な製造プロセスでの再利用可能な部品との類似点を誤って描くことから生じることがよくあります。 コードの記述は、複数のユニットの生産ではなく、単一の製品の設計に似ているため、誤りです。

• 同じことを繰り返さないで
• ソフトウェア再利用に関する国際会議
• 継承（オブジェクト指向プログラミング）
• 言語バインディング
• ここで発明されたものではない（反意語）
• 型多態性
• 手続き型プログラミング
• 車輪の再発明（反意語）
• 再利用性
• メトリクスの再利用
• 真実の唯一の情報源
• ソフトウェアフレームワーク
• 仮想継承

• ReNews – ソフトウェアの再利用とドメインエンジニアリングに関する情報サイト
• ソフトウェア再利用のヒント記事