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

積読消化回。 10 年以上前にリファクタリング・ウェットウェアを読んだ時からこういう本は好きなので。 見た感じワーキングメモリにも触れてるぽい。脳のワーキングメモリを鍛える！もだいぶ前読んだので学びほぐしみたいな感じで臨む。 ファストアンドスローも持ってるけどどこに行ったかわからなくなってるしこの機会に探し出そう。

2024-09-28, read count: 1, page: iii ~ xviii

Part 1 Chapter 1 コードをより良く読むために コーディング中の混乱を紐解く 知識不足 = 長期記憶、情報不足 = 短期記憶、処理能力不足 = ワーキングメモリ。 長期記憶がストレージ、短期記憶 = RAM、ワーキングメモリ = CPU 。これらはわかりやすく抽象化してるだけであることに注意。 実際は、例えば短期記憶に欠落する情報でも長期記憶内でパターン化された情報を参照して推測したり、相互に作用している。

2024-09-29, read count: 1, page: 1 ~ 14

Part 1 Chapter 2 コードをより良く読むために コードを速読する チャンク、感覚記憶、アイコニックメモリ。 パターン、コメント、ビーコンの適切な利用がチャンクを形成するのを助ける。 長期記憶にパターンが充実してるほど、短期記憶のスロットを節約でき、効率的に記憶できるってか。

2024-09-30, read count: 1, page: 15 ~ 40

Part 1 Chapter 3 コードをより良く読むために プログラミング言語の文法を素早く習得する方法。 現在の科学でわかっているのは、長い期間期間をかけて勉強した方が長く記憶に留まるということ。 記憶には貯蔵強度と検索強度があり、すぐ記憶から引き出せないのは検索強度が低いから。 この状態を web の検索とかでカバーしてしまうと検索強度が上がらないままになる。 意図的に思い出そうとすること≒想起記憶、また覚えたての概念を他の既知の概念につなげる精緻化≒推敲が強度を高めるのに有効に働く。 素早く習得できたことないので参考にしよ。

2024-10-01, read count: 1, page: 41 ~ 56

Part 1 Chapter 4 コードをより良く読むために 複雑なコードの読み方。 コードが複雑だとコレまでの手法は通用しない。問題の処理に用いられる短期記憶＝ワーキングメモリが 2~6 個しか同時に処理できないため。 課題内在性負荷＝問題自身の複雑さ、課題外在性負荷＝コードの書き方や読み手の知識不足に起因する複雑さ。 複雑で読めないコードには認知的リファクタリングを施すか、依存関係グラフ、状態遷移表といったツールで理解を深める。 仕事なら認知的リファクタリングという選択はあるかな。趣味プロであえてやる意味ないし好きじゃないな。 妙にリスト内包表記が槍玉に上がっててかわいそう...

2024-10-02, read count: 1, page: 57 ~ 76

Part 2 Chapter 5 コードについて考える コードの深い理解に到達する。 変数の役割フレームワークは読み解くときにマーキングの方法だけでなく書くときにも使える。 チャールズ・シモニーのハンガリアン記法の正しい使い方にも可能性がある。 ただいずれも強制力がないからなあ。 どこからコードを読み始めるかという起点がフォーカルポイント。 これってエラーログとかの外的要因で明確なら困らなさそう。 読解するのが目的だとエントリポイントや関数の先頭からとか、より難易度高くなる選択肢しかないんやろな。

2024-10-03, read count: 1, page: 77 ~ 93

Part 2 Chapter 5 コードについて考える コードの深い理解に到達する。 コードの読解に関してクヌース先生だけ別格でわろた。 Coders at Work 家のどっかに積んでるわ。 プログラムの読解には言語能力が強く関係しており、自然言語を読むためのテクニックがコード読解にも使える。 過去の知識の活性化、読解の監視、コードの重要性の判断、変数から推論、コードの可視化、自問自答、コードの要約。 こうやってキーワードを羅列するとフレームワークのようになるけど、こうなると個人的に全然やらなくなるタイプのやつ。 特に手で表を書き出すとかが字も図も下手で苦手なのでなんかいい感じに自分のスタイルに組み込みたいな。

