リファクタリングという技術
2012 年 2 月 3 日 by yasukuniコーディングを行なっている際に次のような経験はないでしょうか？
・ちょっと前にも同じようなことを記述した記憶がある。
・似たような機能(画面)が既に存在したので、コピー＆ペーストでコードを複製した。
・コードの中にコメントを記載しないと意味が解らない変数やマジックナンバーが沢山ある。
・バグが入り込んだ際に、原因の特定に時間を要する(修正が困難)又は、途中でトレースするのが嫌になった。
・仕様変更による影響が多岐に及び、対応/評価に莫大な時間を要した。
この様な経験があれば、リファクタリングが必要なのかもしれません。
リファクタリングとは機能を変更することなく、コードの組み換え等を行い仕様変更への耐性、保守性の向上を行う技術です。
この技術の根本には、仕様というのは変動的であり、多くの場合に漏れ(抜け)があるという考えのもと行われます。
例えば、同様のコードが見つかった際に、共通化する小さな努力を怠ったり複製を行うと、修正が発生した場合に対象が多岐に及ぶことは避けられません。
ただ、このリファクタリングを行う際に、一番注意しなければならないことは
『リファクタリング前後で動作が変わらないこと』です。
ただ闇雲に行なってしまうと、正常に動作していた機能が動作しなくなるばかりか、芋づる式に修正範囲が広がってしまい、逆に手が付けれないことにもなりかねません。
大きなリファクタリングを行う際は、テスト方法も併せて十分検討する必要があります。
次は小さなリファクタリングのサンプルです。この処理は何を意味するのでしょうか？
int work = 100 / 37.5782;
マジックナンバー”37.5782″がよくわからないので隠蔽するために、処理をメソッド化しました。(※37.5782は100m世界記録の時速)
int hour = this.getNecessaryHourForRunning(100);
function int getEstimateHour(int km){
return km / 37.5782;
}
行数は増えてしまいましたが、処理を共通化することだけがリファクタリングの目的ではありません。
このメソッドを見れば、走るために必要な時間(h)が取得できることが一目でわかります。
もし仮に、ヒトが走ると疲れることを考慮に入れる仕様が追加された場合も、このメソッドを修正すれば非常に小さなスコープで影響が収まります。
まず、この様な小さなことから始めてみると良いのかもしれません。
