Closed14

『プログラマー脳』を読む

yoshinoyoshino

Chapter 1 コーディング中の混乱を紐解く

  • コードを読み書きする際には3つの認知プロセスが関与している
    • 長期記憶、短期記憶、ワーキングメモリ
yoshinoyoshino

Chapter2 コードを速読する

  • 短期記憶の容量は2〜6つ
  • チャンクの理論
    • 「チャンク」とは情報のかたまり
    • 対象が覚えやすい情報のかたまりになっていると、より多くの情報を短期記憶に入れられる
  • チャンク化しやすい(=読みやすい)コードを書く方法
    • デザインパターン
    • コメント
      • コメントは新人プログラマーのコード理解を助ける
    • ビーコン
      • チャンクよりも小さなコードの部分
      • 単純なビーコン:意味のある変数名、演算子、ifやelseなどの制御構造
      • 複合的ビーコン:self.leftself.rightなど、まとまって意味を成す複数のプロパティ
  • ビーコンを認識する練習
    • あまり見慣れないコードからメソッドを1つ選んでコードを読む
    • コード理解に役だったビーコンのリストを作る
    • ビーコンを改善、または追加する
  • コードをチャンク化する練習
    • ある程度内容を把握しているコードから50行ほど選んで2分間読む
    • 読んだコードを再現する
    • 再現できた箇所、再現できなかった箇所から、自分に馴染みのないプログラミング概念、ビジネス領域の概念を抽出する
yoshinoyoshino

Chapter3 プログラミング言語の文法を素早く習得する方法

  • プログラミング言語の文法を覚えるべき理由
    • プログラミングに関する概念、データ構造、文法を知っていればいるほど、コードリーディングが速くなる
    • 情報検索という割り込み作業のために生産性が低下する
  • プログラミング言語を覚えるのにフラッシュカードが有効
    • https://quizlet.com/
    • 間隔をあけて繰り返すこと
    • 積極的に思い出そうとすること
    • すでに理解しているプログラミング概念と関連づけながら新しい文法を記憶すること
yoshinoyoshino

Chapter4 複雑なコードの読み方

  • コードリーディング時に認知的負荷がかかるパターン
    • 解くべき問題自体が複雑なパターン
    • 問題を解く作業に別の作業が付随するパターン:変数の置き換えなど
  • 認知的負荷を軽減するテクニック
    • 認知的リファクタリング
      • インライン化:メソッドを呼び出し元の関数に直接埋め込む
      • 無名関数、リスト内包表記、三項演算子などを従来の書き方に戻す
  • ワーキングメモリに負荷がかかっているときに使えるテクニック
    • 依存関係グラフ:コード内の関連する変数やメソッドを線でつなぐ
    • 状態遷移表:変数の遷移を表にする
yoshinoyoshino

Chapter5 コードの深い理解に到達する

  • コードを読むのに必要なスキルと、自然言語を読むのに使うスキルは強く関連している
  • 変数の役割
    • https://zenn.dev/shava2c/articles/1fe0e0bd13b115
    • 固定値
    • ステッパー:for i in range(0, n)iなど
    • フラグ
    • ウォーカー:二分木の検索インデックスなど
    • 直近の値の保持者:line = file.readline()lineなど
    • 最も重要な値の保持者:最大値を満たす最初の値を保持する変数など
    • 収集者:sumなど
    • コンテナ:リスト、配列など
    • フォロワー:prevなど
    • オーガナイザー:文字列を文字配列にするなど、異なる形式で保存するためだけに使われる変数のこと
    • テンポラリ:tempなど
  • 変数の役割を区別することで、プログラムの特徴をつかむことができる
  • ハンガリアン記法も場合によっては役立つ
  • コードへの深い理解を得るポイント
    • フォーカルポイント(コード内の注目すべきポイント)を見つける
    • フォーカルポイントから知識を拡張する
    • 関連する要素の集合からコードの概念を理解する
    • 複数の要素にまたがる概念を理解する
yoshinoyoshino

Chapter6 プログラミングに関する問題をよりうまく解決するには

  • メンタルモデル
    • データ構造:有向グラフや無向グラフ、さまざまなリスト構造など
    • デザインパターン:Observerパターンなど
    • アーキテクチャパターン:MVCなど
    • ダイアグラム:実体関連ダイアグラムやシーケンス図など
    • モデリングツール:状態図やペトリネットなど
    • メンタルモデルは長期記憶とワーキングメモリの両方に存在する
    • メンタルモデルの知識をフラッシュカードでチェックする
  • 想定マシン
    • コンピュータが何をしているかを考えるために使うコンピュータの抽象的な表現
    • 変数に値を「格納する」、ファイルが「開いている」など
    • 既存のスキーマをプログラミングに適用するため、プログラミングの理解に役立つ
  • メンタルモデル、想定マシンは矛盾する可能性がある。最初の頃に学んだメンタルモデルは長期記憶に保持され、ワーキングメモリにも何度も読み込まれてしまうため、あらぬ混乱を招く可能性がある。
yoshinoyoshino

