## リファクタリングしたほうが良さそうなコードを探す

でたらめにファイルを選んでもリファクタリングしたほうがいいコードはありますが、優先度が高そうなコードを探します。

なんとなくですが、普段は以下の基準に当てはまるものを優先的に対応しています。

`お金を稼いでいる処理 × ユニットテストが無い × 短時間で対応出来そう × 理解が難しい処理`

「短時間で対応出来そう」が実は肝心でして、対応時間が長いとリファクタリング範囲も広くなってしまう場合があります。結果的にリリースも遅くなり、他のリファクタリングが出来なくなる経験があります。なので「短時間で対応出来そう」を基準に含めています。

## 課題作成する

弊社では Backlog で課題を管理していますので、同様に課題を作成します。課題作成の段階では大雑把に記載しています。

タイトルにはリファクタリング課題であることが分かるようにしています。リファクタリングを一通り終えてから本文に対応内容を記載しています。短く簡潔を目指しています。

リファクタリング課題のリリースは優先度が低くなることが多いので忘れがちになります。課題内容を見たときに「思い出した」ではなく「内容が分かる」を目指しています。

## リファクタリングする

リファクタリングする目的がユニットテスト可能にすることがほとんどなので、テスト可能なコードにリファクタリングします。

コードの入力と出力がテスト出来ればいいかなと思っているので、処理の見やすさ等は一旦行わなくてもいいかなと思っています。修正中に整理することが多いです。

## リリースする

リリースしてもらいます。自分はリリースする役割ではないのでお願いします。リリースする前には「こういうリファクタリングをしました。テストはこれをしました」などは伝えておきます。

## 終わり

これらを地道にやっていきます。チームビルディング的な観点で見るともっと改善出来そうな気はしています。

アイキャッチ画像のために掃除っぽい画像をおいておきますね。