なるべくイメージする
ソフトウェア開発における整理
ソフトウェア開発に携わる中で、英語圏を由来とする技術用語が文脈ごとにどのような意味合いを帯びているのかを意識的に整理し頭へ定着させておくことが、各ドキュメントの読解における認知的負荷を減らし、設計や実装の判断を楽にしてくれるのではないかとふと思いました。
逐次補足・編集を行っていこうとは思います。
ライブラリ
「自分のソースコードの外部にあり、再利用のためにまとめられたコード」
必要な書籍（=ソース）を図書館（=library）から借りて使わせてもらう、といった感覚が先行する。
視点としては、自らの開発環境から外側に向けられているという印象が強いですね。
なお、借りてきたライブラリは、そのまま呼び出すことで機能を利用できるが、制御の主導権はこちらにあります。
使いたい関数をこちらから選び、呼び出すことで機能を組み込んでいく構造ですね。
モジュール
「ソースコード内部の構成要素（≒リポジトリ内の単位）」として用いられる、LEGO ブロックのような構成パーツ。
ラテン語の modulus（小さな尺度・単位）に由来し、ソフトウェア内における“機能のまとまり”を表す。
基本的には、開発対象となるリポジトリ内部に対する視点で語られることが多く、その設計方針や粒度の決定にはプロジェクトごとの個性が色濃く反映されると思います。
モジュールの切り方や分け方には、リポジトリごとの思想や判断基準が強く現れやすい、属リポジトリ性があると捉えていてもいいかもしれないですね。
プラグイン
プラグインとは、既存のコードに意図的に設けられた“拡張ポイント”に挿入される追加機能のこと。
「フックポイント」や「インターフェース」を通じてホストコードに接続される。
電源プラグを差し込むような直感的メタファーが思い浮かびやすいですが、プラグインが指すのは、ホスト側が明示的に開けておいた接続口に対して補完的あるいは追加的な振る舞いを注入するソフトウェア、あるいはその機能そのものを含む場合もある、のような言い方が腑に落ちる気がします。
ビルド
ソースコードは人間にとって可読性が高いように記述されているが、そのままではコンピュータにとって直接的に実行可能な形ではない。
そのため、コードを段階的にコンパイルやトランスパイルなどの処理を経て、中間形式やバイナリ形式へと変換していく必要がある。
この一連の変換・処理工程を総称して「ビルド」と呼ぶらしいですね。機械ってバイナリしか分からないの辛いですね。自然言語と切り離す上では一番綺麗な形だとは思いますが。
フレームワーク
フレームワークとは、特定のアーキテクチャに基づいて構築されたソフトウェアの土台であり、その枠組みに沿って開発を進めることで、一定の設計方針や実装スタイルが保証される。
「枠を使わせてもらう」という語感通り、自由度がある程度制限される代わりに、整った設計、パターン、効率性が担保される。
重要なのは、ライブラリとは異なり、フレームワークの側が主導的にコードを呼び出すという点にある。
こちらが呼び出すのではなく、「決まった場所にフックしておけば、フレームワーク側が適切なタイミングで実行してくれる」といった構造が基本。
ランタイム
ソースコードを実行する際に必要となる実行環境や基盤システムのことであり、プログラムが書かれた言語仕様に則って、実際の計算資源上でコードを走らせる責任を持つ層を指す。
単に「実行されている最中の時間帯（実行時）」を意味する文脈もあるが、ここでは実行時に介在するソフトウェア的インフラの意味合いが中心となる。
タイムというのにはおかしいなと思ったんですけど、コンパイルタイムという概念と区別する概念を表した言葉だったことも関係してるっぽいですね。
API（Application Programming Interface）
API とは、ソフトウェア同士が連携・通信するために公開された接点＝インターフェースである。
人間にとっての UI（ユーザーインターフェース）が操作の窓口であるのと同様に、プログラムにとっての API は、内部の実装を意識せずとも必要な機能にアクセスするための入口として機能する。
API の本質は、「こうした命令をこの形式で送れば、このような応答が返ってくる」という操作契約にある。API は、“どのように使うか”だけを明示し、“その内部で何が行われているか”は利用者に対して隠蔽されている。実装を抽象化し、信頼可能な操作面だけを外部に提示する構造こそが、API の中核的な役割である。
※補足
「インターフェース」とは、一般にソフトウェア開発において表面のみを対象とし、その裏側の実装とは切り離して議論する概念的な境界です。
UI における見た目や操作感が重要視されるように、中身を意識せずに接触・操作できる対象として扱われやすいという性質に通じている。視覚的には「テクスチャー」が指すイメージであったり、触覚的には物理的プロダクトのインターフェースにも通ずるものがあるとは思います。
なお、関数もまた一種の API とみなすことができますし、より抽象度を高めれば、複数の関数やリソースを束ねたサービス単位やプロトコルレベルの設計もまた API に含まれます。 API は、単なる機能の窓口ではなく、「外部とどのように対話するか」を体系的に設計する枠組みと捉えた方が直感的かもしれないですね。
Discussion