リファクタリングが億劫な人にこそ読んでほしい『Tidy First?』感想
変更に強いコードは小さな整頓から始まる -『Tidy First?』を読んだ話
ラブグラフエンジニアのひろです！
今回は『Tidy First? - 個人で実践する経験主義的ソフトウェア設計』を読んだので、その感想を書いておきたいと思います。
📖 『Tidy First?』ってどんな本？
いつ・どこでコードを整頓（Tidy）するか？
具体的な整頓の方法や、適切なタイミング、またなぜ整頓が必要なのかなど、具体的な手法から理論まで解説されていて、リファクタリングと機能追加のバランスに悩んだことがある方が読むと良さそうだなと感じました。
長く運用されているコードだと、機能追加をする場所に古くなって使われていないコードがあったり、何年も前に書かれていて、動いてはいるんだけど整理したいようなコードに出会うことが珍しくないと思います。
そんなとき、どう対処するべきなのかが書かれていて、今後の開発に活かせる心構えを知ることができました。簡単に一部を紹介します。
🗂️ なぜ整頓をするのか
変更しやすいコードを保ち続けるため
いつどんな変更が必要になるか分からない開発の中で、必要に応じて柔軟に変化できるように、コードを整理しておくことが大事だという理解をしました。
Kaigi on Rails 2024 の基調講演でも、 Tidy First? を元に同じ話がされていたので、まだ聞かれてない方はぜひ聞いてみてください。
録画
資料
📅 いつ・どこで整頓するか？
整頓するべきかをどう判断するのか
整頓をいつやるのか、ということについては状況によって判断する必要があります。
- 「先に整頓」：直近の改修が楽になるなど、すぐにメリットがあるケース
- 「あとで整頓」：今すぐではないものの、分岐がたくさん追加される予測がある場合など、放置すると変更コストが上昇してしまうケース
- 「整頓しない」：変更の予定もなく、一定の複雑さを許容するしかないケース
時間をかけすぎない
整頓の目的は「次の変更をやりやすくする」ことです。
あくまで整頓。深追いしすぎず、次の変更がしやすくなった時点で止めるのが良いそうです。
事前に整頓してから
整頓のみをおこなったPRを作成することが推奨されていました。
レビュアーも楽ですし、その後に本来の改修・新規追加タスクをやる自分にとっても良いですよね。
改修作業の前に、整頓だけのPRを作ってマージし、
（ここで深追いは厳禁、あくまで整理するだけ）
その後、本丸の改修に入るのが良さそうです。
💡 整頓術
具体的な整頓術
リーダブルコードなどの本と被る内容もありましたが、たくさん紹介されていた中から、自分がこれからも意識したいと思ったものをいくつか紹介します。
-
ガード節（早期リターン）を多用しすぎない
return された対象を早めに思考から消せるので、僕は結構気に入っていて多用していたんですが、たくさん並んでいると読みづらいとの意見もあることを知りました。 -
適度に変数化をする
長すぎるメソッドチェーンを書かないこと。
自分が読んでいて、理解を段階的に進めた時点で変数化することで、変数名から処理の内容を伝えることができ、理解が早まりますね。 -
冗長なコメントを削除する
コメントは「なぜそのコードが存在するのか？なぜそう書いたのか」を伝えるためにあるので、自明なコメントや実態と合わなくなったコメントは削除・改良しましょう。
✍️ 感想
機能追加や改修のタスクがあったとき、その過程でまとめてリファクタリングをおこなうのではなく、最初に小さい整理を済ませてから追加・改修に入ること。
とても良い方法だと思ったので自分も目下の開発から少しずつ試しています。
今までの自分はリファクタリングというと大掛かりなものを想像しがちで、それにより「今は厳しいけどいつかやりたい。。」と放置してしまっていたので、小さな整理を積み重ねることで、読みやすい・変更しやすいコードを保てるようにしていこうと思えました！
みなさんも『Tidy First?』ぜひ読んでみてください！
Discussion