認知負荷
開発者がコードを理解・変更するために必要な精神的な労力の量
設計チーム
認知負荷とは
認知負荷 (Cognitive Load) は、開発者がコードを理解・変更するために必要な精神的な労力の量である。認知負荷が高いコードは、バグが生まれやすく、変更に時間がかかり、新メンバーのオンボーディングが遅くなる。
3 種類の認知負荷
| 種類 | 説明 | 例 |
|---|---|---|
| 内在的 (Intrinsic) | 問題自体の複雑さ | 分散トランザクション、暗号化 |
| 外在的 (Extraneous) | 不要な複雑さ | 悪い命名、過度な抽象化 |
| 学習的 (Germane) | 理解を深める負荷 | 新しいパターンの学習 |
外在的認知負荷を最小化し、内在的認知負荷に集中できる環境を作ることが目標。
認知負荷が高いコードの特徴
// ❌ 認知負荷が高い: 何をしているか分からない
const r = d.filter(x => x.s === 'A' && x.t > Date.now() - 86400000)
.reduce((a, c) => ({...a, [c.g]: [...(a[c.g] || []), c]}), {});
// ✅ 認知負荷が低い: 読めば分かる
const activeItems = data.filter(item =>
item.status === 'active' && item.timestamp > oneDayAgo
);
const groupedByCategory = groupBy(activeItems, 'category');
認知負荷を下げる方法
明確な命名 (変数名・関数名から意図が分かる)、小さな関数 (1 つの関数が 1 つのことだけ行う)、早期リターン (ネストを浅く保つ)、型による制約 (TypeScript の型で不正な状態を防ぐ)、コロケーション (関連するコードを近くに配置) が効果的。
Team Topologies と認知負荷
Team Topologies (Matthew Skelton, Manuel Pais) では、チームの認知負荷を設計の制約として扱う。
❌ 1 チームが巨大なモノリスを担当 → 認知負荷が限界を超える
✅ チームごとに独立したサービスを担当 → 認知負荷が管理可能
チームが担当するサービスの数と複雑さを、チームの認知負荷の上限内に収める。
マイクロサービスと認知負荷
モノリスはコードベース全体の理解が必要。マイクロサービスは個々のサービスは小さいが、サービス間の連携が複雑になる。モジュラーモノリスはモジュール境界で認知負荷を分割しつつ、運用は単純に保てる。
コードレビューでの認知負荷
PR が大きいとレビュアーの認知負荷が高くなり、バグを見逃す。200 行以下なら集中してレビューでき品質が高い。200〜400 行は中程度。400 行以上は流し読みになりレビュー品質が低下する。
認知負荷を扱う関連書籍も多い。