ryokatsu.devプログラマー脳を読んだ
タイトルに惹かれて買いました。ジャンルでいうと「達人プログラマー」的な本ではありそうですが、「コードを書くときにSOLID原則を意識しろ！」みたいな感じではなく「コードを読むとき、書く時に具体的に人間の脳で何が起こっていて、どういう処理をしているのか」に着目している本でした。全章通して学びが多かったのですが、その中でもいくつか気になった箇所について読書感想文として紹介します。
どうやって記憶が管理されているか（プログラミングって難しい）
本書の一番最初の部分です。ここだけでも本書を読んだ価値が十分にあると感じました。そしてプログラミングというのは非常に複雑でクリエイティブな作業だと感じます。
長期記憶
コードを読む際に、例えばTypeScriptで
function test<T>(arg: T): T {
return arg;
}とあった場合にTが、何をしているのかが分からない場合は「知識不足」で長期記憶に関する情報が少ないとされています。
短期記憶
コードリーディング中にとあるメソッドを発見したけど、このメソッドが具体的に何をしているのかがすぐに分からない場合は「情報不足」で短期記憶に関する問題とされています。短期記憶は一時的に保持される場所では、ありますがたくさんの異なる事柄を探索している際に、以前に保存していた情報を忘れてしまう場合もあります。
ワーキングメモリ
コードリーディング中に出てくる定数や変数、処理の内容が複雑だと、混乱することがあります。「処理能力の不足」でワーキングメモリが不足していることが原因です。
こう見ると、プログラミングというのは、とても大変な作業だということがわかります。これらの記憶装置を理解した上で、長期記憶にしっかり定着させるための方法とし、「間隔をあけて思い出す」というのがありました。勉強した学びとか知見などは、まず短期記憶に入りますが、正直すぐに忘れます。
これは業務でもよくあることで「何だこのコード汚いな。。誰が書いたんだ？ 1ヶ月前のオレやんけ！！」ってことありませんか？自分はあります。ただ完全に忘れているわけでもなくワーキングメモリがうまく覚えているケースもあって、以前覚えた情報をインプットすると短期記憶のフィルタを通して強く記憶に残ることがあり、このとき長期記憶に記憶されます。つまり「長期記憶」「短期記憶」「ワーキングメモリ」はそれぞれ補完し合っていることがわかります。
ここで以下のような言葉がありました。
人はただ言葉や事実だけを記憶するのではなく、自分の記憶や信念に合うように記憶を修正している
正しく事実を記憶しているつもりが自分が良いように解釈して、記憶することで誤った記憶になるケースもあります。これは結構危険ですね。。
フラッシュカード
本書は、優れたプログラマーになるためにコードの読み方と書き方について認知科学に基づいて書かれていますが、度々「フラッシュカード」という言葉が出ます。言ってしまえばこれが優れたプログラマーに、なるための解決策だと僕は本書を読んで感じました。
フラッシュカードは、いわゆる英単語を暗記するための「単語帳」のようなものです。フラッシュカードにシンタックスや、デザインパターン、Tipsとかを書いていきます。そしてそのフラッシュカードを使って先程の長期記憶に保存するために、定期的に繰り返し練習することで長期記憶からすぐに取り出してプログラミングに取り組むことができます。
なんかこう書いてしまうと、「中学とか高校でやってたやつじゃん。。なんでやっていないんだろ」という気持ちになりました。本書でも基礎的な練習は必要と論文の紹介を交えて書かれていました。
反復練習
ランニングだったり、音楽で運指を訓練するみたいなことがありますが、プログラミング界隈ではあまりないということも書かれていました。（100回forループを書いて身につけるといった文化圏ではない）ここで重要な様々なスタイル（デザインパターン）での書き方を訓練するのが大事ということでした。for文でも、正順、逆順、ステップ数の異なるステッパー変数を使う書き方などを訓練すると良いとのことでした。これは確かにそうで、自分も様々なコードのスタイルを見て書いてみて覚えてきた経験があります。
またキーボードショートカットとかを自動化していくのも優れたプログラマーになるためには重要とありました。余計な脳のメモリを使わないためにも必須ですね。
メンタルモデル
実際に手を動かさなくてもできる作業のこととして紹介されていました。ある事柄だったり部分的なことについてを抽象的な形として捉えることですかね。プログラマー的にいうとクラスとかでしょうか。一度メンタルモデルにしてしまうと、人間が扱いやすい形になっているので、ワーキングメモリへの負荷が減らせます。
しかしここで「古い記憶は長期記憶から消えることがない」ということが書かれており、例えばなんでしょう、あるメンタルモデルの内容を更新して長期記憶に入れたはずなのに、認知負荷が高い状態だとアップデートしたメンタルモデルを参照せず、古いメンタルモデルを参照することがあり。この時読み間違えが起こってしまいます。具体的なコードレベルでたくさんクラスを作ってあることがいい状態かというと微妙そうですが、コードを読むための助けにはなってくれそうです。
2つ目のプログラミング言語の学び方
一度学んだ知識が他でも生かされることを、「知識の転移」と紹介されていました。人は、新しい情報に遭遇すると感覚記憶から短期記憶に移行してワーキングメモリに入力され、ワーキングメモリが活性化されて長期記憶も活性化されて検索を始めます。その検索でヒットして見つかることがあります。Haskellでmap()やfilter()とかを覚えていたらJavaScriptのmap,filterに関しては、そこまで苦労せずにというかほぼ苦労せずに覚えることができると思います。
しかし、この「知識の転移」実は、難しいことだと本書で紹介されていました。その例としてチェスの実験があったのですが、チェス自体は他の論理ゲームなどに転用することができないというのが実験の結果でした。更に一般的な知能、論理的推論力、記憶力が向上すると言ったことはないとのことでした。 演習としては、類似点、違い、気付きなどをマトリクスにしてそれぞれ考えるのがおすすめのようです。TypeScriptとHaskellで構文、型システムなどの違いをまとめると言った感じでしょうか。
割り込み
ここはエンジニアあるあるだと思いますが、コーディングに集中している最中に声を掛けられたり（今はリモートがほとんどなんであまりないかもですが）、Slackのメンションがきたりすると一気に集中力がなくなります。とある実験によると、割り込みがあってから再度コードを書き始めるにはおよそ15分掛かることがわかったそうです。プログラマーが1分以内に作業を再開できたケースは、わずか10%に過ぎないらしいです。。めっちゃわかるな〜と感じました。自分も割り込みされると、復帰するのに割と時間が掛かるというか、Slackをそのままダラダラ見てしまったりすることもあります。ポモドーロをすれば良いかも知れませんが、それでも割り込み自体はなくならないので、割り込みされる前にコメントを記載しておくなどをしてこまめに記録しておくと再開する時間が早くなるかも知れませんが。中々面倒ですね。。
オンボーディング
読み方/書き方とは違った箇所で、新人のプログラマーに対してどう接するかが書かれていました。以下に注意して取り組んでいくと良さそうな内容でした。
- 新人さんが新しくジョインしたときに、シニアエンジニアが、一度にたくさんの情報を伝えると新人さんの認知負荷が高くなるのでやめる
- シニアエンジニア目線で、小さなバグ改修、小さな機能開発だと思ったissueは実は、新人さんからすると簡単なissueではない可能性があるのでちゃんと認識合わせする
まとめ
全体的にとても読みやすく、最初から順番に読んでいくストーリー仕立てな所もあって面白く読めました。フラッシュカードについては、ちょっとやってみたいなと思いました。拡張させてカードゲームみたいにできたらより面白いかも知れません。
他にも、可読性の話だったり、意味波の話も書こうかなと思ったのですが、以下のzennの感想ブログに詳しく丁寧に書かれていたのでそちらを読んでいただけると良いのかなと思いました。