システムのリプレイスや性能改善のためのリファクタリングを行うためには、コードを理解することは必須ですよね。
そのコードを見てすぐに仕様や振る舞いが理解できると幸せですが、そうでないことのほうが多いように感じます。
そんなときのアプローチ手法の紹介。
メモる/スケッチを描く
膨大なコード、眺めてるだけじゃ理解できないことのほうが多いです。
ロジックを上から読んで、メソッド呼び出しがあればそのメソッドのロジックを確認して、、、なんてことをすると脳内メモリはすぐパンクします。
そんな時はメモを取りましょう、絵を描きましょう。
これはエクセルやメモ帳などのシステムツールではなく、紙に書いたほうが効果があります。
上からコードを読んでいき、メソッドがあればどこか別の場所にメソッド名を書いて線で結び、また元のロジックに戻る。
そうしていくうちに、縦の流れから線が伸び、植物の根のようになります。
そこから関連を見つけ出し、グルーピングすることで理解が深まることはよくあります。
メソッドの名前も正確でなくてもよいですし、よくあるUMLを使う必要もないです。
その場限りの理解を深めるためだけに使用するものとして、描いて理解することが良いようです。
試行リファクタリング
変更対象のコードを変更前の状態で、ただ闇雲にリファクタリングします。
メソッドの抽出や変数の移動、あらゆる方法を利用してリファクタリングをする。
ここで行うリファクタリングは、コードをきれいにすることではなくコードを理解することを目的とします。
コードに触れていることで、コードへの理解が上がるという効果を狙います。
そしてここでリファクタリングしたコードはどこにもコミットせずに捨てちゃいましょう。
そうすることで、リファクタリングの本来の目的を意識せず、自分が理解しやすいようにコードを改変することができる、とのことです。
このような取り組みのことを「試行リファクタリング」と呼ぶようです。
上記の手法は
レガシーコード改善ガイド
第16章 変更できるほど十分に私はコードを理解していません
に掲載されています。
https://www.amazon.co.jp/dp/4798116831