認知負荷

開発者がコードを理解・変更するために必要な精神的な労力の量

設計チーム

認知負荷とは

認知負荷 (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 行以上は流し読みになりレビュー品質が低下する。

認知負荷を扱う関連書籍も多い。

関連用語