【書評】脳に収まるコードの書き方とは結局、何なのか

オライリーから発売された「脳に収まるコードの書き方」という書籍を読了しました。
発売されるまで全く情報をキャッチできていなかったのですが、自分の近辺でこの書籍を購入している方がちらほらといて、特に内容・目次を精査することもなくノリで買ってしまいました。

僕はオライリーから発行される書籍の表紙に描かれる生き物が何なのか毎回、ワクワクしているのですが、この書籍では葬送のフリーレンに登場する防御魔法のようなヘックスが描かれています。まさかこれが書籍の内容を象徴するものだったとは...(後に分かります)

ネタバレ: 脳に収まるコードって何

コンピューターと人間の脳の違い

まずは、本書のタイトルの一部にある「脳に収まるコード」がどんなコードなのかを追っていきたいと思います。
その前置きとして、コンピューターと人間の脳の違いについて本書では紹介があります。コンピューターは膨大な情報を正確に記憶装置(RAM, HDDなど)へ記録して読み取ることができますが、複雑な思考・判断をすることができません。一方で我々、人間の脳は複雑な思考・判断をしたり、意思決定をすることができますが、膨大な情報を正確に記憶することを苦手としています。

さらに人間の記憶には短期記憶と長期記憶というものがあるそうです。
目の前に現れた情報は短期記憶として扱われた後、何かしらのきっかけによって脳が重要だと判断した情報は、短期記憶から長期記憶になることで長い間、脳に記憶され続けることになります。コンピューターでは高速な読み書きが可能なメモリ、大容量だが読み書きが低速なストレージに分かれているのが一般的なアーキテクチャですが、これが脳を模倣したものなのかは分かりません。詳しい方がいたら教えてください。

コードを読んでいる時、情報はどう扱われているのか

前置きが長くなりましたが、人間がコードを読む時、情報はどのように扱われているのでしょうか。
コードに登場する情報には変数名、関数の引数・戻り値、型...などがありますが、それらはまずは短期記憶として記憶されます。その後、全体的なアーキテクチャ、頻出するパターンやなどは、先ほど記述したように段々と長期記憶になることがありますが、ほとんどの情報は短期記憶として役目を終えていくとのことです。

となると、変数名などの情報が多く短期記憶に記録されていればコードをスムーズに読むことができそうですが、残念ながら人間の短期記憶の容量は非常に小さく、おおよそ7つのことまでしか覚えられないと言われています。心理学の分野ではマジカルナンバー7という言葉があります。

マジカルナンバーとは、人間が瞬間的に保持できる情報の数は「7±2」であるとするもの。
アメリカのハーバード大学の心理学者、ジョージ・ミラー教授（George Armitage Miller）による1956年の論文「The Magical number seven, plus or minus two」で登場

マジカルナンバー7±2（ミラーの法則）とは意味/解説 - シマウマ用語集

ここでタイトルを回収したいと思います。
つまり「脳に収まるコード」とは7つまでの情報に集約されたコードのことを指していました。
どこまでを情報としてカウントアップするのかについて正確な定義はありませんでしたが、自分は関心事の数という理解をしています。例えば、以下のサンプルコードは情報が5つなので、脳に収まるコードだと判断することができます。

// 動作しない適当なコードです
fun main(args: Array<String>) {
    val cofigures = Configure.getConfig() // 1.設定の取得
    val middlewares = Middleware.getMiddlewares() // 2.ミドルウェア一覧の取得
    val routing = Router.getRouter() // 3.ルーターの取得
    
    // 4.サーバー情報の設定
    val server = Server(
      configure = configure,
      middlewares = middlewares,
      routing = routing,
      protocol = 'https',
    )

    // 5.サーバーの起動
    server.run(port = 8080)
}

書籍の表紙にあったヘックスの数が7個だったと気づいた方はいるでしょうか。
これは本書ではヘックスフラワーと呼ばれており、コードが持つ情報を以下のように書き込むことで脳に収まるコードかを判断するために使用されていました。

多くの章ではどのようにしてコードの情報を減らす・集約・分割する...というテクニックが紹介されています。
主にテスト駆動開発やAAA(Arrange・Act・Assert)、カプセル化、KISSの原則など...。よく周知されたテクニックだったので、自分目線では目新しいものはありませんでしたが、これらのテクニックを上手く使って脳に過負荷を与えないようにコードが変化していく過程が面白く学びがありました。

なぜ脳にコードを収めたいのか

ケント・ベック著の「実践パターン」という書籍でも触れられているように「コードは書いている時間よりも読んでいる時間の方が圧倒的に多い」です。本書は実践パターンに影響を受けている印象があり「コードは読んでいる時間の方が多い」という視点で、コードの可読性が組織の開発パフォーマンスに大きく影響を与えることを指摘しています。

さらにコードは負債であり、開発年月が長くなればなるほど持続可能性が低下していきます。
これは自分の経験上からも間違いなくて、いつの間にか知らない機能のモジュールが追加されていたり、関数の引数が爆発的に増えていたりと日々、コードは複雑になり、変更することが難しくなっていきます。そのために「脳に収まるコードを保ち続けなければならない」という主張があり、サイクロマティック複雑度やリファクタリング、CI/CDによる継続的デリバリーなどの文脈の話が登場してきます。

PS. 残念ながら「実践パターン」はすでに絶版となっているようで、Amazonでは15,000円近い値段となっており入手するのが難しい状況です。たまたま市立の図書館においてあったので、僕は読むことができました。図書館マジでオススメです。

勝手に対象読者

先ほども書いたように「真新しいトピックは正直ない」というのが自分の感想です。
偉大な先人達によって生み出されてきたテクニック、ツールやプロセスに対してリスペクトを送りつつ「脳に収まるコードかどうか」という筆者オリジナルを視点を加えて情報を集約したという印象でした。しかし、先ほども書いたように実際にテクニックを駆使して、脳に過負荷を与えないようにコードを変化させていく過程が秀逸であり、凄腕プログラマーの実装の過程を覗き見ることができる一冊という感じです。

何か新しい開発方法やコーディングのテクニックを求めている方にはもっと良い書籍があるでしょう。
開発の経験を積んできた方が今までのやり方はどうだったんだろうかと振り返り、再発見するために読んでみるというのが良さそうです。