Chapter7 誤認識:思考に潜むバグ

  • 先に学んだプログラミング言語の知識が、新しいプログラミング言語の理解を邪魔することがある
  • 正の転移、負の転移
  • 概念変化:すでに知っているプログラミング言語に基づいて形成された誤認識を、新しく学ぶ言語に適したメンタルモデルに置き換えるプロセス
  • 概念変化の学習は通常の学習より困難
    • 誤認識は非常に長い期間残ることがある
  • プログラミング初心者が抱きがちな162種類の誤認識
  • 同じプログラミング言語を同じ順番で学んだプログラマーにアドバイスをもらうのも有益
yoshinoyoshino

Chapter8 よりよい命名を行う方法

  • なぜ名前が重要なのか
    • 名前はコードの大部分を占める
    • コードレビューの4件に1件は命名に関する指摘
    • 名前は最もアクセスしやすいドキュメントである
    • 名前はビーコンとして機能する
  • 初期の命名の慣習は永続的な影響を与える
  • 名前の品質の評価はコードレビューで行うべき
  • 名前の雛形を作ってコードの一貫性を保つ
    • 利用する雛形を減らすことでよりコードが理解しやすくなる
  • よりよい変数名のための3ステップのモデル
    • 名前に含めるべき概念を選択する
    • それらの各概念を表す単語を選ぶ
    • それらの単語を使って命名を行う
yoshinoyoshino

Chapter9 汚いコードとそれによる認知的負荷を避けるための2つのフレームワーク

  • 構造的アンチパターン:コードの臭い

https://qiita.com/NagaokaKenichi/items/22972e6ba698c7f2978a

  • 言語的アンチパターン:高い認知的負荷を引き起こす
    • メソッド名に書かれた以上の働きをするメソッド
    • 実際の働き以上のことをするかのごときメソッド名
    • メソッド名に書かれたことと真逆のことをするメソッド
    • 実際に格納されているよりも含まれているものが少ないかのごとき識別子名
    • 実際に格納されているよりも多くのものが含まれているかのごとき識別子名
    • 実際に格納されているものと真逆な識別子名
yoshinoyoshino

Chapter10 複雑な問題をより上手に解決するために

  • 問題を解くときには長期記憶を使っている
  • 見慣れた問題なら脳はより簡単に解決できる
  • 問題解決において重要な役割を担う2種類の記憶
    • 手続き記憶(潜在記憶)
      • タッチタイピング、forループの記述、クラスの作成なども
      • 繰り返しによって作られる
      • 習得したいスキルを利用する、少しずつ違った新しいプログラムをたくさん書く
      • 既存のプログラムを改良してみる
    • 宣言的記憶(顕在記憶)
      • エピソード記憶
      • 意味記憶
  • 問題を自ら解決すると、認知的負荷が高すぎて、情報が長期記憶に保持されなくなってしまう
    • 範例(=すでにある解法)から学ぶのが効率がよい
    • GitHubでコードリーディングするなど
yoshinoyoshino

Chapter11 コードを書くという行為

  • プログラミング中に割り込みが発生すると回復に時間がかかる
    • メンタルモデルが失われるため
  • 割り込みに備えるよい方法
    • メンタルモデルを保存する:コメントを残しておく
    • 展望記憶を補助する:TODOコメント
    • 下位目標のラベル付け:これから行う作業をあらかじめリストアップしておく
yoshinoyoshino

Chapter12 より大きなシステムの設計と改善

  • ライブラリやフレームワークの開発者向けの話
  • CDB、CDCN:コードの認知的特性を予測するフレームワーク
  • 今後他の開発者たちがどのような活動(=検索、理解、転写、増強、探索)を行う可能性があるのかに応じて、設計上の処置を行うべき
    • 1年に1回の見直しなど
yoshinoyoshino

Chapter13 新しい開発者のオンボーディング

  • 新しい開発者のオンボーディングで小さな開発タスクを割り振ることが多いが、それはコード理解+ビジネス理解が発生し認知的負荷が高すぎる状態
  • 新しい概念は抽象→具体→抽象の順で理解すべき(意味波)
    • オンボーディングでも同様
  • オンボーディングを改善するための活動
    • タスクにおけるプログラミング活動を限定する
      • コードを理解してドキュメントにまとめるだけのタスクを与えるなど
    • 一緒にコードリーディングを行う
    • ビジネス領域の説明とコードの説明は分けて行う
yoshinoyoshino

取り入れられそうなこと

  • 覚えられずに何度も調べている内容について、意識的に長期記憶に取り入れられるようにフラッシュカードを作成する
    • Dockerコマンド
    • Gitコマンド
    • Linuxコマンド
    • JavaScriptの文法
    • Reactの文法
  • 大きめのタスクを実装しているときは、プログラミングが中断されてもすぐ回復できるように、メモを残しておく
    • ChatGPTにタスクの分解をやらせて、同じスレッドで都度わからないことを質問していく。そしてどこまでタスクをやっている状態なのかすぐに取り出せるようにしておく、とか。
このスクラップは2023/10/09にクローズされました