「Good Code, Bad Code」メモ

高品質なコードと低品質なコードの違い

	高品質なコード	低品質なコード
ソフトウェアが本来満たすべき要件	十分に満たす	エッジケースによっては満たされない
要件の変更	少し追加作業が必要	多くの再作業とリファクタリングが必須
エラーの発生	システムは適切に復帰するか適切に落ちる	システムの動作がおかしくなり、データを破損する
システムへの攻撃	安全な状態であり続け、不正アクセスを受け付けない	謎の状態に陥る
全体	信頼度が高く、メンテナンスがしやすく、ほとんどバグがない	信頼度が低く、メンテナンスしにくく、バグだらけ

本書での良いコードの原則
エラーの発生に関しては Chapter4 で掘り下げてあるが、今までシステムが落ちない努力はある程度してきたものの、「適切に落とす」努力はしていなかったと感じた。

コードの品質のゴール

• 正しく動くこと
• 正しく動作し続けること
• 要件の変更に対応しやすいこと
• 車輪の再発明をしないこと

あるものは使う、使える形で残す

モジュール化
モジュール化されたおもちゃ
→ パーツごとに取り替え可能なロボットのおもちゃ

モジュール化されていないおもちゃ
→ 一箇所の糸がほつれるとダメになってしまうぬいぐるみ

問題が非常に複雑でも、小さな問題に切り出して正しい抽象化レイヤーを作れば、その複雑さを制御できます。

困難は分割せよ

私たちの書いたコードが他のコードから呼び出される小さなAPIを公開していると考えることは、多くの場合において有用です。

何を引数として何が返り値かを考えて実装
それを他のエンジニアもわかりやすい形で公開する

関数を一度作ったら、その関数を一つの文として試しに読んでみよう。
その文が読みづらかったり、不格好であれば関数が長すぎる可能性がある。

コーディングする際の習慣として取り入れると品質担保できる

• 凝集
  クラス内のものがどれだけ適切なクラスに所属しているかを評価する
  凝集度の高いクラスが良いとされる
  ただし、一つのタスクの定義はかなり主観的である。
  関連するものをどのように一つにまとめれば役に立つのか基準を決定する
  関連する小さな問題を解決することが別の問題として数えられるのか、メインの問題の本質的な一部としてカウントされるべきか意見が分かれる

どの粒度でコードを分割するかは個人開発では自分の価値基準で決定できるが、チーム開発では話し合いつつ分割を進める必要がある

Chapter 3

あなたにとっては明確なことでも、他の人にとっては明確ではない

自分のメンタルモデルと他のエンジニアのメンタルモデルは一致しない。
当然ではあるが、それぞれチームに所属するメンバーのバックグランドに依存して、コーディングに対する姿勢は異なる

あなたはやがて、あなたのコードのことを忘れる

チーム開発ではコードの読み手はメンバーだが、個人開発におけるコードの読み手は未来の自分である

コードの使い方を理解するための方法

• 関数やクラスの名前を見る
• データの型を見る
• ドキュメントやコメントを見る
• 直接メンバーに確認する
• 周辺コードを読む