手続き型プログラミング言語であるC言語のシンプルなソースコード例。生成されるプログラムは、コンピュータ画面に「Hello, World」と表示します。この「Hello World」という最初のコードは、1974年にベル研究所のブライアン・カーニハンによって考案されました。[1]

コンピューティングにおいて、ソース コード（または単にコードあるいはソース ）は、人間が読める プレーンテキストであり、最終的にはコンピュータの動作を制御することができます。コンピュータを制御するには、コンピュータ プログラムで処理する必要があります。つまり、インタープリタを介して直接実行するか、コンパイラなどを使用して、よりコンピュータが処理しやすい形式に変換する必要があります。場合によっては、コードはマシン コードに直接コンパイルされ、それ以上処理せずにコンピュータのネイティブ言語で実行できます。ただし、最近の多くの環境では、インタープリタを介して実行することも、ジャス​​トインタイムコンパイルによってオンデマンドでマシン コードにコンパイルすることもできる、バイトコードなどの中間表現へのコンパイルが必要になります。

背景

1940年代末に登場した最初のプログラム可能なコンピュータ[2]は、機械語（プロセッサが直接実行できる単純な命令）でプログラムされていました。機械語はデバッグが難しく、異なるコンピュータシステム間での移植性がありませんでした。 [3]当初、ハードウェア資源は不足し高価でしたが、人的資源は安価でした。[4]プログラムが複雑になるにつれて、プログラマの生産性がボトルネックになりました。これが、1950年代半ばにFortranなどの高級プログラミング言語の導入につながりました。これらの言語はハードウェアの詳細を抽象化し、人間がより簡単に理解できるアルゴリズムを表現できるように設計されました。 [5] [6]したがって、ソフトウェアは基礎となるコンピュータハードウェアとは別の命令であるため、比較的最近のものであり、 Fortran、Lisp、Cobolなどの初期の高級プログラミング言語にまで遡ります。[6]高級プログラミング言語の発明は、ソースコードをコンピュータハードウェアで直接実行できる機械語に自動的に変換するために必要なコンパイラと同時に行われました。[7]

ソースコードとは、人間が直接変更するコードの形式で、通常は高水準プログラミング言語で記述されます。オブジェクトコードは、機械によって直接実行可能であり、ソースコードから自動的に生成されます。ソースコードの生成には、多くの場合、中間段階としてアセンブリ言語が使用されます。オブジェクトコードは特定のプラットフォームでのみ動作しますが、ソースコードは別のマシンに移植し、そこで再コンパイルすることができます。同じソースコードでも、オブジェクトコードは大きく異なる可能性があります。これは、コンパイルされたマシンだけでなく、コンパイラによるパフォーマンス最適化によっても異なります。[8] [9]

組織

ほとんどのプログラムは実行に必要なリソースをすべて備えておらず、外部ライブラリに依存しています。コンパイラの機能の一部は、これらのファイルをリンクし、プログラムをハードウェアで実行できるようにすることです。[10]

より複雑なJavaソースコードの例です。オブジェクト指向プログラミングスタイルで記述されており、定型コードの例を示しています。プロローグコメントは赤、インラインコメントは緑、プログラムステートメントは青で示されています。

ソフトウェア開発者は、ソースコードファイルの変更を追跡するために構成管理（バージョン管理）を使用することが多い。構成管理システムは、どのオブジェクトコードファイルがどのバージョンのソースコードファイルに対応しているかを追跡する。[11]

目的

推定

ソースコード行数（SLOC）は、コンピュータプログラマーの生産性、コードベースの経済的価値、開発中のプロジェクトの労力見積もり、リリース後のソフトウェアメンテナンスの継続的なコストを評価する際の指標としてよく使用されます。[12]

コミュニケーション

ソースコードは、オンラインや書籍内のコードスニペットなど、関係者間でアルゴリズムを伝達するためにも使用されます。[13]

コンピュータプログラマーにとって、既存のソースコードを確認することはプログラミング技術を学ぶ上で有益です。[13]開発者間でソースコードを共有することは、プログラミングスキルの成熟に寄与する要因としてよく挙げられます。[13]ソースコードを表現力豊かな芸術的媒体と考える人もいます。[14]

ソースコードには、コンパイラが無視するようにマークされたテキストブロックであるコメントが含まれることがよくあります。このコンテンツはプログラムロジックの一部ではなく、読者がプログラムを理解するのに役立つことを目的としています。 [15]

企業は、企業秘密とみなされるアルゴリズムを隠すために、ソースコードを秘密にしておくことがよくあります。独自の秘密ソースコードとアルゴリズムは、刑事司法などの機密性の高い政府アプリケーションに広く使用されており、アルゴリズムの手法に関する透明性が欠如したブラックボックス的な動作につながっています。その結果、バイアスなどの問題に対する公的な監視を回避しています。[16]

