# 拡大する開発者向け宣言、「スタイル上の教条ではなく認知負荷をソフトウェア設計の指針にすべき」
NeoTechNews編集部
発生日である2025年8月30日、`cognitive-load`と題されたGitHubプロジェクトが、率直な命題によって注目を集めていた。ソフトウェア設計に関する助言の大半は、コードベース内で安全に作業するために必要な思考量を減らせるかどうかによって評価すべきだというものだ。[16134]
この文書は自らを2026年6月まで更新された生きた文書と説明し、多くのベストプラクティスが失敗するのは、コードを読み保守する実際の経験ではなく、美学、スローガン、主観的な好みによって動かされているからだと主張している。[16134] 代わりに据える構成原理は認知負荷、すなわちタスクを完了するために開発者が作業記憶に保持しなければならない情報量である。[16134]
情報源は、この考えを基礎付けるため、人間に関する単純な制約を用いている。平均的な人は作業記憶におよそ4つの情報のまとまりを保持でき、コードの理解がその限界を超えると、理解することがはるかに難しくなるという。[16134] つまり、ソフトウェア品質は正確さや優雅さだけの問題ではない。変更を加える前に、開発者が一時的な心理状態をどれほど再構築しなければならないかも問題となる。
この文書は、内在的負荷と外在的負荷を区別している。内在的負荷は問題そのものから生じ、設計によって取り除くことはできない。外在的負荷はコードの構成方法や提示方法によって加わるもので、多くの場合、大幅に減らすことができる。[16134] このリポジトリはほぼ全面的に後者へ焦点を当て、保守性に関する負債の中でも最も具体的な形態の一つとして扱っている。
その例は意図的に実用性を重視している。推奨事項の一つは、意味のある名前を持つ中間変数を導入し、開発者が前提条件を頭の中でやりくりするのではなく、正常系に集中できるようにすることだ。[16134] もう一つは、継承よりコンポジションを優先することである。深い継承チェーンでは、読者が一つの変更について推論できるようになるまでに、複数のクラスをたどって挙動を組み立てなければならないからだ。[16134]
しかし、最も強い主張は、浅いモジュールの過剰生産に反対するものだ。この文書は、単純なインターフェースを公開しながら複雑な実装を隠す「深い」モジュールと、実際の処理内容に比してインターフェースが不釣り合いに複雑な「浅い」モジュールを対比している。[16134] 浅いコンポーネントが多すぎると、開発者は各モジュールの役割だけでなく、それらすべての相互作用も追跡しなければならないため、プロジェクトの把握が難しくなると著者は主張する。[16134]
この点を説明するため、情報源は規模が同程度の二つの個人プロジェクトを比較している。一方には浅いクラスが80個あり、理解するために大量の文脈的知識を再構築する必要があったため、長い中断後に作業へ戻るのが困難になった。もう一方には深いクラスが7個しかなく、作業を再開するのがはるかに容易だった。[16134] リポジトリによれば、これは巨大な「ゴッドオブジェクト」を推奨する議論ではなく、複雑さを形式的な手続きとして外部へ押し出すのではなく、内部に隠すコンポーネントを支持する議論である。[16134]
この捉え方は、単一責任の原則に関する一般的な解釈への批判にもつながる。この文書によると、開発者はしばしば「一つの責任」を「一つのごく小さなこと」と取り違え、その名前やインターフェースが実装以上に精神的負担となる抽象化を生み出している。[16134] 代わりに著者は、責任を恣意的なサイズ制限ではなく、ステークホルダーやユーザーのニーズと結び付けている。[16134]
このリポジトリの人気は、多くの開発者がそこで説明されている問題を認識していることを示唆する。フレームワークの複雑化が進み、AI生成コードが大量に生み出される時代には、読むコストが書くコストよりもさらに重要になり得る。[16134] チームが時間の大半を既存システムの理解に費やすのであれば、理解の負担を増やす設計ルールには、より厳しい基準が課されるべきだ。
提供された証拠は、このプロジェクトの主張を明確に要約する内容を裏付けている。優れたソフトウェア設計とは、次に作業する人の不要な精神的負担を減らすものである。[16134] これは多くのアーキテクチャー理論ほど華やかではないが、まさにそれが、この議論が支持を集めている理由なのかもしれない。
