Open3
Good Code, Bad Code読書メモ
mishGood Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考を読み始めた
本書では、GoogleのテックリードであるTom Long氏が、その知識と経験に基づいて「よいコード」と「悪いコード」を見極めるための概念やテクニックを紹介します。そのための「4つのゴール」「6つのコード品質の柱」を示し、具体的な事例を使って、なぜ「このコードはよい／悪いのか」を解説します。また、それを確認するためのユニットテストについても紹介します。プロのソフトウェアエンジニアとして必携の一冊です。
mish第1章 コードの品質
- なぜ品質の高いコードが大事なのか
- 高品質なコードとはどういうコードなのか
- 正しく動作する
- 正しく動作し続ける
- 変更に対応しやすい
- 車輪を再発明していない
- 読みやすいコードとは
- 想定外の事態をなくす
- 誤用しにくいコードを書く
- HDMIケーブルと電源ケーブル
- 違う種類のケーブルはそもそも刺せない
- モジュール化する
- ぬいぐるみとロボットの例
- ロボットはパーツを交換できるし元に戻しやすい
- ぬいぐるみは縫い直したり縫い付けたりしないといけないので変更も元に戻すのも大変
- ぬいぐるみとロボットの例
- コードを再利用、汎用化しやすくする
- 再利用性：ハンドドリルは天井にも壁にも使える
- 汎用性：ドリル穴を開けるのにも使えるしネジ穴を開けるのにも使える
- 垂直の壁にしか使えないドリルや天井にしか使えないドリルは再利用性も汎用性も低い
- テストしやすいコードを書き適切にテストする
- 単体テスト
- インテグレーションテスト
- E2E
- モジュール化されたシステムはテストがしやすい
- 高品質なコードは開発スピードを遅めるか
- 短期的にみるとそうかも
- 長期的にみると高品質なコードを書いた方が時短になる
- 急がば回れである
mish第2章 抽象化レイヤー
- きれいな抽象化レイヤーで問題を小さな問題に切り分けよう
- コードを書くことは問題を解決すること
- どう構造化するか
- 抽象化レイヤーを反映するようにコードを構造化すると読みやすさ再利用性汎用性の高さに繋が理テストも書きやすくなる
- 関数、クラス、インターフェースを使ってコードを明確な抽象化レイヤーに分割する
- 関数：多くのことをやりすぎない、細かく分割すべき
- 単一のタスクを担うのみ
- クラス：300行を超えないようにすべき論は大体の場合正しい。必要以上のものを含んでいる場合が多い
- 絶対ではない
- 凝集：クラス内のものがどれだけ適切なクラスに所属しているか評価するもの。凝集度が高いほど良い
- 逐次的凝集：一つの出力が他の入力に必要な場合
- コーヒー豆を挽き、コーヒーを抽出する
- 豆を引かなければコーヒーが入れられない
- 機能的凝集：一連のものが全て１つのタスクのために動く場合
- ケーキ作りのツールは全て一つの引き出しにあると便利
- 関心の分離：ゲーム機とテレビが分離されている例
- ゲームはゲームを動かし、テレビは動画を写すためのもの
- 逐次的凝集：一つの出力が他の入力に必要な場合
- 関数：多くのことをやりすぎない、細かく分割すべき