コードベースとは？わかりやすく解説

コードベース（英: codebase）は、ソフトウェア開発では、特定のソフトウェアシステム、アプリケーション、ソフトウェアコンポーネントなどを構築するために使用されるソースコードの集まりのこと。通常、コードベースには人間が作成したソースコードファイルのみが含まれ、ツールによって生成されたソースコードファイル（生成されたファイル）またはバイナリライブラリファイル（オブジェクトファイル）は含まれない。これらは人間が作成したソースコードから構築できるためである。構成ファイルとプロパティファイルはビルドに必要なデータであるため、コードベースに含まれる。

コードベースは通常、バージョン管理システムのソース管理リポジトリに保存される。小規模なプロジェクトの場合は、単純なファイルの集まりとして保持される場合がある（Linuxカーネルでさえ長年にわたってファイルの集まりとして維持されていた）^[1]。ソースコードリポジトリは、公的または私的に大量のソースコードが保管される場所であり、バックアップとバージョン管理に使用され、複数人の開発者によるプロジェクトでは、さまざまなソースコードバージョンを処理し、開発者が重複する変更を送信することで発生する競合を解決するのに役立つ。 Subversion、Git、Mercurialは、このワークフローを処理するために使用される一般的なツールの例であり、オープンソースプロジェクトでも一般的である。

明確でモノリシックなコードベース

複数のプロジェクトは、個別の別個のコードベースを持つことも、単一の共有またはモノリシックコードベース持つこともできる。これは特に、同じ会社内で開発されたプロジェクトなどの関連プロジェクトに当てはまる。より詳細には、モノリシックコードベースは通常、単一のリポジトリ（すべてのコードを1か所にまとめたもの）と、多くの場合、共通のビルドシステムまたは共通のライブラリが用意される。コードベースが共有されているか分割されているかは、システムアーキテクチャと実際のビルド結果に依存しない。したがって、実際の開発に関連するモノリシックコードベースは、ソフトウェアアーキテクチャまたは単一のモノリシックバイナリに関連するモノリシックシステムを必要としない。その結果、モノリシックコードベースは、単一のシステムまたは単一のバイナリのみを伝送するのではなく、（大規模なコードベースの場合）個別のコンポーネントで構成される場合がある。分散コードベース（複数のコンポーネントを含む）を利用すると、単一のモノリシックシステムまたは単一のバイナリを構築できる。たとえば、Linuxカーネルは、アーキテクチャ的には単一のモノリシックカーネルだが、個別のバイナリ（ロード可能なコンポーネント）で構成され、複数の分散リポジトリで開発されている。

分散コードベースと比較した場合、モノリシックコードベースには長所と短所の両方がある^[2]^[3]。最も単純には、モノリシックコードベースは統合が簡単である。異なる構成要素に対する変更やコンポーネント間のコードのリファクタリングを容易かつアトミックに行うことができる。そして全体のコードベースを横断した操作が可能であるが、より大きなリポジトリが必要となる。

個別のコードベースまたは分散コードベースは、個々のリポジトリをより小さく、より管理しやすくし、コンポーネント間の分離が可能になる。一方、コードベース間の統合（またはメインリポジトリとの統合）が必要になり、複数のコードベースにまたがる変更を複雑にする^[4]。

標準に関して、複数のコードベースが「別個」であるとは、ソースコードの共有がない独立した実装であり、歴史的に、これらの実装は共通のプロジェクトから発展しなかったことを意味する特定の標準を実装する2つの独立したソフトウェアにより、相互運用性を実証することができる。

例

特に大きなコードベースには、次のものがある。

Google: モノリシック、10億ファイル、900万ソースコードファイル、20億行のソースコード、合計3,500万コミット、合計サイズ86TB（2015年1月）^[5]
Facebook: モノリシック、8GB（履歴を含むレポ54 GB、2014）、^[6]数十万のファイル（2014） ^[3]
Linuxカーネル: 分散、^[7] 1,500万行を超えるコード（ 2013年現在^[update]およびカーネルバージョン3.10）

脚注

^ “A Short History of Git”. git-scm.com. 2014年10月21日閲覧。
^ J. David Morgenthaler; Misha Gridnev; Raluca Sauciuc; Sanjay Bhansali (2012). "Searching for Build Debt: Experiences Managing Technical Debt at Google". Proceedings of the Third International Workshop on Managing Technical Debt. IEEE. pp. 1–6.http://research.google.com/pubs/archive/37755.pdf (PDF)
^ ^a ^b “Scaling Mercurial at Facebook”. Facebook Code (2014年1月7日). 2016年4月29日閲覧。
^ “Git - Distributed Workflows”. git-scm.com. 2016年4月29日閲覧。
^ Potvin, Rachel; Levenberg, Josh (24 June 2016). “Why Google stores billions of lines of code in a single repository”. Communications of the ACM 59 (7): 78–87. doi:10.1145/2854146.
^ @feross (2014年4月24日). "Facebook's git repo is 54 GB". X（旧Twitter）より2016年4月29日閲覧。
^ Sproull, Lee; Moon, Jae Yun (2000-11-05). “Essence of distributed work: The case of the Linux kernel - Moon - First Monday”. First Monday 5 (11) 2016年4月29日閲覧。.

[1] “A Short History of Git”. git-scm.com. 2014年10月21日閲覧。

[googledebt-2] J. David Morgenthaler; Misha Gridnev; Raluca Sauciuc; Sanjay Bhansali (2012). "Searching for Build Debt: Experiences Managing Technical Debt at Google". Proceedings of the Third International Workshop on Managing Technical Debt. IEEE. pp. 1–6.http://research.google.com/pubs/archive/37755.pdf (PDF)

[facebookmercurial-3] “Scaling Mercurial at Facebook”. Facebook Code (2014年1月7日). 2016年4月29日閲覧。

[4] “Git - Distributed Workflows”. git-scm.com. 2016年4月29日閲覧。

[5] Potvin, Rachel; Levenberg, Josh (24 June 2016). “Why Google stores billions of lines of code in a single repository”. Communications of the ACM 59 (7): 78–87. doi:10.1145/2854146.

[6] @feross (2014年4月24日). "Facebook's git repo is 54 GB". X（旧Twitter）より2016年4月29日閲覧。

[7] Sproull, Lee; Moon, Jae Yun (2000-11-05). “Essence of distributed work: The case of the Linux kernel - Moon - First Monday”. First Monday 5 (11) 2016年4月29日閲覧。.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

コードベースとは？わかりやすく解説