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

投稿元：

レビューを見る

短期記憶、長期記憶、ワーキングメモリといった人間の認知モデルとその特性を解説し、プログラミングにおいてどのような部分でそれらの記憶が利用されるのか、何が記憶の定着を妨げるのかといった切り口で解説している。

感覚で認識しているこれらの負荷が丁寧に言語化され、また説明もわかり易かったのでコードを読む・書く場面での認知に対する理解が深まった。
この本を読んでなにか具体的なスキルが得られるというよりも、知識の引き出しを増やすことで対応できる場面が増えたり、どのように解決するかの手札が増える本だと思う。

完全なプログラミング初心者よりも、リーダブルコードの内容がしっくり来たタイミングのような初級者以降が読む事をオススメしたい。
もちろん、ベテランが読んでも自身の思考の言語化に役立つので良さそう。

投稿元：

レビューを見る

# 1周目 読み終えた
プログラミングを行うとはどういうことなのかを、また、そこから派生する活動を認知科学に基づいたアプローチで掘り下げていく。認知科学から発せられる得体のしれないもののような響きとは裏腹に、そんなに突拍子もないことは書かれていない。プログラミングをしている人なら漠然と感じたことがある、そういわれればそうだろうなというようなことに、ちゃんとした裏付けをとって、信憑性を高めたものになっている。そういった多くのことをわかりやすく整理して、また、具体的な手法を示して、そうした事実認識を定着させることにより、より良いプログラミングができるように導く。最も基本となっているのは、短期記憶、長期記憶、ワーキングメモリを使ってプログラミングを行っているという解釈だ。無意識にプログラミングをしているよりも、良い結果が得られるように、言ってみれば脳を騙すことによって、これらの記憶領域の活動に影響与える。1回読んだだけでは実践できるほど定着できていない。仮に実践できたとしても、即座に効果が得られるような類のものでもなさそうに思える。興味はあるので、何度か読み直して試してみたい。


## パート4を読んだ
コーディングにおける共同作業

‣ 11章 コードを書くという行為
‣ 12章 より大きなシステムの設計と改善
‣ 13章 新しい開発者のオンボーディング

共同でプログラミングするわけでなくても役に立つ情報だった。もし、企業で雇わている状態で作業をするなら13章はとても価値がある。ほとんどの労働環境において、到底ここで述べられているようなちゃんとしたプログラマー視点で考えられた環境であることは望めないが、少しでも改善されることを期待したくなる。


## パート3を読んだ
よりよいコードを書くために

‣ 8章 よりよい命名を行う方法
‣ 9章 汚いコードとそれによる認知的負荷を避けるための2つのフレームワーク
‣ 10章 複雑な問題をより上手に解決するために

具体的なプログラミングスキル強化のための取り組み方が提示されていて読みやすかった。今のところ、各所の演習は軽く目を通して考えを巡らしてみるだけで、手を動かして実践していなかったりする。そのせいもあって、これまで何が書いてあったのか、時間が経つにつれてあやふやになってきている。1回読んだだけでそれらが身につくわけでもないのでと割り切っている。この章のアプローチは説得力があって、試してみたいと思わされる。たぶん再読することになるので、そのときにきっちり身につけることを計画している。


## パート2を読んだ
コードについて考える

‣ 5章 コードの深い理解に到達する
‣ 6章 プログラミングに関する問題をよりうまく解決するには
‣ 7章 誤認識：思考に潜むバグ

難しくなってきた。まず、ここで提案されているフレームワークを定着させるのが簡単ではない。常に意識してトレーニングを積む必要がある。この本の役割が2つに分けられるとしたら、一つは、プログラミングに関連するアクティビティで脳で何が起こっているかを明らかにすることで、もう一つは、それを踏まえてより良い方向に矯正することになる。つまり、無意識のときの脳の自然な処理に手を加えて、無理やり都合の良いように書き換えることを目的とする。それによってより良い結果を得ようとするものだ。いかにも簡単であるはずもなく、やはり反復トレーニングが必須になる。


## パート1を読んだ
コードをよりよく読むために

‣ 1章 コーディング中の混乱を紐解く
‣ 2章 コードを速読する
‣ 3章 プログラミング言語の文法を素早く習得する方法
‣ 4章 複雑なコードの読み方

