「プログラマー脳」のchapter9「汚いコードとそれによる認知的負荷を避けるための2つのフレームワーク」

目次

1.初めに
2.臭いのあるコードは、なぜ認知負荷が大きいのか？
3.悪い名前が認知負荷に与える影響
4.【プログラマー脳】Chapter

1. 初めに

「プログラマー脳」という本を読んでいます。
その中で印象に残ったことや大事だなと思う部分をまとめています。
自分の理解の必要に応じて自分が慣れているJavaScriptで処理を書いています。

2. 臭いのあるコードは、なぜ認知負荷が大きいのか？

コードのにおいの影響

• 臭いの影響のあるコードはエラーが含まれる可能性が高い

匂いがするコードを書かないようにするためには、コードのにおいがどんな害を及ぼすのかを理解しておくことが重要

長すぎるパラメーターリスト : ワーキングメモリの容量オーバー

function createUser(
  firstName: string,
  lastName: string,
  age: number,
  gender: string,
  address: string,
  email: string,
  phoneNumber: string,
  favoriteColor: string,
  favoriteFood: string,
) {
  // ...
}

この関数は、非常に多くのパラメーターを持っており、可読性が低く、メンテナンスが困難になります。

パラメーターをリファクタリングする必要があります。

例として、パラメーターをオブジェクトリテラルとして型定義してみます。

type User = {
  firstName: string,
  lastName: string,
  age: number,
  gender: string,
}
type Contact = {
  address: string,
  email: string,
  phoneNumber: string,
}
type Favorite = {
  color: string,
  food: string,
}

function createUser(
  user: User,
  contact : Contact,
  favorite : Favorite,
) {
  const { firstName, lastName, age, gender } = user
  const { address, email, phoneNumber } = contact

  console.log(favorite.color,favorite.food)
  // ...
}

ユーザー情報はuserのオブジェクトがデータを持ち、連絡先や住所はcontactのオブジェクトが持っています。リファクタリング前のコードと見比べたときに、何の値が渡ってきているのかが頭の中にチャンク化されて残っているので、認知的負荷が下がったと言えるのではないでしょうか。

個人的にはfavoriteのオブジェクトのように渡しても認知的負荷を下げることができるのではないかと思います。

コードクローン(重複したコード)

const addNumToTarget = (target: number) => {
  if (target < 0) {
    return target
  }

  return target++
}

const plusNumToTarget = (target: number) => {
  if (target < 0) {
    return target
  }

  return target + 2
}

上記の2つの関数は名前も実装も非常によく似ているため、脳は両者を混同する可能性が高い

脳はaddNumTargetとplusNumToTargetの返す関数が異なるにもかかわらず、1つのカテゴリとしてまとめて認知してしまいます。

そのため、コードを何度か読む中で改めて認識し直す必要が出てきてしまいます。

その他のコードの臭い

• 複雑なswitch分
• 巨大なクラス(神クラス)、長すぎるメソッド

コードを扱うとき、私たちは常にコードを整理し、抽象化をおこなっています。そのため、意味のある名前を持つ小さな関数に分割していくことを好みます。まとまりのある属性値と関数グループはクラスとしてまとめることができます。そうすることで、名前がドキュメントとして機能するでしょう。

コードの臭いは一般的に知られている概念のようですね
https://ja.wikipedia.org/wiki/コードの臭い

3. 悪い名前が認知負荷に与える影響

言語アンチパターン

• コード内の言語的要素とその役割の間の不整合である

6つ

• メソッド名に書かれた以上の働きをするメソッド
• 実際の働き以上のことをするかの如きメソッド名
• メソッド名に書かれたのと真逆のことをするメソッド
• 実際に格納されているよりも多くのものが含まれているかの如き識別子
• 実際に格納されているよりも含まれているものが少ないかの如き識別子
• 実際の格納されているものと真逆な識別子

悪い名前が「誤ったチャンク化につながる」

• 長期記憶が思考をサポートする際に、間違った事実を検索してしまうことが原因であることが考えられる
• また言語化アンチパターンは、実際の実装とは異なる処理内容が推測してしまうため、間違ったチャンク化が行われてしまう

4. 【プログラマー脳】Chapter

「プログラマー脳」のchapter1「コーディング中の混乱を紐解く」
「プログラマー脳」のchapter2「コードを速読する」
「プログラマー脳」のchapter3「プログラミング言語の文法を素早く習得する方法」
「プログラマー脳」のchapter4「複雑なコードの読み方」
「プログラマー脳」のchapter5「コードの深い理解に到達する」
【TODO】「プログラマー脳」のchapter6「プログラミングに関する問題をよりうまく解決するには」
【TODO】「プログラマー脳」のchapter7「思考に潜むバグ」
【TODO】「プログラマー脳」のchapter8「より良い命名を行う方法」
Now →「プログラマー脳」のchapter9「汚いコードとそれによる認知的負荷を避けるための2つのフレームワーク」
【TODO】「プログラマー脳」のchapter10「複雑な問題をより上手に解決するために」
【TODO】「プログラマー脳」のchapter11「コードを書くという行為」
【TODO】「プログラマー脳」のchapter12「より大きなシステムの設計と改善」
【TODO】「プログラマー脳」のchapter13「新しい開発者のオンボーディング」