リファクタリングとは
「リファクタリング」という本(新装版 p53)に書かれている用語で、以下のように定義されています。
外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること。
リファクタリングをするメリット
リファクタリングそのものは何も機能追加やバグ修正を行いません。 しかし、リファクタリングをすることによって、機能追加やバグ修正が容易になり、 長期的には品質と開発スピードの向上に繋がります。
リファクタリングのタイミング
リファクタリングは以下のタイミングで行うのが分かりやすいです。 なぜなら、リファクタリングをする際はテストが必須だからです。
- 機能追加の前段階
- バグ修正の前段階
これ以外にも簡単なものについては、コードを読んでておかしいと思った時点で やるのがいいと思います。
リファクタリングは常識
プログラミング言語によって多少変わりますが、 少なくとも、Javaでプログラミングをするなら、 リファクタリングを知らないのは論外と言っていいです。
なぜなら、リファクタリングを知ることで、これだけプログラミングのスタイルが変わるからです。
| リファクタリングを知る前 | リファクタリングを知る後 | リファクタリングによるメリット | |
|---|---|---|---|
| コードの変更 | できるだけ変更しない | 必要なら積極的に変更する | メンテナンスが容易になる |
| 良いコードと悪いコード | 動けば何でもいい | リファクタリングしやすいのが良いコード | メンテナンスが容易になる |
| 変数の命名 | 動けばなんでもいい | 「読みやすさ」を重視する | メンテナンスが容易になる |
| デザインパターン | 動けばなんでもいい | デザインパターンは良い指針になる | 設計力が向上する |
| 単体テスト | しない、できない | JUnitなどのフレームワークを使う | 品質が向上する |
- 「変化を受け入れる」という思考が身につく。逆に言えば、リファクタリングを知らない人は、「一度書いたコードは変更しない」という考えに固執しがちです。
- 良いコードと悪いコードの見分けがつくようになる。なぜなら、リファクタリングがしづらいコードはほとんどの場合、悪いコードだからです。
- 命名に気を配るようになる。基本的なリファクタリングの1つに、「メソッド名の変更」というものがあります。
- 「デザインパターン」を知るきっかけになる。リファクタリングは闇雲に行うのではなく、デザインパターンという良い指針に向かって行う事が多いです。
- テスト、特に単体テストを書く理由が理解できる。
リファクタリングを知らない人は、これらを学ぶ機会に恵まれているとは思えません。 技術者としては袋小路に入ってしまいます。 また、プログラマーでなくても、リファクタリングを知らない事で、 変化を拒絶してしまう人になってしまいます。
リファクタリングの難易度
リファクタリングは「振る舞いはそのまま」が原則ですが、 それが容易な場合と、注意が必要な場合があります。
Javaの場合例えば、以下のものはIDEを使えばほぼ100%安全です。
- コメントの削除(リファクタリングのカタログにはありませんが)
- ローカル変数のリネーム
- privateフィールドのリネーム
- privateメソッド名のリネーム
- メソッドの抽出
- if文の条件式の反転
一方で、publicメソッドのリネーム、クラス階層の見直しなど、 注意が必要なものもあります。
なぜこのようなことを書くのかというと、 リファクタリングができない人は、「何が安全か」の見極めが出来ていないからです。 何が安全かを見極めるためには、Java言語の知識が必要です。 その知識が足りない人は見極めが出来ず、必要以上に怖がり、良いプログラムが書けません。