リファクタリングのスヽメ
リファクタリングについて自分の理解があまかったため、どういうものかを説明し、実際におこなってみたので、その報告をしようとおもいます。
リファクタリングとは
リファクタリングとは プログラムの外部的振る舞い（動作）を変えることなく、内部構造としてのソースコードを変更することである。理解や修正がしやすいように整える目的で行われる。
リファクタリングのメリット・デメリット
では、リファクタリングのメリットはなんなのでしょう。リファクタリングするとなにがよくなるのでしょうか
- コードがよみすくなる
- バグをみつけやすくなる
- 機能追加をいれやすくなる
- 理解しやすい
- バグがへる
一見、いいことずくしのようにみえますが以下のようなデメリットもあります。
- コードをいじるため、あらたなバグがおこってしまう可能性がある
- わりと時間がかかる
個人的な感想ですが、慣れてないと時間を沢山費やしてしまう。
リファクタリングすべきコードとは？
リファクタリングの定義は分かったのですが、実際にどういうコードをリファクタリングするべきなのでしょうか。リファクタリングが必要なコードのことを「コードの臭い」といいます。以下はWikipediaに記載されている一例です。
- 重複したコード
同一あるいは同様のコードが複数箇所に存在 - 長すぎるメソッド
メソッド、関数、手続きが長くなりすぎている - 巨大なクラス
大きくなりすぎたクラス - 機能の横恋慕
他クラスのメソッドを過度に用いるクラス - 不適切な関係
他のクラスの実装の詳細に依存しているクラス - 相続拒否
基底クラスの規約が尊重されない形でのメソッドオーバーライド - 怠け者クラス
行うことが少なすぎるクラス - 重複メソッド
同一あるいは同様のメソッドが複数箇所に存在 - 不自然なクラス
簡潔な設計で十分なところに、過剰に複雑なデザインパターンの使用を強制する - 不適切な関係
クラス間の結合度が高く、privateがなくなる - コメント
コメントは多いが、よい説明になっていない
実際にリファクタリングしてみた
ここまで、リファクタリングの定義とコードの臭いについて述べてきたのですが、とりあえずやってみました。コードは自分が先日開発したアプリのソースの一部を実際にリファクタリングをしてみました。
リファクタリングした箇所を具体的に示していきます。
重複した変数を一つに
下のように似たような変数が沢山ならんでいるのですがそれをまとめました。Listを使ったら大分キレイになりました。
before
after
類似した初期化処理を一つに
先ほど変数をまとめたため変数の初期化も以下のようにループでまわせるようになりました。
before
after
重複した処理・メソッドをひとまとめに
先ほど変数をまとめたため管理が楽になりました。そのため似たような処理・メソッドををひとまとめにしました。
before
プログラム１(リファクタリング前)
プログラム２(リファクタリング前)
プログラム３(リファクタリング前)
after
プログラム１(リファクタリング後)
プログラム２(リファクタリング後)
プログラム３(リファクタリング後)
最後に全体のプログラムを以下にしめします。
まとめ
今回は自分のコードを用いてリファクタリングをしてみました。そしたらなんと500行だったプログラムが350行くらいまで縮小できました。それだけ無駄がおおかったということですね。もっとうまくリファクタリングできるとおもうのですが、自分ができる精一杯のことは出来た気がします。
最後に、実際にリファクタリングを行い学んだことを並べます。
- プログラムがみやすくなった
- リファクタリング中はこまめに実行すべき
- 機能を追加しやすい形になった
今まで混沌していた部分をキレイにしたことによって新しい機能を追加しても他のところを変更せずに追加できるようになった - 重複してきてるなーと感じたらリファクタリング
今回、一通りプログラムを完成させてから行ったため時間がとてもかかるため、段階的にリファクタリングをかけていくと効率もアップするとおもわれます。
ここまで、記事をよんでくださったみなさま、リファクタリングにかんしてもっとこうしたらいいんでねーのっていうのがあったら、面倒だとはおもいますがご指摘いただければ幸いです。