修正

ソースコード（オブジェクトコードだけでなく）へのアクセスは、コードを変更する上で不可欠です。[17]既存のコードを理解することは、コードがどのように機能するかを理解するために必要であり[17]、コードを変更する前に必要です。[18]理解の速さは、コードベースとプログラマのスキルの両方に依存します。[19]経験豊富なプログラマは、コードが高レベルで何をするかを理解するのが容易です。[20] ソフトウェアの視覚化は、このプロセスを高速化するために時々使用されます。[21]

多くのソフトウェアプログラマーは、生産性を向上させるために統合開発環境（IDE）を使用しています。IDEには通常、よくあるエラーをプログラマーに警告するソースコードエディタなど、いくつかの機能が組み込まれています。 [22]変更には、多くの場合、コードのリファクタリング（機能を変えずに構造を改善すること）と再構築（構造と機能を同時に改善すること）が含まれます。[23]コードへのほぼすべての変更は、新たなバグや予期せぬ波及効果をもたらし、再度の修正が必要になります。[18]

他の開発者によるコードレビューは、プロジェクトに追加された新しいコードを精査するためによく使用されます。[24]このフェーズの目的は、コードがスタイルと保守性の基準を満たしていること、およびソフトウェア設計の正しい実装であることを確認することです。[25]いくつかの推定によると、コードレビューにより、ソフトウェアテストの完了後に残るバグの数が劇的に減少します。[24]コードを実行して機能するソフトウェアテストに加えて、静的プログラム解析では、自動化ツールを使用してソースコードの問題を検出します。多くの IDE はコード解析ツールをサポートしており、コードの明瞭さと保守性に関するメトリックを提供できる場合があります。[26] デバッガーは、多くの場合、プログラマが実行をステップ実行しながら、どのソースコードが各状態の変化に対応しているかを追跡できるようにするツールです。[27]

コンパイルと実行

高水準プログラミング言語のソースコードファイルは、命令を実行する前に、機械語への前処理段階を経る必要があります。 [7]コンパイルされたプログラムはオブジェクトファイルとして保存され、ローダー（オペレーティングシステムの一部）はこの保存されたファイルを読み込み、コンピュータハードウェア上のプロセスとして実行することができます。 [10]一部のプログラミング言語では、コンパイラではなくインタープリタが使用されます。インタープリタは実行時にプログラムを機械語に変換するため、コンパイルされたプログラミング言語に比べて10～100倍遅くなります。[22] [28]

携帯性

多くのプログラムが実行可能なバイナリ ファイルではなくソース コード形式で配布されるもう 1 つの理由は、多くの場合、単一のソース コード ファイルを一度記述すれば、さまざまなエンド ユーザー マシン (それぞれ独自のローカライズされたコンパイラまたはインタープリタを使用) で実行できることです。一方、実行可能コード ファイルは、一般にほぼ同一のマシンでしか動作しません。ソース コードは、Unix の歴史の初期にはこの方法で Unix オペレーティング システムを配布するために使用され、後にスクリプト言語(特にJavaScript クライアント側スクリプト言語) で記述されたプログラムをさまざまなマシンで実行できるようにするために使用されました。

この目的のために、縮小、難読化、または逆コンパイルされたソース コード ファイル (いずれも元のコード内のコメントを削除したもの) は、変更にはあまり役に立たないため、GNU 一般公衆利用許諾書バージョン 2 (GPL2) のソース コードの定義を満たしていないにもかかわらず、一般に元のソース コード ファイル (ほぼ常にコメントを含む) と同様に移植可能です。

品質

ソフトウェア品質とは、コードの正確性と効率性、再利用性と移植性、変更の容易さなどを指す包括的な用語です。[29]開発プロセスの後半で品質を追加するよりも、最初から製品に品質を組み込む方が通常は費用対効果が高くなります。[30]高品質のコードは、信頼性と保守性の向上により、サプライヤーと顧客の両方にとって生涯コストを削減します。[31] [32]

保守性とは、既存の機能を壊すことなくソフトウェアを容易に変更できる品質のことです。[33]目的に応じた明確な関数名や変数名を使用するなどのコーディング規約に従うことで、保守が容易になります。[34]条件付きループ文は、コードが複数回実行される場合にのみ使用し、実行されないコードを削除することでも、理解しやすさが向上します。 [35]多くのソフトウェア開発組織は、長期的なコスト増加につながるにもかかわらず、開発フェーズで保守性を無視しています。[32] 技術的負債は、プログラマーが怠惰や期限への焦りから、コードに保守性を組み込むのではなく、手抜きの解決策を選択することで発生します。[36]よくある原因は、ソフトウェア開発の労力見積もりを過小評価し、開発に割り当てられるリソースが不十分になることです。[37]保守性に関する課題は、多くのソフトウェアエンジニアリングのコースで保守性が重視されていないことです。[38]ソフトウェアの保守を担当しないことを知っている開発エンジニアには、保守性を組み込むインセンティブがありません。[18]

