Tidy First? 読んだ
発売当初から話題になっていて気になっていたTidy First?を読んだので感想的なものを書く。
ちなみにAmazonは在庫なく2ヶ月待ちだったので書店に行ったらそちらも在庫がなくて取り寄せしてもらってやっと購入できた。
第Ⅰ部 整頓
具体的な整頓の方法について。
2章 デッドコード
消そう。以上。
せやな。
3章 シンメトリーを揃える
同じことをしているなら同じ書き方にする。
6章 凝集の順番
あるひとつの機能を変更しようとするときコード上の複数の箇所に変更が加わる場合、それが近い場所にある方がよい。
凝集とは by Claude
凝集(cohesion)とは、モジュール（クラスやメソッドなど）内の要素がどれだけ密接に関連しているかを表す指標。凝集度が高いほど、そのモジュールの責務が明確で、保守性が高いとされる。
主な凝集度の種類
機能的凝集（Functional Cohesion）
- モジュール内のすべての要素が単一の明確な機能を実現するために協力している状態
- 最も望ましい凝集度
時間的凝集（Temporal Cohesion）
- 特定のタイミングで実行される処理をまとめたもの
- たとえば、アプリケーションの初期化処理をまとめたクラスなど
論理的凝集（Logical Cohesion）
- 似たような処理をまとめたもの
- ファイル操作をするメソッドをFileUtilクラスにまとめるなど
- 必ずしも関連性が強くない場合もある
高い凝集度を持つコードの利点
- 可読性が向上する
- テストが容易になる
- 再利用性が高まる
- バグが発生しにくくなる
- 保守が容易になる
凝集度を高めるためには、単一責任の原則（Single Responsibility Principle）に従い、各モジュールが明確な一つの責務を持つように設計することが重要。
12章 ヘルパーを抽出する
a()をb()の前に呼び出す必要がある場合、その部分を切り出して
ab() a() b()
のようにすると時間的な結合を表現することができる。
14章 説明コメント
なぜこうしているのか、この場所を変更するときに注意すべき点などはコメントに残しておく。
15章 冗長なコメントを削除する
例にあるような、
getX() # X を返す return X
のレベルはさすがにいらんやろと思うが、変数名が実際にやっていることをちゃんと表せていないことはままあるので、自分は多少冗長でもあった方がマシ派。
振る舞いが変わったなら元々あったコメントの方も一緒に直しておいてくれ。
第Ⅱ部 管理術
個人が整頓を普段の開発に組み込むにはどうするのか。
16章 分けて整頓する
整頓はそれ自体で分けてPRを作るべし。
自分の環境では悲しいことにレビューが後回しにされ続ける未来が見えるので、チームでの整頓の話がされるであろう次作に期待。
17章 連鎖
自分はコードを読みながらエディターの警告を修正することがよくあり、一通り読み終わったら何ファイルも差分ができていたというのが起こりがちなので気をつけようと思った。
19章 リズム
整頓するのは、将来システムの振る舞いを変更するときに、それを簡単にするためだ。
コードにおいて、振る舞いの変更は一部に集中する傾向にある。
すべてのコードを整頓しようとして時間をかける必要はない。
ボーイスカウト精神で今変更するところを整頓していけば、いずれは変更する部分はすでに整頓済みになるはず。
21章 先に整頓、あとに整頓、改めて整頓、整頓しない
21.2 改めて整頓
正直、この部分は共感できない。
もしかしたら会社の中で開発部署がどの程度力を持っているかによるのかもしれない。
第Ⅲ部 理論
一度読んでみてあまりよくわからなかった部分が多い。
今また読んでもまだよくわからない。たぶん眠くない時に読んだ方がいい。
ことあるごとに何度も読み直すことになりそうな本なので、いつかすんなり理解できるといいなと思っている。
Discussion