業務で大幅なリファクタリングをする機会があり、その際の注意だったり、気をつけるべきことなどをまとめておきます。
自分用なので自分にしかわからない言葉で書いてある可能性が大きいです。
気になる方は問い合わせてください(爆)
Contents
親クラスやユーティリティクラスに集合させる
プログラムの抽象度をできるだけあげるためにもなるべく、抽象的だったり、汎用的なクラスに処理を集めましょう。
とはいっても心がけるだけでは中々うまくいかないものです。そのために大事なのが下記のような考え方でしょう。
インスタンス変数にむやみにアクセスしない
変数はなるべく、ローカル変数で対処しましょう。
インスタンス変数にアクセスしていると当たり前ですが、ロジックがクラスに張り付いてしまい、簡単に移動できません。
なるべくスコープの小さいローカル変数をつかっておけば、移動が楽です。
クラスインスタンスのパラメーター化
Listで変数をループさせる作業というのは最も頻度の高い処理だと思います。
List<String>,List<Map<String,String>>などだったらいいですが、List<Product>など自作のクラスを使う場合、ジェネリクスの中身を動的に変えたいことがあります。
その場合List<T>などといった使い方をする必要がありますが、これができるとできないとで抽象度が大きく変わってきますので注意しておきましょう。
プログラムはメイン処理とサブ処理のシンプルな形にする
要はそのメソッドのクラスに対する関連度、依存度をなるべく下げておきましょう。
言葉だとイメージがしにくいですが、プログラムを書くときに、
Ａ:メインの処理
Ｂ:サブ処理(Aから呼ばれる処理)、
C:サブ処理(Bから呼ばれる処理)、
・・・などとしておくとＢを別のクラスにリファクタリングすることが困難です。※Cがあるため。
A:メイン処理 ,
B:サブ処理(Aから呼ばれる処理)
Ｃ:サブ処理(Aから呼ばれる処理)
としておくとＢはAのみに関連しているためリファクタリングが簡単になります。
コーディング規約などはチェックリスト使用
どこまで厳密にするかにもよりますが、頭でその都度覚えようとすると必ず忘れますし、いずれ崩壊します。
チェックリスト化し、机の横に置きながらそれをすすめるようにしましょう。
テストコード
リファクタリングって特に本番運用中だとできなかったりします。理由としてはデグレードが怖いため。
デグレードを起こさないためにも安全弁としてテストコードを用意しておきましょう。