状況は世界各国で異なりますが、1974年以前のアメリカ合衆国では、ソフトウェアとそのソースコードは著作権の対象ではなく、常にパブリックドメインソフトウェアでした。[39] 1974年、米国著作物の新技術利用委員会（CONTU）は、「コンピュータプログラムは、著作者の独自の創作を具体化する限りにおいて、著作権の適切な対象である」と決定しました。[40] [41]

プロプライエタリソフトウェアがソースコードとして配布されることは稀である。[42]オープンソースソフトウェアという用語は文字通りソースコードへの公開アクセスを指すが、[43]オープンソースソフトウェアには追加の要件がある。それは、自由な再配布、ソースコードを変更して同じライセンスの下で派生作品をリリースする許可、そして商業的利用を含む異なる用途間の差別禁止である。[44] [45]オープンソースソフトウェアの自由な再利用性は開発を加速させることができる。 [46]

参照

参考文献

  1. ^ Kernighan, Brian W. 「C言語によるプログラミング：チュートリアル」（PDF）。ベル研究所、ニュージャージー州マレーヒル。2015年2月23日時点のオリジナル（PDF）からアーカイブ。
  2. ^ ガッブリエリ＆マルティーニ 2023、p. 519.
  3. ^ Gabbrielli & Martini 2023、520–521 ページ。
  4. ^ ガッブリエリ＆マルティーニ 2023、p. 522.
  5. ^ ガッブリエリ＆マルティーニ 2023、p. 521.
  6. ^ Tracy 2021、1ページより。
  7. ^ Tracy 2021、121ページより。
  8. ^ リンら。 2001 年、238 ～ 239 ページ。
  9. ^ カティアル 2019、1194頁。
  10. ^ Tracy 2021、122–123頁を参照。
  11. ^ O'Regan 2022、230–231、233、377。
  12. ^ フォスター2014、249、274、280、305頁。
  13. ^ abc Spinellis, D.: Code Reading: The Open Source Perspective . Addison-Wesley Professional, 2003. ISBN 0-201-79940-5
  14. ^ 「アートとコンピュータプログラミング」ONLamp.com、2018年2月20日アーカイブ、Wayback Machine、(2005)
  15. ^ カズマレクら。 2018、p. 68.
  16. ^ Katyal 2019、pp. 1186–1187。
  17. ^ ab Katyal 2019、p. 1195。
  18. ^ abc Offutt, Jeff (2018年1月). 「ソフトウェアのメンテナンスと進化の概要」.ジョージ・メイソン大学コンピュータサイエンス学部. 2024年5月5日閲覧。
  19. ^ Tripathy & Naik 2014、p. 296.
  20. ^ Tripathy & Naik 2014、p. 297.
  21. ^ Tripathy & Naik 2014、pp. 318–319。
  22. ^ O'Regan 2022、375ページより。
  23. ^ Tripathy & Naik 2014、p. 94.
  24. ^ ab Dooley 2017、p. 272を参照。
  25. ^ オレガン 2022年、18、21頁。
  26. ^ オレガン2022、133ページ。
  27. ^ カズマレクら。 2018、348–349ページ。
  28. ^ セベスタ 2012、28ページ。
  29. ^ ガリン2018、26頁。
  30. ^ オレガン2022、68、117頁。
  31. ^ オレガン 2022年、3頁、268頁。
  32. ^ Varga 2018、12ページより。
  33. ^ Varga 2018、5ページ。
  34. ^ Tripathy & Naik 2014、296–297 ページ。
  35. ^ Tripathy & Naik 2014、p. 309.
  36. ^ ヴァルガ 2018、6～7頁。
  37. ^ ヴァルガ 2018、7ページ。
  38. ^ ヴァルガ 2018、7～8頁。
  39. ^ Liu, Joseph P.; Dogan, Stacey L. (2005). 「著作権法と主題の特定性：コンピュータソフトウェアの事例」.ニューヨーク大学アメリカ法年次調査. 61 (2). 2021年6月25日時点のオリジナルよりアーカイブ。
  40. ^ Apple Computer, Inc. v. Franklin Computer Corporation Puts the Byte Back into Copyright Protection for Computer Programs Archived 7 May 2017 at the Wayback Machine in Golden Gate University Law Review Volume 14, Issue 2, Article 3 by Jan L. Nussbaum (Jan 1984)
  41. ^ Lemley、Menell、Merges、Samuelson著「ソフトウェアとインターネット法」 34ページ。
  42. ^ ボイル 2003、45ページ。
  43. ^ Morin et al. 2012、「オープンソースとクローズドソース」。
  44. ^ センら2008年209頁。
  45. ^ Morin et al. 2012、「フリーおよびオープンソースソフトウェア（FOSS）ライセンス」。
  46. ^ オレガン2022、106頁。

