実装理解のためのリファクタリングで品質を上げる

はじめに

業務でいわゆるレガシーなコードベースに対して開発を行ってきました。

ユニットテストがなかったり、設計思想が不明だったり、ツギハギだったり...
そんなコードをよく理解しないまま修正し、デグレや新たなバグを埋め込んでしまう...ということが私も過去にありました。

アプリ全体を含めた根本解決の時間が取れれば良いですが、普段の開発もツギハギではなく「立つ鳥跡を濁さず」的に、将来の保守者が同じ混乱に陥らない状況を作っていきたいものです。

過去の経験から、私は作業のはじめに「実装理解のためのリファクタリング」を行うようにしています。

ちなみに、以下書籍にこの記事と同じことが書いてあるので、体系的に学びたい方はこちらを読んでください。（むしろこの記事が劣化コピーです）

依頼の対応を完了するまで、以下のステップに分けて作業します。

最初にこの作業を挟むことで思わぬひらめきが得られることがあり、最終的なアウトプットが予想しなかった良い設計やコード量になることもあります。（DDD 本でブレイクスルーと紹介されるものだと思います）

実装理解のためのリファクタリングでは以下を繰り返します。
ノイズを減らしながら、実装に隠された仕様や裏背景を明らかにします。

現状の実装を理解するための作業なので、自分が重要だと思ったことや不明点など、思いついたことはとにかくコード内コメントでメモしておきます。

コードを理解することに集中したいので、それを阻害するものをなるべく減らします。

ただし、振る舞いが変わる破壊的な変更は行いません。
例えば、理解しづらい命名やメソッドの粒度をリネーム・インライン化で整える程度にします。

私は普段 IntelliJ の IDE を利用していますが、長期間メンテされていないコードでは警告や改善提案が出ることがあります。
破壊的な変更でなければサッと対応し、コードリーディング中の脳への割り込みを減らします。

IDE のリファクタリング機能を使えば、手作業ゆえのバグ埋め込みや対応漏れのリスクを抑えられます。

先程紹介したリネーム、インライン化、メソッド抽出なども私は基本的に IntelliJ IDE のリファクタリング機能で対応します。

上記のようなリファクタリングを行うことで、デグレの可能性を減らした依頼対応と、既存コードの改善が可能になります。

今回は依頼対応のステップのうち最初だけ記載しましたが、それ以降のステップでもデグレを起こさない取り組みを行っているので、またそれは元気がある時に記事化しようと思います...！