「リファクタリング(第2版): 既存のコードを安全に改善する」 - 読書メモ

Martin Fowler (著), 児玉公信 (翻訳)の「リファクタリング(第2版): 既存のコードを安全に改善する」を読んだ。

読んだうえで実践してみた感想

効率がよくなり、かつ（対象のコードに対する）自信に満ちあふれるためとても楽しい
IntelliJなどのIDEに搭載されたリファクタリング機能の意味が理解できるしうまく使える
一気に作業をやりがちで、どこでエラーになったのかわからなくなることがよくある。一定の手順で一歩ずつ実施することで早く失敗でき体感として早く終わったように感じた（実際はわからないが、へんにバグにはまってしまうみたいなことが減った）

前編から実際に聴いてほしいが、ざっくり以下のような流れでリファクタリングの大事さが理解できた。

自動テストがあれば、設計をあとから安全に変更できるようになった
リファクタリングと自動テストはセット
実装の変わりやすいところというのは分かるのか？
- よかれと思って追加した物は使われない（YAGNI）
- 結果的に想像力を超えていく変更がはいる（変わりやすいところを推測するのは難しい）
リファクタリングしながらパターンにしていく
- リファクタリングのゴールやターゲットとしてのデザインパターンになった
- そのためリファクタリングが大事
身軽であることが備え
- 可能なかなりシンプルにしておき、変化に備える

多少表現がポッドキャストと異なるかもしれないが、この流れで聴いてすぐにでもリファクタリングを習得したいと思えた。

たまたま見つけたのだが、texta.fm - Sideshow 9. Master of Writing Test Codeで、t_wadaさんが

このような話があり、特に

自動テストは動作確認という作業も「コード書いてよい」になった

ここに感動した。テストを書くのはなんとなく楽しいと感じてはいたが、純粋に別枠のコーディングが楽しかったのだと気がついた。ポジティブな視点を得られて聴いてよかった。

全体的に表現がおもしろく、かなりマーカーをひいた。いくつか引用したい。

できる限りデータは不変にしておくべきでしょう。可変な状態はすぐに腐ってしまうからです。 p27
私は、単なる好みを超えて、よいコードはどれだけ変更が容易なのかで決まると思っています。 p43
リファクタリング期間中に数日間コードが壊れたままになっているなら、それはリファクタリングとは言えない。 p46
リファクタリングは、コードベースがどれだけ美しいかではなく、純粋に経済的な基準で測られるものです。リファクタリングするのは、あくまでもスピードを上げるため、新機能の追加やバグの修正を速めるためです。そのことを常に心にとどめるべきですし、メンバにもその観点を持って接していく必要があります。 p57
多くの優れたプログラマたちが好むリファクタリングが「デッドコードの削除」です。不要なステートメントに火炎放射を浴びせるのは最高です。 p205

「デッドコードの削除」をおこなうとき効果音付きで「バーン！！」といいながら消していた自分に気がつきました（楽しい）。

この書籍は大半がリファレンスのように使えるように構成されているため、身近なところにおいて思い出しながら日々参照してリファクタリングの手法を習得したい。シンプルでわかりやすいコードがかけるようになりたい。

最近、積読がはかどりすぎて読みたい本がたくさんスタックしている。出勤もほとんどしていないため電車での読書の頻度も減ってしまった。寝る前や、子どもたちを寝かしつけた後に読むこともあるが、結局うとうとして読めないことが多い。何かしら対策を考えたい。