サブタイトルには「認知科学に基づくアプローチ」とあり、何やら難しそうなことが書かれているイメージだった。読んでみると全然そんなことなくて、この本自体がそのようなアプローチによって、脳に負担のかからないように書かれているものと思われた。コードの読み方についてということで、コードを読むときに脳で何が起こっているのかを分析し、よりよく読むためにはどうすればいいかを検討する。自分の経験では、これまでいっさいそのようなことを行ってこなかった。とにかくたくさん書いてたくさん読めばいい、言ってしまえば何も考えっていなかった。あとは自然に読む力がつくことを祈るのみだった。もし、何らかの戦略をもって挑んできたら、もしかしたら今よりもずっと良い結果が得られていたのではないかと思えてきた。今からでも、コードを読むときに一定のアプローチに基づいて取り組むよう意識することを試す価値がある。まず手始めにこの本で提案されている手法を採用するのはありだ。

投稿元：

レビューを見る

アプローチは違うがリーダブルコード的な書籍と結論は一緒。
脳の仕組みの面から解説している点がとても面白い。

自分が経験的に無意識でやっていたことが、正しいということがわかった。
プログラミング経験の長い人なら共感できるはず。

長期記憶：文法、アルゴリズムなどを記憶する。PCに例えるとストレージ
短期記憶：メソッド名、変数名などの一時的な記憶。PCに例えるとメモリ
ワーキングメモリ：短期記憶の情報を元に処理をする。PCに例えるとCPU

短期記憶、ワーキングメモリに記憶できる要素は2～6個
それを超えると脳が混乱する。
ゆえに長い関数を理解することは、脳にとってとても負荷の高い作業
これを認知的負荷と言う。

認知的負荷には二つある。
課題内在性負荷：コードが分かりづらいことによる負荷
課題外在性負荷：コードを書いた人と読む人の知識ギャップにより生じる(例えばラムダ式が分からない人がラムダ式で書かれたコードを読む等)


ベテランプログラマは複数の情報を塊で記憶している。
いわゆるアルゴリズムだとかデザインパターンだとか。
これをチャンク化という。

例えば下記のケースはいずれも12個の文字だが、後者の方が覚えることが容易。
・abk mrtpi gbar
・cat loves cake

それは"cat", "loves", "cake"という単語3つにチャンク化しているから。
初学者にはそれができない。長期記憶に情報がないことが原因。
ゆえにベテランプログラマに比べて認知的負荷が高まる。


プロジェクト単位では、コードの書き方に一貫性を持たせると脳への負荷が低い。
命名方法としては、キャメルケースの方が記憶しやすい。
スネークケースは変数を認識しやすいメリットがある。

プログラマが費やす時間の大半はコードを理解する(読む)時間である。
初学者は書き方を学ぶよりも先に読み方を学ぶべし。


短期間で詰め込むいわゆるブートキャンプ的なやり方はうまくいかない。
長期にわたって定期的に学ぶ方がより脳へ定着する。

スポーツの世界ではフォームだとか型が重要。そのための反復練習を行う。
しかし、このやり方をプログラミング界隈では行わない。
forループを100回書いて覚えるというやり方が実は有効。


プログラミング能力と数学的スキルに相関性はない。
プログラミング能力と相関性が高いのは言語能力。
(確かに話が分かりづらい人はコードもわかりづらい)

ある知識が別の知識に活かされることを移転という。
移転は主に近いもので起き、遠移転はほとんど起きない。
論理的思考を養うためにプログラミングを学ぶという考えは間違い。
プログラミングを学んだからと言って、論理的思考が養われることはない。

最後に割り込みについて。
コーディングに集中している最中に声を掛けられたり、チャットツールのメンションがきたりすると一気に集中力がなくなる。
そこから再���コードを書き始めるにはおよそ15分かかる。
集中していることがわかるときには声をかけないのがベスト。

投稿元：

レビューを見る

勉強したての人が読んでも学びがあると思う。記載のコードは読み飛ばすとしても、プログラミングを理解するための脳構造から、より読みやすくするための工夫、熟練者との考え方や見方の違いなどためになった。

投稿元：

レビューを見る

