プログラマー脳 ④ Chapter 4 複雑なコードの読み方

寝床で、昨日読んだ内容を思い出そうとしていた。

なかなか思い出せないものだ。

自分は、想起が嫌いであり、そのせいで長期記憶がスカスカなのだと思う。

他の人は、読んだ漫画の内容などを自然に思い返したりするのだろうけど、僕は刹那的に消費してしまうので、その作品について語ったりできない。

まあ、プログラマー脳については、このように所感を述べるほどに吸収したい意欲があるので、他の事柄よりは思い出しやすかった。

《昨日読んだ内容の想起》

  • 人が同時に覚えていられる内容（= 短期記憶）はせいぜい 6 つ。そのため、次の 2 つの方策が重要になる。

    • チャンキング
      • その「せいぜい 6 つ」を最大限に活用する方法。対象を意味の塊という単位で把握する
    • 長期記憶化

  • 「都度調べれば良い」の何が問題か

    • 想起を伴わないので、その対象が長期記憶化すべきものだと脳が認識しない
      • → また忘れて調べ直すという悪循環
    • コンテキストスイッチの切り替えコストが発生する

  • コードを覚え、再現してみるのが学習に有効

    • 自分の苦手な部分が浮き彫りになる

  • 長期記憶を増やすには

    • フラッシュカードによる、対象を絞っての意図的な反復練習が有効
      • Anki をインストールし、デッキを作った
      • カードを増やすのに適切なタイミングは、何かを調べようとした時
    • 精緻化
      • この用語自体を覚えるのを面倒臭がっていた自分に気付いた
      • 学んだばかりの内容を他の事象と繋ぎ合わせたりして分析し理解を深めるプロセス

  • 「記憶の強さ」は次の 2 つの概念で表せる

    • 貯蔵強度
      • 学べば学ぶほど強くなる
      • 時間が経っても減退しない
    • 検索強度
      • 減退する
      • 想起を試みることで強化可能

まあ、まずまず思い出せているか

読んだ内容の多さに対して、まとめた内容は少ないけれども、そういうものだろう

ここで、これまでのまとめを読み直して、何が思い出せていなかったのかを確認してみる

大体は思い出せていた感じだ

アイコニックメモリの点で、声に出したりすると自分にとっては良さそうかもね、というのは重要だった

ただ、Chapter 2 が「速読」、3 が「文法を習得する方法」だったけれども、そこら辺の区別は曖昧だった

Chapter 2 は、いかに上手にチャンキングして、短期記憶をフル活用するかが主題だったようだ

そして、コードを読んでから再現する方法は、チャンキングに上達するための方法であるとのこと

また、デザインパターンも、短期記憶を助けるためのもの、とのこと

チェスの盤面を、よくある場面で覚えているのと同じようなものだろう

Chapteer 4 複雑なコードの読み方

《本章の内容》

  • プログラムを書くときに発生する 2 種類のワーキングメモリの過負荷を比較する
    • 2 種類、気になる
  • 複雑なコードを読むときのワーキングメモリをサポートする状態表と依存関係グラフの作成
    • 面倒でやらなさそうなヤツだというのは覚えている

これまで読んできた内容は、短期記憶と長期記憶に関するものだった

本章では続けて、ワーキングメモリ、つまり処理について扱う

4.1 複雑なコードを理解するのが難しい理由

処理を追うのが難しい場合は、メモを取りたくなるようね、という話

ワーキングメモリと短期記憶の違いは何か

短期記憶とワーキングメモリを区別しないケースもあるとのこと

ただ、本書では区別し、ワーキングメモリを「問題の処理に用いられる短期記憶」と定義する

  • ワーキングメモリも、一度に処理できる事柄の個数は 2 〜 6
    • 自分はそんなに処理できていないような気が
    • この容量を 認知的負荷 と呼ぶ
      • これをオーバーすると「過負荷」になる

4.1.2 プログラミングに関連する認知的負荷の種類

認知的負荷は以下の 3 つに分類される

  • 課題内在性負荷
    • 本質的な難しさ
  • 課題外在性負荷
    • 同じ処理でも可読性によって変わるヤツ
    • 問題の図が読みにくかったり
  • 学習関連負荷
    • 考えたことを長期記憶に保持する際に引き起こされる認知的負荷

4.2 認知的負荷を軽減するテクニック

4.2.1 リファクタリング

保守性に優れているコードが認知性でも優れているとは限らない、ということ、盲点だった

確かに、処理を分散させると、追うのが大変になる

でも、保守性の方が重要だよね

読みやすさを目的に、自分用にコードを書き換えることを、認知的リファクタリングと言う

メソッドとして切り分けられているものをインライン化したり

4.2.2 使い慣れない言語構造の置き換え

コードを読むときに起こりうる混乱を、

  • 知識不足
  • 情報不足
  • 処理能力不足

と 3 つに分類している。

なるほど、長期記憶が知識、短期記憶が情報か

4.2.3 同義で書き方の違うコードはフラッシュカードデッキの非常によい追加要素

とても長い見出しで内心笑っていたけれども、考え直してみると、それだけ強調したいことなのだろう

実践するようにしよう

4.3 ワーキングメモリに負荷がかかっているときに使える記憶補助ツール

4.3.1 依存関係グラフを作成する

変数、関数、インスタンスという 3 つで色分けをしている。

また、同じ要素を線で結び付けて、どこで登場しているのかが一目瞭然になるようにしている。

まあ、確かに、こうすると分かりやすいよね

4.3.2 状態遷移表の利用

各変数の値がどのように変化していくかを記したもの。

コードリーディングの際、コメントなどで、もっと積極的にやっても良いのかも。

頭の中でコードを実行するプロセスを、トレース、または 認知的コンパイル と呼ぶ

↑ これは、デバッガーにやらせると良いことだ

でも、環境の要因もあって、デバッガーを上手く使えていないんだよな…

使わないとだよな…

4.3.3 依存関係グラフと状態遷移票を組み合わせる

《本章のまとめ》

まあ、本章で提唱されている内容の中で、自分が実践しうることとしては「デバッガー使おう」ということだろうな

RubyMine のデバッガーが Docker との絡みで上手く動かないのは解決が難しそうだけれども、JS の debugger は多用していきたい