# 認知負荷を論じるエッセー、精神的な摩擦を減らすソフトウェア設計を主張
minds.mdに掲載され、2024-12-22にHacker Newsへ投稿された新たなエッセーは、ソフトウェアの品質は流行の用語よりも、もっと基本的な尺度によって評価されるべきだと論じている。すなわち、コードが何をしているのかを理解するために、開発者がどれだけの精神的労力を必要とするかという尺度だ。筆者の前提は単純である。変更によってプログラマーが一度にあまりに多くの事実を頭に留めておかざるを得なくなるなら、その設計は作業を必要以上に難しくしている。
この記事は、この考え方を「認知負荷」と位置付けている。心理学から借用した用語だが、ここでは実践的な工学上の意味で使われている。その用法では、問われるのはコードが洗練されて見えるか、あるいは広く使われている経験則に従っているかではない。問われるのは、そのコードが、作業を完了するために伴う混乱を最小限に抑えているかどうかだ。筆者は、混乱は時間と費用を浪費するため、それを減らすことを設計の中心的な目標にすべきだと論じている。
エッセーは、よく知られた一連の例を使って要点を示している。コントローラーと継承階層を連ねた構造を、より少数で深いコンポーネントから成る単純なシステムと対比している。筆者の説明では、開発者が調べなければならない階層が一つ増えるごとに精神的な負担が増し、特にプロジェクトが長期間手つかずだった場合にその傾向が強まる。これに対し、単純なインターフェースを持つ少数のモジュールなら、数カ月離れた後でも作業を再開しやすい場合がある。
エッセーのより辛辣な主張の一つは、一部のソフトウェアに関する助言が単純化されすぎているというものだ。短いメソッドや多数の小さなクラスを本質的に良いものと見なすのではなく、可能な限り複雑さを隠し、利用者が必要とするものだけを公開すべきだと筆者は論じる。これは、古くからある「小さく保て」という助言をよりきめ細かくしたものだ。小さな断片によって読者が頭の中でシステムを組み立てざるを得なくなるのであれば、あらゆるものを小さくすべきではない。
この投稿は、この考え方をAI時代にも結び付けている。開発者は今後、モデルが生成したコードを確認する必要がますます増えるため、不必要な複雑さに対して一層注意を払うべきだという。例自体はなじみ深いものだとしても、それによってこの主張は時宜にかなったものとなっている。その根底にあるメッセージは、明快なソフトウェアは保守しやすいだけでなく、信頼もしやすいということだ。
このエッセーの最大の貢献は、抽象化を捉え直す方法にある。抽象化を漠然とした美徳として扱うのではなく、そのインターフェースによって読者がより少ない精神的労力でより多くのことを行えるかを問う。この視点は、読者が新しいシステムを設計している場合にも、古いシステムを整理しようとしている場合にも有用だ。
主張の整理
提供された抜粋は、このエッセーが認知負荷を、コードを読む際に開発者が感じる混乱の量として定義し、単純なインターフェースを備えた深いモジュールを提唱するとともに、不必要で浅い抽象化がソフトウェア保守の精神的コストを増大させると警告している、という主張を裏付けている。
