プログラマー脳の書評｜コードが読めないのは能力不足じゃないと分かった

プログラミングと認知科学という組み合わせが気になって、単純な興味で読んだのが『プログラマー脳』です。

結論から言うと、コードが読めなかったり、覚えたはずの書き方を忘れたりして、自分の力不足だと感じている人に合う1冊です。読めない・覚えられないことには、頭の働き方から説明できる理由があると分かります。

いちばん役に立ったのは、第1章の「3つの認知プロセスと3つの混乱」の話でした。読んでから、コードの読み方と、覚え方を変えています。

プログラマー脳はどんな本か

書誌情報と章の内容は、紀伊國屋書店のページに載っている出版社内容情報によるものです（定価は書店の掲載価格）。著者はオランダのライデン大学の准教授で、プログラミング教育を研究している人です。コード例はJavaScript、Python、Javaなどで出てきますが、特定の言語の知識は必要ないとされています。

全13章が、4つの部に分かれています。

読む・考える・書くそれぞれで、頭のどの働きを使っているのかを説明し、それに合ったやり方を紹介する作りです。最後の部では、新しい開発者を迎えるオンボーディングも扱っています。

読んだきっかけ｜単純な興味

役に立ったところ｜3つの認知プロセスと3つの混乱

いちばん役に立ったのは、第1章です。出版社内容情報では、第1章は「プログラミングを行う際に重要な3つの認知プロセスと、それぞれの認知プロセスがどのような混乱と関連するか」の章とされています。

原書のManningの公式ページで見られる第1章の見出しでは、混乱の種類として「知識の不足」「情報の不足」「処理能力の不足」の3つ、認知プロセスとして「長期記憶（LTM）」「短期記憶（STM）」「ワーキングメモリ」の3つが挙げられています。

Javaのコードで言うと、たとえばこうです（説明用の例）。

// 1. 知識が足りない：書き方そのものを知らない
Map<Rank, List<Member>> byRank =
    members.stream().collect(Collectors.groupingBy(Member::rank));

// 2. 情報が足りない：中身が別の場所にあって、ここからは見えない
int fee = feePolicy.apply(order);   // apply の中で何をしている？

// 3. 処理する力が足りない：一度に頭に置くことが多すぎる
if (a > 0 && (b < limit || flag) && !(c == null || c.isEmpty()) && retry < max) {
    ...
}

どれも「読めない」ですが、原因が違います。1つ目は書き方を知れば解決し、2つ目は定義を見に行けば解決し、3つ目は条件を分けて名前を付ければ楽になります。

読んでから変えたこと｜読めない理由を切り分ける・繰り返し思い出す

1. 読めないのを、能力不足だと思わなくなった

読んでから、コードが読めないことを、自分の能力不足だと思わなくなりました。読めないときは、3つの混乱のどれなのかを切り分けるようにしています。

「なんとなく分からない」のままだと、どこから手を付ければいいか決まりません。種類が分かれば、調べるのか、見に行くのか、書き出すのかが決まります。

2. 覚えたいことは、繰り返し思い出すようにした

もう1つは、覚えたいことを繰り返し思い出すようにしたことです。原書の第3章の見出しには、フラッシュカードで構文を覚える方法、忘れないための「間隔反復（spaced repetition）」、「情報を見るだけでは不十分」「思い出すことで記憶が強くなる」といった節が並んでいます。

出版社内容情報でも、第3章は「プログラミングの構文や概念をよりよく、より簡単にきちんと学ぶ方法」の章とされています。新しい書き方を覚えるときに、答えを見る前に一度思い出してみる。それだけでも、同じことを何度も検索することが減ります。

ほかに読みどころになる3つの話

刺さったのは第1章ですが、目次を見ると、ほかにも実務ですぐ使える話が並んでいます。原書の見出しをもとに3つ紹介します。

複雑なコードは、頭の外に書き出して読む（第4章）

原書の第4章の見出しには、ワーキングメモリがいっぱいになったときの助けとして、依存関係のグラフ（dependency graph）と状態表（state table）を作る方法が挙がっています。状態表は、ループの中で変数がどう変わるかを、表に書きながら追う方法です。たとえばこんなコードなら（説明用の例）、

int total = 0;
for (int i = 1; i <= 3; i++) {
    total = total * 2 + i;
}

頭の中で追う代わりに、1回ずつ書き出します。

ループ   i   total（計算）
開始前   -   0
1回目    1   0 * 2 + 1 = 1
2回目    2   1 * 2 + 2 = 4
3回目    3   4 * 2 + 3 = 11

3つの混乱のうち「処理能力の不足」への対処で、頭に置いておく量を紙やエディタに逃がす考え方です。

名前の良し悪しは、バグの数にも関わる（第8章）

第8章の見出しには、名前の書式は短期記憶を助ける、分かりやすい名前は長期記憶を助ける、「悪い名前のコードはバグが多い」、そして名前の型（name molds）といった節があります。名前の付け方を、好みではなく、読む人の頭の負担とバグの話として説明しているのが特徴です。

名前と中身が食い違うと、混乱が増える（第9章）

第9章の見出しには、コードの臭いが認知的な負荷を生む理由と、「言語的アンチパターン（linguistic antipatterns）」の節があります。言語的アンチパターンは、名前から想像する動きと、実際の動きが食い違っている状態のことです。

// 名前と中身が食い違っている（説明用の例）
public boolean isValid(Order order) {
    order.setCheckedAt(LocalDateTime.now());   // 「確かめるだけ」に見えて、状態を書き換えている
    return order.total() > 0;
}

public List<Member> getMember(MemberId id) { ... }   // 単数形の名前なのに、リストが返る

名前を信じて読むと間違え、中身を確かめに行くと情報の不足になる。名前の付け方は良いコード／悪いコードで学ぶ設計入門の書評でも書いています。

今のレベル別の読み方

4つの部に分かれているので、今の自分の困りごとに合わせて読む部を決めやすい本です。

向いている人・向いていない人

• 向いている人：コードが読めない・覚えられないことを、自分の力不足だと感じている人。プログラミングの学び方そのものを良くしたい人
• 向いていない人：特定の言語やフレームワークの使い方を知りたい人。この本は、頭の働き方から読み方・覚え方を考える本です

出版社内容情報では、すべてのレベルのプログラマー向けとしつつ、特に職業プログラマーが直面する状況を取り上げている、とされています。

あわせて読みたい

• 良いコード／悪いコードで学ぶ設計入門の書評：読む人の負担が少ない名前と構造の作り方
• ドメイン駆動設計入門の書評：業務の言葉をコードの名前にする考え方
• 単体テストの考え方/使い方の書評：コードの意図をテストで残す

読んだ本はほかにも、トムの本棚に並べています。

よくある質問

Q. 認知科学の知識がなくても読めますか？

読めます。出版社内容情報では、まず認知プロセスを説明してから、それぞれの場面でどんな方法を採るべきかを具体例で説明する、とされています。

Q. Javaの人でも役に立ちますか？

役に立ちます。コード例はJavaScript、Python、Javaなどで出てきますが、特定の言語の知識は必要ないとされています。

Q. 原書はありますか？

あります。Manningから2021年に出た「The Programmer's Brain」です。