出典

  • アブロン、リリアン、ボガート、アンディ (2017). 『ゼロデイ、千の夜：ゼロデイ脆弱性とそのエクスプロイトの生涯と時代』（PDF） . ランド研究所. ISBN 978-0-8330-9761-3。
  • ボイル、ジェームズ（2003）「第二次囲い込み運動とパブリックドメインの構築」『法と現代問題』66 (1): 33-74 . ISSN  0023-9186.
  • キャンベル＝ケリー、マーティン、ガルシア＝シュワルツ、ダニエル・D. (2015). 『メインフレームからスマートフォンへ：国際コンピュータ産業の歴史』 ハーバード大学出版局. ISBN 978-0-674-28655-9。
  • ダスワニ、ニール、エルバヤディ（2021年）『大規模侵害：誰もが学ぶべきサイバーセキュリティの教訓』 Apress. ISBN 978-1-4842-6654-0。
  • ドゥーリー、ジョン・F. (2017). 『ソフトウェア開発、設計、コーディング：パターン、デバッグ、ユニットテスト、リファクタリング付き』 Apress. ISBN 978-1-4842-3153-1。
  • フォスター、エルビス・C. (2014).ソフトウェアエンジニアリング：方法論的アプローチ. Apress. ISBN 978-1-4842-0847-2。
  • ガブリエリ, マウリツィオ; マルティーニ, シモーネ (2023). 『プログラミング言語：原理とパラダイム』（第2版）. シュプリンガー. ISBN 978-3-031-34144-1。
  • ガリン、ダニエル（2018年）『ソフトウェア品質：概念と実践』ジョン・ワイリー・アンド・サンズ、ISBN 978-1-119-13449-7。
  • ハーバー、モリー・J.; ヒバート、ブラッド (2018). 『資産攻撃ベクトル：組織を守るための効果的な脆弱性管理戦略の構築』 Apress. ISBN 978-1-4842-3627-7。
  • カツマレク, ステファン; リース, ブラッド; ベネット, ゲイリー; フィッシャー, ミッチ (2018). 『Objective-C for Absolute Beginners: iPhone, iPad and Mac Programming Made Easy』 . Apress. ISBN 978-1-4842-3428-0。
  • Katyal, Sonia K. (2019). 「ソースコード秘密のパラドックス」Cornell Law Review . 104 : 1183.
  • キッチン、ロブ、ドッジ、マーティン (2011).コード/スペース：ソフトウェアと日常生活. MIT Press. ISBN 978-0-262-04248-2。
  • リン、ダニエル、サグ、ロナルド・S. ローリー (2001).「ソースコードとオブジェクトコード：オープンソースコミュニティにおける特許の影響」サンタクララ・コンピュータ＆ハイテクノロジー法律ジャーナル18 : 235.
  • モーリン, アンドリュー; アーバン, ジェニファー; スリス, ピオトル (2012). 「科学者プログラマーのためのソフトウェアライセンスクイックガイド」. PLOS Computational Biology . 8 (7) e1002598. Bibcode :2012PLSCB...8E2598M. doi : 10.1371/journal.pcbi.1002598 . ISSN  1553-7358. PMC 3406002.  PMID 22844236  .
  • オレガン、ジェラード（2022年）『ソフトウェアエンジニアリング簡潔ガイド：基礎から応用方法まで』シュプリンガー・ネイチャー、ISBN 978-3-031-07816-3。
  • Sen, Ravi; Subramaniam, Chandrasekar; Nelson, Matthew L. (2008). 「オープンソースソフトウェアライセンスの選択における決定要因」. Journal of Management Information Systems . 25 (3). Informa UK Limited: 207– 240. doi :10.2753/mis0742-1222250306. ISSN  0742-1222.
  • セベスタ, ロバート W. (2012). 『プログラミング言語の概念』（第10版）. アディソン・ウェスレー. ISBN 978-0-13-139531-2。
  • トレイシー、キム・W. (2021). 『ソフトウェア：技術史』 モーガン＆クレイプール出版社. ISBN 978-1-4503-8724-8。
  • トリパシー、プリヤダルシ。ナイク、クシラサーガル (2014)。ソフトウェアの進化とメンテナンス: 実践者のアプローチ。ジョン・ワイリー＆サンズ。ISBN 978-0-470-60341-3。
  • Varga, Ervin (2018). 『ソフトウェア保守と進化を解き明かす：既成概念にとらわれない思考』 Springer. ISBN 978-3-319-71303-8。
無料の辞書である Wiktionary でコード またはソース コードを調べます。
ウィキメディア コモンズには、ソース コードに関連するメディアがあります。