リファクタリングとは？プログラムの動きを変えずにソースコードをきれいにする作業

リファクタリングとは、プログラムの動きを変えずにソースコードをきれいにする作業です。

「プログラムの内部構造を整理」なんて書かれたりもするけど、要するに、コードをきれいにする作業。

「読みにくいなぁ」と思ったら、シンプルなつくりに変えたりして整理するメンテナンスのイメージ。

ソースコードを修正したことで、動作が変わったら意味がないので、案外、神経を使う作業です。

リファクタリングは、動きを変えずにソースコードをきれいにする作業

リファクタリングは、動きを変えずにソースコードをきれいにする作業。

年末とかにやる家の大掃除みたく、なんかのタイミングでやる作業だと、とらえて問題なしです。

ソースコードとは、プログラムが書かれたテキストのこと

ソースコードとは、プログラムが書かれたテキスト、あるいはその1行のことです。

てきとうに、Javaで、それっぽいのを書いてみるとこんな感じ。

String gyomuKbn = “X”;

switch (gyomuKbn) {

case : “X”
// 業務区分Xの処理を書く
break;

case : “Y”
// 業務区分Yの処理を書く
break;

case : “Z”
// 業務区分Zの処理を書く
break;

default :
// 何もせずに抜ける
break;
}

これを”hoge.java”のように、テキストで保存したのがソースコード。

「ソースコード」とも「ソース」とも、あるいは、単に「プログラム」って言っちゃったりします。

初めのうちは、ソースコードはキレイであることが多い

「ソースコード」（プログラム）を作るときに、はじめからぐちゃぐちゃにしてやろうと思って作る人はいません。

実際にプログラミングするときは、プログラマーが外部設計や内部設計に沿って、がんばって、ソースコードを書きあげます。

この時点では、ソースコードというのは、作りこまれて、きれいなのが普通です。

※相当、ボリュームが多かったり、新人プログラマーが書いたとか事情があるなら別だけど。

色々と作業していくうちに、ソースコードがごちゃごちゃになる

はじめは、キレイだったソースコード。

例えば、完成したところで、仕様変更（お客様から「やっぱ、こうして」といわれること）で、ソースコード全体を、急ピッチで修正したり。

あとは、単体テストでは問題なかったけど、結合テスト・総合テストの工程で、他のプログラムとのつなぎのテストのときに問題が発生したときは、やはり修正が入ります。

突然やってくる仕様変更や、結合テスト・総合テストの工程になると、いろんな修正が入るので。

わりと、簡単にごちゃごちゃになるものです（はじめに作った人と、この時に直す人が別なのも、よくある話。IT業界を経験すればわかるよ。きっと 笑）。

どこかで、「えいやっ」ときれいにする

そこで、ソースコードをきれいにする作業である、リファクタリングが登場。

いろいろ直していった結果、ごちゃごちゃになったソースコードを、どこかで、「えいやっ」ときれいにする作業です。

プログラムの動作が変わらないように注意しつつ、他の人が見てもわかりやすいように微調整します。

リファクタリングは、やる意味ない作業なの？

「え？リファクタリングって、ソースコードを見やすくするだけだよね？やる意味あるの？」と思った人がいるとしたら、もっともです。

ここからは、ひよこSEの主観も大いに入りますが、お付き合いください(*´ω｀)。

何をどうやって修正するのかを決めておかないと永遠に終わらない

まず、何をどうやって修正するのかを、先に決めておく必要があります。

変数名を変える(int aaa = 0; のように、”aaa”みたいな意味不明な、変数名が使われているのを直す)だけにするのか？

それとも、似たような処理が何回も、べた書きされているところを、関数にするなりして、簡略化するのか？

• ソースコードの「どの部分を？」
• 修正手順は、「どうやって？」（ツールをつかうのか？人力か？）
• 「どの程度、時間をかける？」

これらを先に決めておかないと、リファクタリングは極論、永遠にできてしまうので、終わりのない作業になります。

【重要】デグレを発生させたら（直して動作が変わったら）意味ない

それと、ここが肝心なのですが、リファクタリングした結果、直す前と直した後で、動作が変わったら意味ないです。

リファクタリングは、単に人の目で見やすくする作業なので、動作が変わるのは言語道断。

きちんとリファクタリングやソースの構造の全体を理解している人以外に、お任せしちゃダメです(´▽｀*)。

いわゆる「デグレ」（「直す前の方が良かったんじゃね？」的なやつ。「デグレート」が正式名）を起こしたら、文字通り、「やらないほうがよかったね」ということになります。

デメリットもあるし、必要な作業なのか？と言われると正直、微妙

リファクタリングは、後で読む人のことを考えて「ソースが見やすくする」と言う意味では、メリットがあるのも事実。

キレイにするだけとはいえ、別の見方をすると、「すでに動くことがわかってるプログラムを修正する」というリスクがあります。

「時間をかけてまで、やるべき作業なのか？」と言われれば、正直、微妙なところ。

ひよこSEの経験でいえば、「バグ（不具合）が見つかった『ついで』に、個人の裁量でできるならやってくれ。時間かけて、改めてやらんから」みたいな文化のところでしか、お仕事したことないですね(*´ω｀)。

まとめ

リファクタリングときたら、プログラムの動きを変えずにソースコードをきれいにする作業のこと。

なにか必要な理由があって、定期的にメンテナンスするイメージです。

やるのであれば、「直す前の方がよかったね」的な、「デグレ」（デグレート）だけは要注意くらいに思ってくださいまし(-_-;)。