開発手法/リファクタリング

開発手法/リファクタリング

バージョンと製造年月日

2011-09-01

俺流リファクタリング流れ

当然ながら・・・まずリファクタリング前のソースをバージョン管理しまして、そこからもう縦横無尽に後先考えず思うがままにソースを修正していく。それを1日ぐらいやったらコミットして考える。

そしてやりすぎたなって思った所は反映せずうまくリファクタリングできたと思ったところを採用していく。

とにかく最初は広範囲に思うがままにリファクタする。

リファクタリングパターン

自分でこれはと感じたもの

引数→メソッド名へのパラメータの練り込み

引数を取るメソッドがあった場合で、その引数が取りうる値がすごく狭い場合(仕様で決まっていて3種類ぐらいしか値を取らない)、

public void hoge(String aaa){
    //...何か処理
}

場合

パラメータによるメソッドの挙動の変化をメソッド名に練り込んでしまって、引数を排除する。

public void hogeDoA(){
    //...何か処理
}
public void hogeDoB(){
    //...何か処理
}
public void hogeDoC(){
    //...何か処理
}

こうすると、メソッドを使う側は引数に関する情報を知る必要がなくなる。

これはswitchのラベル的な意味で取るStringの引数やbooleanの引数を排除する場合に有効。

PK等の条件を取って内部でDBから引く→PK版とオブジェクト版に分離

PK等の条件を引数でとって、内部でDBからオブジェクトを引き出してゴニョゴニョという動きは結構あると思う。

この時にPKで引っ張ってくる部分とゴニョを分離して、引数にPKを取る版とオブジェクトを取る版に分離する。

public String hoge(int id){
    Piyo p = find(id);
    if(p.fuga == 123){
        return "ok";
    }else{
        return "ng";
    }
}

これを

public String hoge(int id){
    Piyo p = find(id);
    return hoge(p);
}
public String hoge(Piyo p){
    if(p.fuga == 123){
        return "ok";
    }else{
        return "ng";
    }
}

のように分離する。Piyoを取る版はDBが不要になるので純粋にok,ngを返すロジックのテストができるようになる。

タグ

development_method/refactoring.txt · 最終更新: 2012-02-06 20:06 by ore