「プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ」という書籍を読みました。
普段やっていることや考えていることに具体的な名前や研究結果があることを知ったり、自分の行動の中であまりよくなさそうな習慣を認識できたりと、とても学びが多かったです。
この記事では、この書籍で特に印象に残ったことおよびそこから感じたことをメモとして記録しておこうと思います。
余談ですが、原著のタイトルは「The Programmer's Brain: What every programmer needs to know about cognition」となっており、個人的には日本語のサブタイトルの方が要旨を捉えていると感じました。
プログラミングに関する知識は「検索」するのではなく「記憶」した方がいい
マジカルナンバーと一般に呼ばれる、記憶可能な情報量に関する制約が短期記憶にはあります(※具体的な数については諸説ありますが)。
郵便番号や電話番号のハイフン区切りのように、羅列された情報からいくつかの塊を作ることで記憶可能な情報量を増やすチャンク化によって、ある程度この制約を克服できることも有名です。この手法はデザインやマーケティングの世界でよく使われています。
プログラミングの観点では、プログラミングに関する知識を長期記憶に増やすことでより多くのコードをチャンク化しやすくし、短期記憶で記憶すべき情報量を減らすことが重要になります。
この書籍を読む前の私の考えとしては、プログラミングの文法で覚えづらいものについては都度検索すれば十分だと思っていたのですが、何らかの割り込みが発生した後に再度コードを書き始めるには約15分かかるという研究結果も記載されており、プログラミングに関する知識は「検索」するのではなくできる限り「記憶」した方がいい、と考えを改めました。
長期記憶に保存された情報を思い出せないとき、その情報は消えているのではなく検索できなくなっている
情報の強度には貯蔵強度と検索強度という2種類があるそうです。
- 貯蔵強度
- 情報が長期記憶にどの程度きちんと保持されているかを示す
- その内容を勉強すればするほど、その記憶は強くなる
- 検索強度
- 情報を長期記憶から取得することがどの程度簡単かを示す
- 年月が経つにつれて検索強度は低下する
- 他の記憶と関連する記憶では、検索強度は高くなる
またこの書籍によると、長期記憶に記憶した情報は消えることはないそうです。
このことから、長期記憶を活用するには長期記憶に情報を保存するだけでは不十分で、その情報を簡単に取得できるように訓練する必要があることが分かります。
受験勉強のときに覚えた英単語を思った以上に覚えていることに自分でも驚いた日があったのですが、当時は接頭辞・接尾辞をベースに英単語を勉強していたので「接頭辞・接尾辞で関連付けて記憶していたから、今でも意外とスラスラ出てくるのかもしれない」と納得感がありました。
「仕様が難しい」にも複数の意味合いがありそう
認知的負荷には課題内在性負荷と課題外在性負荷の2種類があるそうです(書籍では学習関連負荷というものも紹介されていましたが、少し毛色が違うので割愛します)。
- 課題内在性負荷
- その問題自体がどのくらい複雑か
- 読み手がすでに持っている知識に依存しない
- 課題外在性負荷
- その問題の妨げとなる外部要因がどのくらい複雑か
- 読み手がすでに持っている知識によって異なる
これを読んで、例えば「仕様が難しい」と言ったときに、仕様そのものが本当に複雑なのか、もしくは話者の前提知識が不足していて複雑に見えているだけなのかが変わるなーと思い、個人的には面白い発見でした。
認知的リファクタリング、最高
認知的負荷を軽減する方法の一つとして、読みやすさ・理解しやすさを向上するために一時的にコードをリファクタリングする認知的リファクタリングという言葉が紹介されていました。
「リーダブルコード」を読んだときに学んだ説明変数や要約変数が個人的に好きで、普段からよく使っているのですが、それに通ずるものがあると感じました。
複雑なコードに出会ったとき、自分が理解しやすいように作業ブランチでこういう修正をすることが認知的負荷の観点で有効なことを知れてよかったです。
命名に悩んだらひと晩寝かせる
コーディングは基本的に認知的負荷が高いため、それと並行して適切な名前を考えるという作業は実はかなり難しいものだと再認識しました。
私自身はコードレビューで命名についてコメントすることも結構多いのですが、第三者視点から識別子名の品質について考えることは自分が思っていたよりも意味のあることかもしれないと考えられるようになりました。
また、自分自身で命名を行うときは、コーディングと命名を切り離して行うくらいの気持ちで、ひと晩寝かせてから考えるのもよさそうだと思いました🍛
オンボーディングタスクとしてドキュメント作成は効果的
オンボーディングすることもしてもらうことも何度かありましたが、自分自身の経験としてはドキュメントよりも実際のコードを先に読み始めて、トライ＆エラーで少しずつプロダクトについての理解を深めることが多かった気がします。
そもそもプロダクトやコードに関して包括的に理解できるドキュメントが整備されていること自体が稀かもしれないとは思いつつ、ドキュメントを書く理解だけに集中したタスクを与えることで新メンバー自身の短期記憶の認知的負荷が減り、コードに関する重要なことを記憶するための余裕が生まれるので、とてもよいタスクだと思いました。
また、これによりドキュメント文化が醸成され、未来の新メンバーのオンボーディングのときにも役に立つようになれば理想的だと感じました。
以上です。個人的にはすごく興味深い内容だったので、これをきっかけに認知科学への理解を深めていきたいと思っています。
