社内のエンジニア有志で書籍『リファクタリング(第2版): 既存のコードを安全に改善する』の読書会を6ヶ月間にわたり実施しました。本記事では読書会で出た感想・学び、そして私が所属するチームに持ち帰ったことで起こった変化をご紹介します。
リファクタリングに対する参加者の気付き
読書会が始まる前、私はリファクタリングに対して漠然と「大変」「時間がかかる」「でも必要」と思っていました。おそらく他の参加者も似たような印象を持っていたと思います。
しかし、本書を読み進めてリファクタリングの方法を学ぶにつれて、「なぜ必要なのか」「どのタイミングですべきか」「どうやってするのが効果的なのか」「注意点は何か」の解像度が上がり、「これならできる」「しないといけない」と思うようになりました。
その変化は、読書会の参加者の感想にも表れています。
【池内さん】
本書の中の「プログラマの大半がどのようなことに時間をかけているか調べると実際にコードを書いている時間はきわめて短い」という指摘が印象的でした。「テスト → コーディング → リファクタリング」のサイクルを頻繁に回すことが非常に生産的で安心できる方法であると記載されており、テストから書き始めることが推奨されています。これはそもそも、コーディングの前に『何を作るべきか』を正確に理解することが質の高い開発につながることを再度認識させられました。
【永野さん】
本書のリファクタリングの定義を読んで、今までのリファクタリングに対する認識が変わりました。
- リファクタリング（名詞）: 外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること
- リファクタリングする（動詞）: 一連のリファクタリングを適用して、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること
つまり、リファクタリングする（動詞）ということは、非常に小さいステップでそれぞれ完結するリファクタリング（名詞）を繰り返し適用していくことで、大きな変化をもたらしていくということです。
これは、リファクタリング中はコードが壊れた状態になっている期間が非常に短く、たとえ未完成であってもいつでも中断が可能であることを意味します。
私は今まで、リファクタリングと言いつつ壊れた状態が長期間続くような大きい修正をして、退行があった際に原因の調査が難航するという経験があったので、この定義はとても参考になりました。
【前田さん】
次のことが重要であると学ぶことができました。
- いくらコードがきれいになったとしても、正常動作をしないのは本末転倒。リファクタ前に正常動作がどのようなものか確認すること。テストがない場合はまずテストを書くことから始める。
- リファクタリングはスモールステップで徐々に変えていく。まとめて一気に変えてしまうと、どこが原因でエラーになっているか分かりにくく、修正に時間がかかる。
- 「リファクタリング」と「機能追加」の2つの帽子を意識すること。両方を同時に作業するのではなく、リファクタリング時はリファクタリングに、機能追加時は既存のコードを変えず、機能追加に専念すること。
自分はどちらかと言うと、リファクタ時に「この動作おかしくない？」と思った場合、リファクタそっちのけで機能修正に入り、タスクを長引かせてしまう癖がありました。その癖を認知するきっかけになり、コーディングタスクの責務分離を考える良い機会になりました。
また、とにかく雑でも動けば良いコードを書くのではなく、「実装速度がほぼ変わらないのであれば変数名等もしっかりこだわってつけるべき」という心構えが身につきました。
【杉田さん】
この本は、リファクタリングが特定の技術的負債を一撃で解決する「銀の弾丸」ではない、と明言しています。むしろ、日々の開発に組み込むべきマインドセットであり、コードの健康を維持するための継続的な活動だと捉えるべきだと学びました。
また、リファクタリングは単なるお掃除ではありません。それは、未来の自分自身や、後からコードに触れる仲間に対する「思いやり」であり、ソフトウェアという生き物を健全に育てていくための継続的な活動なのだと感じました。
私が所属するチームでも「リファクタリング」との向き合い方が変わるきっかけに
以前、私が所属するチームでは「リファクタリングはタスクから切り離し、計画的に行う」というルールがありました。これは、リファクタリングに時間を取られて本来のタスクが進まなくなることがあったためです。
しかし、読書会で得た学びは、このルールを見直すきっかけになりました。
読書会を進めるうちに、「第3章コードの不吉なにおい」に書かれている内容が、自分が作業しているコードにもよく当てはまることに気づきました。例えば、「不可思議な名前」「長い関数」「長いパラメータリスト」「変更可能なデータ」など。これは、普段からリファクタリングができていない証拠だと痛感しました。
そこで、チームのふりかえりで「もっと気軽にリファクタリングをしたい」と提案しました。
議論の結果、「タスクの目的を達成するために必要な軽いリファクタリングは、タスクの中で行ってOK」というTryを設けることができました。それと併せてユニットテストで確実に確認することも決まりました。
その後、チームメンバーからも「安心できるようになった」「チームとしてレベルアップした感じがある」などの声も出てきました！
リファクタリングのハードルを下げた「リファクタリングのタイミング」
実は、上の提案を私が所属するチームにした時にやや懐疑的な意見もありました。やはり、チームのメンバーもリファクタリングは大変・時間がかかるという認識を持っていたのだと思います。
しかし、「第2章リファクタリングの原則」「いつリファクタリングをすべきか」の記載内容を使って説明することができました。
- どんなに優れたコードでも、機能に変更がある場合はリファクタリングが必要になる
- 時間と労力がかかる計画的・長期的なリファクタリングだけではなく、理解のため・ゴミ拾い的なリファクタリングもあること、それを日々行うことで健全なコードを維持できるということ
自分のリファクタリングのタイミングに対する解像度もあがり、その知識でチームの共通の理解を押し上げることができ、読書会に参加して本当に良かったと思いました。
おわりに
本書と読書会のおかげで、「なぜ、いつ、どうやって」リファクタリングすべきかの解像度が格段に上がりました。感想にもあったようにリファクタリングは「銀の弾丸」ではなく、日々の開発に組み込む継続的な活動だと再認識させられました。
また、読書会というインプットが、所属するチームの変化というアウトプットにつながりました。これからも小さな「リファクタリング」を積み重ね、より良いコードを維持して行きたいです！
Discussion