長期記憶、短期記憶、ワーキングメモリの3つのどれに対して負荷がかかるコードなのかを判別し、適切な方法で対処することで仕事時間の6割を占めるコードリーディング（ひいてはコーディング）の質を高めることができるという話。

フラッシュカード、状態遷移表（あるいはデバッガ）などの手法は一見地道だが、基礎力のアップが技術力を飛躍的に向上させる一助となるという論調は頷けるものだった。

また、プロジェクトレクシコン(命名規則とほぼ同義)の存在がコーティングの意思統一を容易にするという提言もあり、マネージメントを考える上で(多少無理をしてでも)導入しておくのが良いなと感じた。事前に全社レベルでテンプレを整理しておき、各プロジェクトに当てはめるのが良さそう。

投稿元：

レビューを見る

すごーく久しぶりに仕事がらみの本を読んだ。
今の会社で生き抜く術はスキルよりも泥臭さだなと見定めてしまったため、ここ10年近くは上昇志向は横に置き、リラックスできる読書ばかりに浸っていた。
少しづつ社内の風向きが変わってきたのと、年齢上昇と共に後進の育成というものを担わされるようになってきたので、幾ばくかのリスキル、アンラーニングに取り組むかということで手に取った本書。

短期記憶、長期記憶、ワーキングメモリ、人間は3つのメモリを駆使してタスクをこなすのはよく聞く話ではあるが、それをプログラミング及びそのスキル向上という命題に当てはめた一風変わったプログラミングの書。
認知的仕組みを理解することで、プログラミングにおけるタスクをいかに効率的に、正しく行っていくかに光を当てている。

プログラミング自体のスキルやテクニック、技術的なTipsに関する話題はほとんどないので、スキルアップしたなという実感は湧かないのだが、いくつか興味深い話題があった。

「変数の役割」のフレームワークは、なるほど確かに型だったり、個別の変数名だったりに意識を向けるより、一歩引いて役割を認識することでそのコードが何をしているのか捉えやすくなる気がするし、本書で紹介されている11の役割で充足するのか過剰なのかはさておき、役割で考えるとだいたいそのくらいしかないよなと思い納得。

命名規則にまつわるアンチパターンなんかも、話としては『リーダブルコード』や『達人プログラマー』、『リファクタリング』なんかで目にしてきたことではあるが、認知科学的側面からの根拠を示されることで改めて軽視すべきではないことだと理解できた。

最もこれから意識しなきゃなぁと感じたのは、初学者のオンボーディングにおいて、理解のプロセスが意味波に従うというもの。
意味波とは、初学者はまず一般的な概念を理解した後、アンパッキングというプロセスにより、より抽象度の低い、具体的な概念を理解する準備が整ってくる。その後、個別具体的な理解を積んだ後、再度抽象的な理解に戻り腹落ちする（リパッキング）という、時間経過と理解の抽象度の変化を表現したもの。

熟達者が初学者に物事を伝達する際にやりがちなのが、下記3つ。
・抽象的な概念しか教えていない（ハイフラットライン）
・詳細な情報を大量に与え過ぎて、そもそもなぜそれが重要なのか、便利なのか伝えられていない（ローフラットライン）
・抽象的な概念→具体的な内容と教えるが、理解の統合（リパッキング）を後押ししていない（下降専用エレベーター）
大事なのは、上位概念→下位概念→再度上位概念（理解の統合）と波に乗るような学びをサポートすること。

なるほどね～。

投稿元：

レビューを見る

コード読みで困難にぶつかったとき、自分を卑下するのではなく、認知的負荷が高すぎる、という説明がつけられることで、感情的にならずに、冷静にその現状を受け入れられそうな気がする。「唐辛子の種は辛くない」って知らなかった。「シニアが「Array index out of bounds」を概念として理解できる」は実感としてよく分かる。

投稿元：

レビューを見る

全プログラマーにおすすめの本。

プログラミングについて認知科学の視点から解説されていて非常におもしろい。
どのようなコードが脳にとって認知的負荷が高いのか、認知的負荷を下げるにはどのようにすればいいのかということが詳細に説明されている。
普段自分がコードを書いていて難しいと感じるときに、なぜ難しいのかが明確なった。
新しい言語を勉強するときや、新人へのオンボーディングにも役立つ。