2024-10-04, read count: 1, page: 93 ~ 108

Part 2 Chapter 6 コードについて考える プログラミングに関する問題をよりうまく解決するには。 コードの読解にメンタルモデルを利用する。メンタルモデルはデータ構造やパターン。 想定マシンはプログラミング言語が何をしているかを抽象化するモデル。理解の際に記憶に定着した誤ったモデルが利用されることもある。 これらのメンタルモデルは互いに競合せずに問題に適用することもできる。長期記憶のスキーマと強く関連づくものほど有用。 結局のところ身近な概念で振る舞いを表現するから、自身の持つ語彙力が貧弱だと貧弱になりうる。 つまりちゃんと勉強しろよって話に聞こえるよな。メンタルモデルそれ自身もどれだけ手札があるかという話だし。

2024-10-05, read count: 1, page: 109 ~ 130

Part 2 Chapter 7 コードについて考える 誤認識：思考に潜むバグ。 学習した知識が他の分野でも役に立つのを転移(transfer)という。 同じ領域の学習が容易になるのを学習中の転移(transfer during learning)という。 長期記憶に格納された知識が学習に役立つのは学習の転移(transfer of learning)という。名前似過ぎてややこし... 転移にも種類がある。 無意識にスキルを伝達する一般道の転移(Low Road Transfer)、意識して伝達する高速道路の転移(High Road Transfer)、対象の領域の遠近で近転移、遠転移、 学習に良い影響を与える正の転移、悪い影響を与える負の転移。 遠転移はほとんど自然発生することなく、適切に近い領域に転移することがよい学習効果につながる。 負の転移が誤認識を生む。これを抑制するために概念変化(conceptual change)でメンタルモデルを置き換えたり、抑制によって正の転移を促す。 ただし正しいモデルを構築しても古いモデルが邪魔をすることも常に起こり得る。

2024-10-06, read count: 1, page: 131 ~ 146

Part 3 Chapter 8 より良いコードを書くために よりよい命名を行う方法。 名前はコードの大部分を占める。名前の文法を適用することで名前の品質を高め、チャンクを促す、ビーコンになる等して短期記憶・長期記憶を助ける。 命名の難しいのは linting できないとこと感じてるのでバトラー方式の linter ないんかな。

2024-10-07, read count: 1, page: 147 ~ 160

Part 3 Chapter 8 より良いコードを書くために よりよい命名を行う方法。 略語が指す意味がそれほどコンセンサスが取れてないから略さない方がいい。 キャメルやスネークそれぞれ一長一短あるが全体として一貫性がとれてたらどっちでも良い(でもゼロから始めるならキャメル推しらしいが)。 誤った名前がバグを導くかは因果関係があるとは限らない。 雛形を少なくし、フェイテルソンの 3 ステップで名付けることで品質の高い命名ができる。 コレだけ読むと、キャメル＆ケバブで推奨される動詞が決まってる PowerShell の cmdlet 命名アプローチは勝ち筋やん。

2024-10-08, read count: 1, page: 161 ~ 172

Part 3 Chapter 9 より良いコードを書くために 汚いコードとそれによる認知負荷を避けるための 2 つのフレームワーク。 コードの臭いは構造的アンチパターンで、名前は言語的アンチパターン(概念的)。 構造的アンチパターンはワーキングメモリに負担をかけ、誤ったチャンク化を引き起こす。言語的アンチパターンは負の転移を引き起こす。 コードの臭い。一部は OOP の文脈に依存してたりあまり一般化できるものではないねんよな。エッセンスは FP とか他の文脈にも活きるねんけど。 恐らくそのエッセンスと思ってきたところが認知プロセスに関わる部分なんやろな。

2024-10-09, read count: 1, page: 173 ~ 187

