メモる/スケッチを描く

膨大なコード、眺めてるだけじゃ理解できないことのほうが多いです。
ロジックを上から読んで、メソッド呼び出しがあればそのメソッドのロジックを確認して、、、なんてことをすると脳内メモリはすぐパンクします。

そんな時はメモを取りましょう、絵を描きましょう。

これはエクセルやメモ帳などのシステムツールではなく、紙に書いたほうが効果があります。

上からコードを読んでいき、メソッドがあればどこか別の場所にメソッド名を書いて線で結び、また元のロジックに戻る。

そうしていくうちに、縦の流れから線が伸び、植物の根のようになります。

そこから関連を見つけ出し、グルーピングすることで理解が深まることはよくあります。

メソッドの名前も正確でなくてもよいですし、よくあるUMLを使う必要もないです。
その場限りの理解を深めるためだけに使用するものとして、描いて理解することが良いようです。

試行リファクタリング

変更対象のコードを変更前の状態で、ただ闇雲にリファクタリングします。

メソッドの抽出や変数の移動、あらゆる方法を利用してリファクタリングをする。
ここで行うリファクタリングは、コードをきれいにすることではなくコードを理解することを目的とします。

コードに触れていることで、コードへの理解が上がるという効果を狙います。

そしてここでリファクタリングしたコードはどこにもコミットせずに捨てちゃいましょう。

そうすることで、リファクタリングの本来の目的を意識せず、自分が理解しやすいようにコードを改変することができる、とのことです。

このような取り組みのことを「試行リファクタリング」と呼ぶようです。

上記の手法は
レガシーコード改善ガイド
第16章　変更できるほど十分に私はコードを理解していません
に掲載されています。
https://www.amazon.co.jp/dp/4798116831