『プリンシプルオブプログラミング』用語集

A

AOP（アスペクト指向プログラミング） A

Aspect-Oriented Programming

ログや認証など複数の場所にまたがる共通処理を「アスペクト」としてまとめて注入する設計・実装のスタイル。

アサーション A

Assertion

アサートによってチェックされる「こうであるべき」という条件そのものを指す言葉。テストコードでもよく使われる。

アサート A

Assert

常に成り立つべき条件をコード中で確認するための命令。条件が崩れたら即座にエラーにして、バグに早く気づけるようにする。

アノテーション A

Annotation

コードに付ける小さな注釈。フレームワークなどが読み取り、設定やバリデーション、追加処理などを自動で行うために使われる。

アーキテクチャ A

Architecture

システム全体の大まかな構造や部品の分け方、どのように連携させるかを決める設計の考え方。

詳しく見る

抽象度 A

Abstraction

具体的な細部を隠し、共通する考え方や性質に注目して表現すること。高すぎても低すぎても分かりにくくなる。

B

ビルド B

Build

ソースコードをコンパイルしたりまとめたりして、実行可能なアプリケーションや配布物の形に変換する処理。

C

CI（継続的インテグレーション） C

Continuous Integration

開発者の変更をこまめに統合し、自動ビルドと自動テストを回して問題に早めに気づけるようにする開発のやり方。

CLI C

Command Line Interface

Command Line Interface の略で、キーボードからコマンドを打って操作するインターフェース。慣れると繰り返し作業を素早く行える。

凝集度（Cohesion） C

Cohesion

1つのモジュールやクラスの中には、同じ目的に関わる処理だけを集めて、役割をはっきりさせようとする指標。

詳しく見る

結合度（Coupling） C

Coupling

モジュールどうしがどれくらい強くつながっているかを表す指標で、弱くつながっているほど変更やテストが楽になる。

詳しく見る

D

DIP（依存性逆転の原則） D

Dependency Inversion Principle

具体的なクラスではなくインターフェースなどの抽象に依存させて、仕組みを差し替えやすくする設計原則。

DI（依存性注入） D

Dependency Injection

クラスが自分で new せず、必要なオブジェクトを外から受け取ることで、差し替えやテストをしやすくする設計のやり方。

DRY（重複の排除） D

Don't Repeat Yourself

同じ意味の処理や知識をあちこちにコピペせず、1か所にまとめて管理しようとする設計の考え方。

DSL（ドメイン固有言語） D

Domain-Specific Language

特定の分野の問題を簡潔に表現するために作られた専用の言語。設定ファイルやビルドスクリプトなどでよく使われる。

デプロイ D

Deployment

ビルドした成果物をサーバーやストアなど本番やテスト環境に配置し、ユーザーが使える状態にする作業。

ドメイン D

Domain

ソフトウェアが扱う業務や問題の世界のこと。ユーザーやビジネスのルールを表すモデルの範囲を指す。

詳しく見る

依存 D

Dependency

あるコードが別のコードに頼って動く関係のこと。依存が多すぎたり強すぎると変更やテストが難しくなる。

宣言型 D

Declarative Style

何をどう実行するかではなく「どんな状態になってほしいか」を記述する書き方。SQL や CSS のように結果を宣言して任せる。

死蔵コード D

Dead Code

もう使われていないのに、実際には呼ばれずに残り続けているコード。読み手を混乱させ、誤使用やバグの原因にもなりやすい。

設計 D

Design

決めた要件をもとに、画面や処理の流れ、データの形などソフトウェアの作りを具体的な形に落とし込む工程。

駆動 D

Driven

テスト駆動やイベント駆動のように、何かをきっかけにして設計や処理の流れを決めるという意味合いで使われる言葉。

E

カプセル化 E

Encapsulation

データとそれを扱う操作を1つにまとめ、外から直接いじらせずメソッド経由で扱わせて安全にする考え方。

F

フェールセーフ F

Fail-safe

障害や誤操作が起きたときに、人やシステムにとってより安全な状態になるように設計しておく考え方。

フェールソフト F

Fail-soft

