「リファクタリング」は必要か？

はじめに

最近チームのメンバーとリファクタリングについて話す時間がありました。
自分はかなり「リファクタリング」という言葉に懐疑的な自覚があるため、現時点でどのように考えているかをまとめておきたいなと思いました。

リファクタリングが指すものは人によって違う

リファクタリングは、一般的に「外部から見た振る舞いを変えずに、内部の構造を改善すること」と説明されます。
Martin Fowlerのリファクタリングでも、この定義が出発点になっています。

一方で、Kent BeckのTidy First?では、リファクタリングという言葉の意味がすでに変わってしまっていることが指摘されています。
機能開発を長期間止めて行う作業を指してリファクタリングと呼ぶ人が増え、「振る舞いを変えない」という条件すら抜け落ちてしまった、という話です。
Kent Beckはこれを受けて、振る舞いを変えない小さな構造の改善を「整頓（tidying）」という別の言葉で呼んでいます。

このように、リファクタリングという言葉が何を指すかは人によって違うことが多いです。
そして今は、「振る舞い」一つとっても解釈が色々あります。

エンドユーザーにとっては、たしかに振る舞いは変わりません。
しかし、コードを読み書きする開発者にとっては、リファクタリングによって振る舞いは常に変わります。
どこに何が書いてあるか、どう変更すれば良いか、どこまで影響するかが変わるからこそ、リファクタリングをする意味があるはずです。

そして今は、コードを読み書きする主体として AI の比重が大きくなっています。
AI がコードベースをどう理解し、どう変更を加えるかは、構造によって大きく変わります。
誰にとっての振る舞いなのかによって、同じ変更が振る舞いを変えるとも変えないとも言えてしまいます。
開発者や AI にとっての振る舞いがこれだけ重要になっているのに、「振る舞いを変えない」ことを特徴にした言葉で語ることに、あまり意味がないと思っています。

機能や事業の何に寄与するのか

リファクタリングをしたとして、それは機能や事業の何に寄与するのでしょうか。

本来、この問いには「リファクタリングした」の一言では答えられないはずです。

この先予定している機能開発の速度を上げるため
障害が起きやすい箇所の変更を安全にするため
新しく入ったメンバーや AI が理解しやすくするため

このように、具体的な目的があって初めて構造を変える意味が出てきます。
そう考えると、リファクタリングはもはや開発の一つであって、わざわざリファクタリングと呼び分けなくても良いのではと思っています。

レバレッジの効く改善は説明責任とセット

レバレッジの効く構造の改善をしようとすると、自然とビジネスの話になるはずです。
どの事業領域がこれから伸びるのか、どこに変更が集中するのかを知らなければ、どこの構造を良くするべきかは決められないからです。

そしてビジネスの話をするなら、説明責任もセットでついてきます。

「リファクタリングをする必要があります」だけではステークホルダーを動かすことは難しいです。
リファクタリングという名前ではなく、具体的な目的を持った開発として説明できるはずです。
逆に目的を説明できないなら、その時間を使う理由や今やらなければいけない理由がまだ整理できていないのだと思います。

リファクタリングという言葉に全てを押し込めるのをやめて、何のために何を変えるのかを言葉にしたいと考えています。

日々の営みではどうすることもできなくなってしまったら？

日々の営みの延長線上で扱うには大きすぎてどうしようもない課題が生まれるという場面もあると思います。
これはよく「技術的負債」のような言葉で説明されることが多い気がします。

それ自体が第一級の問題になっているなら、それに取り組むことは理解できます。
ただ、そこまで大きな問題なのであれば、リアーキテクチャのように、プロジェクト自体の具体的な目的として扱うべきだと思います。

自分は「技術的負債」という言葉もあまり好きではありません。
リファクタリングと同様、事業やシステムのどのような問題や課題を解決しようとしているかを、より詳細な言葉で語ることができるはずだと思っています。

古いライブラリ、読みにくいコード、テストのない箇所、設計の歪みは、それぞれ問題の種類も解決したときに得られるものも違います。
一つの言葉でまとめてしまうと、何が問題でなぜ今解決すべきなのかが見えなくなってしまいます。

おわりに

リファクタリングという言葉について、最近考えていることを書きました。

リファクタリングが指すものは人によって違い、「振る舞い」の解釈も一つではない
リファクタリングは機能や事業への寄与を一言では説明できず、開発の一つとして扱えば良い
レバレッジの効く改善はビジネスと構造の話になり、説明責任とセットになる
日々の営みで扱えない大きな課題は、リアーキテクチャのような具体的な目的を持つプロジェクトとして扱う
リファクタリングや技術的負債という言葉に全てを押し込めず、何のために何を変えるのかを言葉にする

構造を良くすることそのものは大事だと思っています。
だからこそ、説得力のある言葉でその価値を説明できるようになりたいです。