Tidy First? を読んでみました。
第1部は「整頓」するためのプラクティスについて。このあたりは内容的には リーダブルコード とかの方が実践的で分かりやすいと思うけど、おそらくこの本はそういう実践的な内容を紹介する本ではないんだろうと思います。なので、そういうのを期待して読むとちょっとズレるというか的外れになる気がするので、個人的にはもう少し俯瞰した視点で読むといいのかなと思いました。そういう自分も最初はわりと実践的な内容を期待してたところはあるので、ちょっと視点を変えて (特に第2部以降を) 読み直してみようかしら。
以下、読書メモ。
リファクタリングが「機能開発の長い中断を指す言葉として使われ始めた」っていう認識がそもそもないのよね
— kntmr (@knt_mr) 2025年1月12日
実際にはそうなってしまうかもしれないけど、こういう本でリファクタリングをこのように表現されてるのは少し意外でした。
3章 シンメトリーを揃える
既存のコードに手を入れる場合に、自分は既存のコードに合わせて書くことがよくあるのでこのあたりは共感できる。
ただ、途中でよりよい方法を見つけたときに、途中からその方法に切り替えるか既存のコードもまとめて変更するかが悩ましい。結局、前者を選択して既存コードは追々修正しようってなることが多い気がする。けど、結局やらない...。
5章 読む順番
読む順番は確かに大事。だけど、読む順番というか、「このあたりはこう書いてあって欲しい」みたいな期待値は個々人で違うかもって思った。こういうのはどうやって認識を合わせるのがいいだろう。あまりコーディング規約とかでがっちり固めたくないしなー。
11章 ステートメントを小分けにする
空行を入れてステートメントを小分けにするのよくやる。ソースコードには空行大事。
16章 分けて整頓する
最近は、プルリクエストは大きさよりも他のプルリクエストとの依存関係がどれくらいあるかが重要な気がしている。もちろんあまりにも巨大なプルリクエストは困るけど。プルリクエストを小分けにしても他との依存関係が多くなると全体感が把握できなくてレビューしにくい。とはいえ、いわゆる「整頓のプルリクエスト」は基本的には他のものと依存しないはず。(と思いたい)
あと、「整頓のプルリクエストではレビューを必須にしない実験」「レイテンシーを減らして小さい整頓のプルリクエストを作るインセンティブにする」というのはなるほど。これはよさそう。だけど、おそらくこれをやるならある程度は自動テストの環境を整える必要がありそう。
21章
整頓のリストを「お楽しみリスト」って呼ぶのいい。確かに楽しいもんな。
28章
可逆的な変更と不可逆的な変更。見返りの特性が根本的に違うものに対して同じ投資 (コードレビュープロセス) をしてしまっているっていうのはいい表現だなと思った。
