Loading article…
コンピューティングにおいて、ソースコード、あるいは単にコードやソースとは、最終的にコンピュータの動作を制御することになる、人間が読める平文のことです。コンピュータを制御するには、コンピュータプログラムによって処理される必要があります。これは、インタプリタを介して直接実行されるか、コンパイラなどを介してコンピュータが処理しやすい形式に変換されるかのいずれかです。場合によっては、コードは直接マシンコードにコンパイルされ、それ以上の処理なしにコンピュータのネイティブ言語で実行できるようになります。しかし、多くの最新の環境では、バイトコードなどの中間表現にコンパイルされ、インタプリタを介して実行されるか、ジャストインタイムコンパイルによってオンデマンドでマシンコードにコンパイルされます。
1940年代末に登場した最初のプログラム可能なコンピュータ[ 2 ]は、機械語（プロセッサが直接実行できる単純な命令）でプログラムされていました。機械語はデバッグが難しく、異なるコンピュータ システム間で移植できませんでした。 [ 3 ]当初、ハードウェア リソースは希少で高価でしたが、人的資源は安価でした。[ 4 ]プログラムが複雑になるにつれて、プログラマの生産性がボトルネックになりました。これが、1950年代半ばにFortranなどの高水準プログラミング言語が導入されるきっかけとなりました。これらの言語はハードウェアの詳細を抽象化し、人間がより簡単に理解できるアルゴリズムを表現するように設計されました。[ 5 ] [ 6 ]したがって、ソフトウェアは基盤となるコンピュータ ハードウェアとは異なる命令であるため、比較的新しく、Fortran、 Lisp、Cobolなどの初期の高水準プログラミング言語に遡ります。[ 6 ]高水準プログラミング言語の発明は、ソース コードをコンピュータ ハードウェアで直接実行できる機械語に自動的に変換するために必要なコンパイラと同時期でした。 [ 7 ]
ソースコードの定義の中には、人間が直接変更するコード形式、通常は高水準プログラミング言語で記述されるコードとみなすものもある。[ 8 ]
オブジェクトコードはマシンによって直接実行でき、多くの場合、中間ステップであるアセンブリ言語を介してソースコードから自動的に生成されます。オブジェクトコードは特定のプラットフォームでのみ動作しますが、ソースコードは別のマシンに移植してそこで再コンパイルできます。同じソースコードでも、オブジェクトコードはコンパイル対象のマシンだけでなく、コンパイラのパフォーマンス最適化によっても大きく異なる場合があります。[ 9 ] [ 10 ]
ほとんどのプログラムは、実行に必要なすべてのリソースを内蔵しておらず、外部ライブラリに依存しています。コンパイラの機能の一部は、プログラムをハードウェアで実行できるようにこれらのファイルをリンクすることです。[ 11 ]
ソフトウェア開発者は、ソースコードファイルの変更を追跡するために構成管理（バージョン管理）をよく使用します。構成管理システムは、どのオブジェクトコードファイルがどのバージョンのソースコードファイルに対応しているかも追跡します。[ 12 ]
ソースコード行数（SLOC）は、コンピュータプログラマの生産性、コードベースの経済的価値、開発中のプロジェクトの工数見積もり、リリース後のソフトウェア保守の継続コストを評価する際の指標としてよく使用されます。[ 13 ]
ソースコードは、オンラインや書籍にあるコードスニペットのように、関係者間でアルゴリズムを伝達するためにも使用されます。[ 14 ]
コンピュータプログラマーは、既存のソースコードを確認することでプログラミング技術を学ぶのに役立つことがあります。[ 14 ]開発者間でソースコードを共有することは、プログラミングスキルの成熟に貢献する要因としてよく挙げられます。[ 14 ]ソースコードを表現力豊かな芸術媒体と考える人もいます。[ 15 ]
ソースコードには、コンパイラが無視するようにマークされたテキストブロックであるコメントが含まれていることがよくあります。この内容はプログラムのロジックの一部ではなく、読者がプログラムを理解するのに役立つことを目的としています。 [ 16 ]
企業は、企業秘密とみなされるアルゴリズムを隠すために、ソースコードを非公開にすることがよくあります。独自の秘密のソースコードとアルゴリズムは、刑事司法などの機密性の高い政府アプリケーションで広く使用されており、アルゴリズムの方法論の透明性が欠如したブラックボックス動作を引き起こします。その結果、バイアスなどの問題に対する公の監視が回避されます。[ 17 ]
ソースコード（オブジェクトコードだけでなく）へのアクセスは、コードを修正するために不可欠です。[ 18 ]既存のコードを理解することは、その動作を理解するために必要です。 [ 18 ]また、修正する前に理解する必要があります。 [ 19 ]理解の速度は、コードベースとプログラマーのスキルの両方に依存します。[ 20 ]経験豊富なプログラマーは、コードが何をしているかを高レベルで理解するのが容易です。[ 21 ]ソフトウェアの視覚化は、このプロセスを高速化するために使用されることがあります。[ 22 ]
多くのソフトウェアプログラマーは、生産性を向上させるために統合開発環境（IDE）を使用します。IDEには通常、プログラマーに一般的なエラーを警告できるソースコードエディタなど、いくつかの機能が組み込まれています。 [ 23 ]変更には、コードのリファクタリング（機能を変更せずに構造を改善すること）と再構築（構造と機能を同時に改善すること）が含まれることがよくあります。[ 24 ]コードへのほぼすべての変更は、新しいバグや予期しない波及効果をもたらし、修正のラウンドがさらに必要になります。[ 19 ]
他の開発者によるコードレビューは、プロジェクトに追加された新しいコードを精査するためによく使用されます。[ 25 ]このフェーズの目的は、コードがスタイルと保守性の標準を満たしていること、およびソフトウェア設計の正しい実装であることを検証することです。[ 26 ]一部の推定によると、コードレビューは、ソフトウェアテストが完了した後に残るバグの数を劇的に減らします。[ 25 ]コードを実行することで機能するソフトウェアテストに加えて、静的プログラム分析は、自動化されたツールを使用してソースコードの問題を検出します。多くのIDEはコード分析ツールをサポートしており、コードの明確さと保守性に関する指標を提供する場合があります。[ 27 ]デバッガは、プログラマが実行をステップ実行しながら、各状態の変化に対応するソースコードを追跡できるようにするツールです。[ 28 ]
高水準プログラミング言語のソースコードファイルは、命令を実行する前に、機械語への前処理段階を経る必要があります。 [ 7 ]コンパイル後、プログラムはオブジェクトファイルとして保存でき、ローダー（オペレーティングシステムの一部）はこの保存されたファイルを取得して、コンピュータハードウェア上でプロセスとして実行できます。 [ 11 ]プログラミング言語の中には、コンパイラの代わりにインタプリタを使用するものがあります。インタプリタは実行時にプログラムを機械語に変換するため、コンパイルされたプログラミング言語よりも10～100倍遅くなります。[ 23 ] [ 29 ]
多くのプログラムが実行可能なバイナリファイルではなくソースコード形式で配布されるもう一つの理由は、（多くの場合）単一のソースコードファイルを一度作成すれば、さまざまなエンドユーザーのマシン（それぞれに独自のローカライズされたコンパイラまたはインタプリタが備わっている）で実行できるのに対し、実行可能なコードファイルは一般的にほぼ同じマシンでしか動作しないためです。ソースコードは、Unixの歴史の初期にUnixオペレーティングシステムを配布するためにこの方法で使用され、その後、スクリプト言語（特にJavaScriptクライアントサイドスクリプト言語）で書かれたプログラムをさまざまなマシンで実行できるようにするために使用されました。
この目的のために、ミニファイ、難読化、または逆コンパイルされたソースコードファイル（いずれも元のコードのコメントを削除したもの）は、元のソースコードファイル（ほぼ常にコメントが含まれている）とほぼ同じくらい移植性がありますが、変更にははるかに不向きであり、したがってGNU一般公衆ライセンスバージョン2（GPL2）のソースコードの定義を満たしていません。
ソフトウェア品質は、コードの正しい効率的な動作、再利用性と移植性、または変更の容易さを指す包括的な用語です。 [ 30 ]通常、開発プロセスの後半で品質を追加しようとするよりも、最初から製品に品質を組み込む方が費用対効果が高いです。[ 31 ]高品質のコードは、信頼性と保守性の向上により、サプライヤーと顧客の両方にとってライフサイクルコストを削減します。[ 32 ] [ 33 ]
保守性とは、既存の機能を壊すことなくソフトウェアを容易に変更できるソフトウェアの品質のことです。[ 34 ]明確な関数名や変数名をその目的に合わせて使用するなど、コーディング規約に従うことで保守が容易になります。[ 35 ]条件付きループ文は、コードが複数回実行される可能性がある場合にのみ使用し、決して実行されないコードを削除することも、理解度を高めるのに役立ちます。 [ 36 ]多くのソフトウェア開発組織は、長期的なコストが増加するにもかかわらず、開発フェーズで保守性を軽視しています。[ 33 ]技術的負債は、プログラマが、多くの場合怠惰や締め切りに間に合わせるための緊急性から、保守性をコードに組み込むのではなく、手っ取り早く粗雑な解決策を選択した場合に発生します。[ 37 ]一般的な原因は、ソフトウェア開発の労力見積もりの過小評価であり、開発に割り当てられるリソースが不十分になることです。[ 38 ]保守性に関する課題は、多くのソフトウェアエンジニアリングコースで保守性が重視されていないことです。[ 39 ]ソフトウェアの保守を担当しないことを知っている開発エンジニアは、保守性を組み込むインセンティブがありません。[ 19 ]
状況は世界各地で異なりますが、1974 年以前の米国では、ソフトウェアとそのソースコードは著作権の対象ではなく、常にパブリック ドメイン ソフトウェアでした。[ 40 ] 1974 年、米国著作権作品の新技術利用委員会 ( CONTU ) は、「コンピュータ プログラムは、著作者の独創的な創作物を具現化している限り、著作権の適切な対象である」と決定しました。[ 41 ] [ 42 ]
独自ソフトウェアはソースコードとして配布されることは稀である。[ 43 ]オープンソースソフトウェアという用語は文字通りソースコードへの公開アクセスを指すが、[ 44 ]オープンソースソフトウェアには追加の要件がある。すなわち、自由な再配布、ソースコードの変更および派生作品を同じライセンスの下でリリースする許可、商用利用を含むさまざまな利用に対する非差別である。[ 45 ] [ 46 ]オープンソースソフトウェアの自由な再利用性は開発を加速させることができる。 [ 47 ]