障害が起きても機能を一部だけ制限し、性能を落としながらも最低限のサービスを続けるようにする振る舞い。

フォールトトレランス F

Fault Tolerance

一部で故障やエラーが起きても、全体としてはサービスを継続できるように設計しておく考え方。

フレームワーク F

Framework

アプリ開発の土台となる共通機能と枠組み。決められた場所にコードを書くことで基本的な処理が手に入る。

フールプルーフ F

Fool-proof

ユーザーがうっかり間違った操作をしても重大な問題になりにくいように、そもそも誤操作しづらく設計しておく工夫。

関数 F

Function

入力を受け取り結果を返す、小さな処理のまとまり。名前を付けて再利用でき、副作用が少ないほど理解しやすくなる。

G

グルー G

Glue Code

本体の部品どうしや外部システムをつなぐためだけに書かれる橋渡し用のコード。増えすぎると構造が分かりにくくなる。

H

フック H

Hook

処理の途中で外部のコードを挟み込めるよう用意された「引っかけるポイント」。イベントや拡張でよく使われる。

ヘルスチェック H

Health Check

アプリやサーバーが生きているかを外から定期的に確認する仕組み。ロードバランサが異常なサーバーを外すときなどに使う。

I

IoC（制御の反転） I

Inversion of Control

処理の流れの主導権をアプリ側ではなくフレームワークなどに持たせ、必要な部分だけ自分のコードを書く考え方。

インターフェース I

Interface

部品どうしがどんなメソッドでやり取りするかを決める「窓口」の定義。中身を隠して差し替えやすくする。

J

JSON J

JSON

データをキーと値の組み合わせで表すテキスト形式。人間にも読みやすく、多くの Web API や設定ファイルで標準的に使われている。

K

KISS（シンプルに保つ） K

Keep It Simple, Stupid

必要なことだけをシンプルに実装し、余計な仕組みや複雑さを足さないようにする設計の考え方。

カーネル K

Kernel

OSの中核となる部分で、CPUやメモリ、ディスクなどのハードウェア資源を管理し、アプリからの要求を仲立ちする。心臓部にあたる存在。

L

LOC L

LOC (Lines of Code)

Line of Code の略で、ソースコードの行数を表す指標。規模の目安にはなるが、多ければ良い・少なければ良いとは限らない。

ライブラリ化 L

Library-ization

よく使う機能を1つのライブラリとしてまとめ、他のプロジェクトから簡単に再利用できるようにすること。

レイヤー L

Layer

システムを役割ごとの層に分けて積み重ねる考え方。表示、業務ロジック、データアクセスなどを分けやすくする。

疎結合 L

Loose Coupling

モジュール同士ができるだけ少ない情報だけでつながる状態。お互いの変更の影響を小さくできる。

詳しく見る

M

メカニズム M

Mechanism

仕組みの具体的な動き方や実現方法のこと。何をするかを決めるポリシーと分けて考えると整理しやすい。

メトリクス M

Metrics

レスポンスタイムやエラー率、CPU使用率など、システムの状態や品質を数字として継続的に計測・監視するための指標。

モジュール M

Module

関連する処理やデータをひとまとまりにした単位。クラスやファイル、パッケージなどがモジュールに当たる。

保守 M

Maintenance

運用中のシステムに対して、バグ修正や性能改善、仕様変更への対応などを行い、使い続けられるようにする活動。

O

OCP（オープン・クローズドの原則） O

Open-Closed Principle

新しい振る舞いを追加しやすくしつつ、既存コードの変更はできるだけ少なくしようとするオブジェクト指向の設計原則。

OSS O

Open Source Software

Open Source Software の略。ソースコードが公開され、誰でも閲覧・改良・再配布できるライセンスのソフトウェアを指す。

運用 O

Operations

リリースしたシステムを日々監視し、ジョブ実行や設定変更、問い合わせ対応などを行って安定して動かし続けること。

P

POSIX P

POSIX

UNIX系OSでプログラムが同じように動くように決めた標準仕様。POSIX対応にしておくと、別のUNIX系環境に移植しやすくなる。

プラガブル P

Pluggable

