リファクタリング第2版の感想

読書感想文

2024-08-15

はじめに

全エンジニアが読まなければならない本として有名な Martin Fowler氏の『リファクタリング』という本がある。

私は、エンジニア経験4年目にもかかわらず、読んだことがありませんでしたw

もともとサンプルコードがJavaだったものが第2版でJavaScriptになり、内容も現代風にアップデートされており、いままでなんとなくで行っていた「リファクタリング」の目的や本質を理解しておきたいと思い読んでみた。

またこの本は12章あるが、1~4章まではリファクタリングの原則や必要性がまとめられていて、あとの章はすべてリファクタリング技法のカタログになっている。

カタログ系の内容は具体的すぎるため今回は触れないつもりです。

「リファクタリング」という言葉ひとつとっても、名詞と動詞では意味が異なると紹介されている。

リファクタリング(名詞)

リファクタリングする(動詞)

上記のことを踏まえると、リファクタリングする(動詞)には多くのリファクタリング(名詞)が含まれており、リファクタリングはコードをきれいにするあらゆる作業を表すものではなく、コードをきれいにするための手法であると理解した。

リファクタリングを行う理由として以下のことが挙げられている。

その中でもプログラミングを速めるという理由が私には刺さった。

リファクタリングを行うと、通常の開発のプラスαでコードを書く時間が増えてしまうので開発スピードが落ちるのでは？と懸念されるが、リファクタリングをするからこそ開発スピードが速くなる。

システムを長期的に開発していると、コードはどんどん複雑になっていき理解しづらい状態になるため機能追加が困難になっていく。

ただ、定期的にリファクタリングを行い、ソフトウェア内部の品質を保つことで既存コード把握が容易になり、新規機能を追加する際の影響範囲を限定的にできる。

結局のところ、いつリファクタリングすべきなのか基準を設けておかないと、本来行うべき作業に集中できなくなる。

この本では以下のタイミングでリファクタリングするとよいと紹介されている。

この中の機に応じたリファクタリングの内容は、私は実践できていなかったので良い気付きになった。

具体的な内容は下記で、特に良いコードに対してもソフトウェアの変化に合わせてリファクタリングしていくべきという視点が私には無かったので勉強になった。

リファクタリングは、ひどいコードを見つけた時に行うだけではなく、素晴らしいコードに対しても必要。
コードを書く際は常にトレードオフを意識し、昨日までは正しかったトレードオフの判断も新たに追加する機能によっては妥当でなくなる可能性がある。現実に合わせてトレードオフを見直して、リファクタリングを行う。

「リファクタリング」を読んで、リファクタリングの目的や実施するタイミングが明確になり、根拠を持ってリファクタリングをできるようになった。

また、今回は紹介していないカタログの章も読むことで、リファクタリング手法の引き出しが広がり実務に活かすことができるため、是非読んでいただきたい。