Part 3 Chapter 10 より良いコードを書くために 複雑な問題をより上手に解決するために。 問題解決を構成する要素はゴール状態・スタート状態・ルール。最適な方法で状態空間を遷移してゴール状態に到達するのが問題解決。 問題解決能力向上には自動化と範例というテクニックが使える。 自動化は、潜在記憶(手続き記憶)≒無意識にタイプする等の肉体的な記憶。認知不可をかけないが、負の転移を起こしがちなので学びほぐしが要る。 潜在記憶は長期記憶を形成するテクニック(間隔を空けて反復する)で強化できる。 範例は、問題解決のためのレシピを利用した学習。レシピが学習関連負荷を下げて脳が忙し過ぎて記憶できない状態を避け、長期記憶を形成しやすくする。 なんか何事も練習あるのみって感じやなやはり。

2024-10-10, read count: 1, page: 188 ~ 208

Part 4 Chapter 11 コーディングにおける共同作業 コードを書くという行為。 プログラミングは 5 つの活動で構成される。検索・理解・転写・増強・探索。それぞれに異なる認知システムを利用するので適したアプローチが異なる。 プログラミングではゾーンに入るのに時間がかかり、一度割り込まれると戻るのに約 25 分かかるので、戻るための目印を置く＝ロードブロックリマインダ。これは後述のテクニックを使ってる。 割り込みから復帰しやすくするための 3 つのテクニック。 1 コードのメンタルモデルを保存する、 2 展望記憶(TODO のような未来の記憶)を補助する、 3 下位目標のラベル付け(解決ステップを細分化したテキスト)。 割り込みを防ぐための FlowLight わろた。集中してる時赤色点滅してたら気になりそう。マルチタスクできないのはもう昔からわかってるもんね。やらぬが吉。

2024-10-11, read count: 1, page: 209 ~ 224

Part 4 Chapter 12 コーディングにおける共同作業 より大きなシステムの設計と改善。 コードベースの認知特性を予測する術として Chapter 11 で出た CDN(Cognitive Dimensions of Notation) から派生した CDCB(Cognitive Dimensions of Code Bases) がある。 13 の次元を持つ。エラーの発生しやすさ、一貫性、拡張性、隠れた依存関係、暫定性、粘性、段階的評価、役割表現力、マッピングの近接度、ハードな心的操作、副次的表記、抽象化、視認性。 エラーの発生しやすさを下げると粘性が高まる等、特性はトレードオフの関係にある。 特性はプログラミング言語・フレームワーク・エディタのようなツールの選択で決まるような制御しにくいものもあれば、コードの構造的・言語的な問題で改善できるものもあるのは救いか。 どの特性を重視するかはチームのスキルセットや好みの問題やろな。言語の選択によってエラーの発生しやすさを上げてまで粘性を高めたいとは思わんかな。 暫定性と段階的評価は REPL でカバーできそうやなと見えるし、言語やフレームワークの選択は固く、それで下げた特性はツールでカバーて感じが好みか。

2024-10-12, read count: 1, page: 225 ~ 241

Part 4 Chapter 13 コーディングにおける共同作業 新しい開発者のオンボーディング。これで終わり。 シニア開発者とジュニア開発者の間には、大量の長期記憶の差があり、結果としてシニア開発者の与える大量の情報が認知的負荷をかけ過ぎてしまうことがある。 初心者プログラマの行動を新ピアジェ主義モデルで理解する。初心者プログラマの理解のプロセスは意味波(理解のため抽象と具象を行き来する)に従う。 これらを踏まえたうえでオンボーディングを行うと。 いまこういうことに関わる機会ないのでそういう機会が万一あった時に備えて心の中に留めておく。 一通り読んだので、自分や誰かの理解がイマイチでも認知プロセスのどのへんに問題があるのかくらいは気を使うきっかけは持てたかもな。

2024-10-15, read count: 1, page: 242 ~ 269