コードの再利用

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

コードの再利用は、ソフトウェアの再利用とも呼ばれ、既存のソフトウェアまたはソフトウェアの知識を使用して、新しいソフトウェアを構築することです[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攻撃return指向プログラミング、およびジャンプ指向プログラミングがあります。[12] [13]

コンポーネント

コンポーネントは、オブジェクト指向の範囲で、コラボレーションクラスのセット(または1つのクラスのみ)とそのインターフェイスを表します。インターフェイスは、コンポーネントの交換を可能にする役割を果たします。再利用可能なコンポーネントは、コンポーネントソースコード管理テクノロジ(CSCM)を使用して、SCMリポジトリ間で分離および同期することもできます。[要出典]

外部のコンピューター

「コードの再利用」の概念全体には、ソフトウェア以外のエンジニアリングアプリケーションも含まれます。たとえば、コンピュータ支援設計のパラメトリックモデリングでは、再利用可能な設計を作成できます。標準化により、相互運用可能なパーツが作成され、多くのコンテキストで再利用できます。[要出典]

批判

コードを再利用すると、再利用されるコンポーネントに依存することになります。Rob Pikeは、「少しのコピーは少しの依存関係よりも優れている」と述べました。彼がGoogleに入社したとき、同社はコードの再利用に重点を置いていました。彼は、Googleのコードベースは、コンパイル速度と保守性の点で、以前のポリシーの結果に依然として苦しんでいると信じています。[14]

も参照してください

参考文献

  1. ^ フレーク、WB; カン・キョウ(2005年7月)。「ソフトウェア再利用研究:現状と将来」。ソフトウェアエンジニアリングに関するIEEEトランザクション31(7):529–536。CiteSeerX10.1.1.75.635 _ 土井10.1109 /TSE.2005.85S2CID14561810 _
  2. ^ a b レッディ、マーティン(2011)。C ++のAPI設計ボストン:モーガンカウフマン。ISBN 978-0-12-385004-1OCLC704559821 _
  3. ^ Selaolo、Karabo; Hlomani、Hlomani(2016)。「アルゴリズムオントロジークラスターに向けて:モジュラーコードの再利用とポリグロットプログラミングのために」コンピュータサイエンスの進歩5:63 –Researchgate経由。
  4. ^ "4.コードの再利用:関数とモジュール-ヘッドファーストPython、第2版[本]"www.oreilly.com 2022-01-26を取得
  5. ^ フェイトサ、ダニエル; Ampatzoglou、Apostolos; Gkortzis、Antonios; ビビ、スタマティア; Chatzigeorgiou、Alexander(2020年9月)。「実際のコードの再利用:技術的負債の利益または害」ジャーナルオブシステムズアンドソフトウェア167:110618。doi 10.1016 /j.jss.2020.110618S2CID219502749_ 
  6. ^ ロンバードヒルグループ。「ソフトウェアの再利用とは」lombardhill.comロンバードヒルグループ。2019年1月23日にオリジナルからアーカイブされました2014年10月22日取得
  7. ^ ロンバードヒルグループ。「ソフトウェアの再利用とは」2019年1月23日にオリジナルからアーカイブされました2014年10月22日取得
  8. ^ McConnell、Steve(1996)。迅速な開発:ワイルドソフトウェアのスケジュールを使いこなす。ISBN 978-1-55615-900-8
  9. ^ a b コロンボ、F。(2011)。「再利用だけではありません」SharedNow.blogspot
  10. ^ Champman、M。; Van der Merwe、Alta(2008)。「小さなプロジェクト中心の会社で体系的なソフトウェアの再利用を検討する」Proceeding SAICSIT '08発展途上国におけるIT研究に関する南アフリカコンピュータ科学者および情報技術者協会の2008年年次研究会議の議事録:技術の波に乗る土井10.1145 /1456659.1456662ISBN 978-1-60558-286-3
  11. ^ 「コードの再利用」DocForge2011年7月10日にオリジナルからアーカイブされました2022年2月18日取得
  12. ^ a b Bletsch、Tyler(2011)。コード再利用攻撃:新しいフロンティアと防御ノースカロライナ州立大学。ISBN 978-1-124-75297-6
  13. ^ ブレッチ、タイラー; 江、Xuxian; フリー、ヴィンスW; リャン、ジェンカイ(2011)。「ジャンプ指向プログラミング:新しいクラスのコード再利用攻撃」(PDF)情報、コンピュータ、通信のセキュリティに関する第6回ACMシンポジウムの議事録ACM。pp。30–40。土井10.1145 /1966913.1966919ISBN  978-1-4503-0564-82017年8月7日にオリジナル (PDF)からアーカイブされました2017年8月7日取得
  14. ^ Goプログラミング言語(2015-12-01)、Go Proverbs – Rob Pike – Gopherfest – 2015年11月18日、 2021-12-22にオリジナルからアーカイブ、 2016年2月26日取得

外部リンク