プラグインのように部品をあとから差し替えたり追加したりできる設計になっている状態を指す言葉。

プラグイン P

Plugin

本体のソフトにあとから追加して機能を拡張できる小さなモジュール。オンオフや追加がしやすい形で作られる。

プログラミング P

Programming

設計どおりにコンピュータが動くよう、プログラミング言語を使ってソースコードを書いたり修正したりする作業。

プロダクト P

Product

ユーザーに価値を届ける製品やサービス全体のことで、ソフト本体だけでなく周辺の仕組みや体験も含めて指す。

ポリシー P

Policy

「何をしたいか」という方針やルールのこと。メカニズムが「どう実行するか」を担当するのと対になる考え方。

手続き P

Procedure

値を返すことよりも、一連の処理を順番に実行することに意味がある関数。画面更新やファイル書き込みなどに使われる。

驚き最小の原則 P

Principle of Least Surprise

利用者が「そう動くだろう」と自然に予想できる挙動にそろえ、思わぬ動きで驚かせないように設計しようという原則。

R

RB R

RB (tool / technique)

Review Board など、コードレビューや開発ツール名の略称として使われることが多い略語。文脈によって意味が変わる。

リファクタリング R

Refactoring

外から見た振る舞いは変えずに、コードの構造や名前付けを整理して読みやすく、変更しやすくする改善作業。

詳しく見る

ロバストネス R

Robustness

予期しない入力や多少の負荷変動でも簡単には落ちず、安定して動き続けられる強さを指す言葉。

ロールバック R

Rollback

障害や不具合が出たときに、データやシステムの状態を直前の正常なバージョンまで戻す操作や仕組み。

冗長化 R

Redundancy

サーバーや回線などを複数用意し、どれかが故障しても残りで動かせるようにする設計。止まりにくいシステムを作るための工夫。

要件定義 R

Requirements Definition

システムで何を実現したいかを整理し、必要な機能や条件を言葉でまとめて関係者で合意する作業。

S

SLAP（単一抽象化レベルの原則） S

Single Level of Abstraction Principle

1つの関数の中では同じ抽象度のことだけを書くようにし、細かい処理は別の関数に分けようとする考え方。

SRP（単一責任原則） S

Single Responsibility Principle

クラスや関数には1つの役割だけを持たせ、変更の理由ができるだけ1種類になるように分けて設計しようという原則。

サービスロケータ（アンチパターン） S

Service Locator

必要なオブジェクトを共有窓口から取得する仕組みだが、依存関係が見えにくくなりテストしづらくなりがちなパターン。

シェル S

Shell

ユーザーがOSに命令するための窓口となるプログラム。コマンドを入力して実行したり、スクリプトで処理を自動化したりできる。

シグネチャ S

Signature

関数名・引数・戻り値の型など、その関数がどのように呼ばれるかを表す情報。関数の「名刺」にあたる部分。

スキーマ S

Schema

データの項目名や型、制約など、データの構造を決めた設計図。データベースやJSONの定義などで使われる。

ストレステスト S

Stress Test

通常より重い負荷や長時間の利用をかけて、システムがどこまで耐えられるかや、限界付近でどう振る舞うかを確認するテスト。

T

テスト T

Testing

作ったソフトが期待どおりに動くかを確認する工程で、バグを見つけて修正し、品質や安心感を高めるために行う。

テンプレート化 T

Templating

似た構造の処理や文書をひな形として切り出し、差分だけを埋めて再利用しやすくすること。

トレース T

Trace

リクエストがどのサービスや処理を通ったかをたどれるようにする情報。分散システムでの原因調査に役立つ。

U

UNIX U

UNIX

昔から使われているOSの一族で、シンプルな仕組みと小さなコマンドを組み合わせる思想が特徴。LinuxやmacOSの元になった文化的な基盤。

V

verbose V

Verbose

ログやメッセージを詳しく大量に出すモード。デバッグには便利だが、普段はノイズになるため切り替えて使うのが一般的。

Y

YAGNI（今は要らない） Y

You Aren't Gonna Need It

将来使うかもしれない機能を今から作らず、本当に必要になったときにだけ追加しようとする考え方。