読んだ本

プログラマー脳～優れたプログラマーになるための認知科学に基づくアプローチ

Description: 長年プログラミング教育の研究に取り組んでいる著者が、最新の「認知科学」に基づいて、プログラミングの際のさまざまな作業や技術の取得を効率的に行うための方法を解説しています。

選定理由

話題になってたから ← めっちゃ大事
認知科学に基づくとか元研究者心をくすぐるお題だったから
プログラミングをしているときに自分が考えていることが妥当なのか確かめられそうと思ったから

ここで話すネタ

紹介したいのは以下。

プログラマは結局コードを読む時間のほうが長い
素早く読むには長期記憶、短期記憶、ワーキングメモリを上手く活用する必要がある
個人的に刺さったポイント

詳細な解説は本書を買って読んでほしい。

この本をおすすめする人はある程度コードを書いたり読んだりしたことがある方はなるほどって思うことは多い。

一方でコーディング経験がほぼない人は要約をいくつか読んでコードリーディングしてから読むほうが学びが多いと思う。

プログラマは結局コードを読む時間のほうが長い

一般的にプログラマーと呼ばれるポジションの人種は一生コードを書いていると思われるが圧倒的にコードを読む時間のほうが長い。

プログラマーの時間のほぼ60%はコードを書くよりも理解することに費やされているらしい。

（実際にプログラマーをやってる人もコード書いてるのを仕事と話すこともあるから改めて書いておく）

なので読む時間を効率よくできるようにしてコードを書くことが必要。

読むことを意識してコードを書きましょう。以上！と片付けても楽しくないのでここからはもうちょっと掘り下げてみる。

素早く読むには長期記憶、短期記憶、ワーキングメモリを上手く活用する必要がある

人がコードを読むとはどういうことか。

例えば「数値nを与えられて二進数表現するプログラム」を考えてみる。（本と同じコード書いています）

APLを使った表現だと以下。

2 2 2 2 2 T n

APLの文法を知らない人はTの意味がわからなかったりそもそも2が何を示すかなど知識不足によってわからなくなる。

public class BinaryCaluculator {
    public static void mian(Integer n) {
        System.out.println(Interger.toBinaryString(n));
    }
}

メソッドの名前から機能の推測はできそうだがtoBinaryStringが具体何をしているか情報が不足していてわからなくなる。

LET N2 = ABS (INT (N) )
LET B$ = ""
FOR N1 = N2 TO 0 STEP 0
    LET N2 = INT (N1 / 2)
    LET B$ = STR$ (n1 - N2 * 2) + B$
    LET N1 = N2
NEXT N1
PRINT B$
RETURN

ここは処理内容こそ（読める人にとっては）わかりやすいが変数が変わり続けるためわからなくなる。

このようにわからなくなることを大別すると

知識不足 = 長期記憶
情報不足 = 短期記憶
処理能力の不足 = ワーキングメモリ

の足りなさによる。

読むために工夫できること

逆を言うようで恐縮だが

知識不足を解消する
情報不足を解消する
処理能力の不足を解消する

知識不足を解消する

これは勉強し続けるしかない。for文ってこう書くよね、dict使うとこんなことできるよね、みたいな。

半分経験値。

情報不足を解消する

処理能力の不足を解消するもたぶん同じ。

大事なのは2つ

チャンク化

コードを読み進めるときにわからなくなるのは最初から細かいところまで読みすぎな場合がある。

その場合にはチャンク（意味的な塊）を意識して抽象度を上げるとよい。メンタルモデルがあるだけで理解のスピードは格段に上がる。

構造的に考えるのはコーディングについても効果的。

長期記憶で予測する

単語帳を使って概念だったりシンタックスや、デザインパターン、Tipsとかを書いて覚えるのが有効と書いてあった。

経験値ゲーな感じもする。

一方で予測しすぎはそれはそれで良くない。
（ちなみにさっきのjavaの関数名がmianとtypoしてたの気付いた？）

個人的に刺さったポイント

2つめの言語を習得する

Pythonに慣れていたら上のJavaのコードもある程度は理解できる（forとかifとかほぼ同じ）、知識を転用して概念をマッピングすると良さそう。

だが万能ではない。（Python知っててもSQLと文法構造やできることが異なると転用できない場合もある）

割り込みへの対処

集中してて話しかけられたりSlackで連絡来て目を話すと再開までに平均して15分くらいかかるらしい。（やっぱりね）

これが1日に4回あると1時間、、、

軽減するためになんとかメモを残したりしましょう。（Todoコメントが溢れない程度に）

オンボーディング

シニアとジュニアは経験値が違いすぎるので教育は特に注意しましょねー。

シニアメンバーはジュニアに一気に教えて認知的負荷を高めてしまうことが多い。（超自戒）

シニアが簡単/単純だと思ったことでもジュニアにとってはそうとも限らないので認識合わせましょう。

人間の脳的にわかりやすさ vs 体系化されたわかりやすさ

コードって関数をまとめたり、責務を十分に軽くするのが良いとされている。

一方で読むときには一行一行書いてあった方がコードジャンプしなくて良くなって上から下にに読めるからわかりやすくない？(と思っていたことが正直ある。)

がここも経験値がある場合はデザインパターンなどの共通認識から開発チーム全体の生産性を上げるために一般的に良いコードとされているものを書くべし。

まとめ

結局のところ経験値が物を言うと思う。

その経験値を効率よく上げていくために脳科学からアプローチして積み上げるのがよいのでは。