#リファクタリング
１．プログラム改善について
プログラム開発はとても複雑な行為で、試行錯誤を行いながら進めます。
その方法はさまざまで、レビューを開いてどこを改善すべきか、このまま開発を進めてよいかなどを
お客さんに確認して進めたりします。
また、期限、締め切りが迫っているなどの理由で「好ましくないが手軽な書き方」をあえて
選択しなければいけないこともあるでしょう。
※期限を守ることを最大限努力してもダメな場合
ですから、意識せずに放っておくと開発中のプログラムはどんどん複雑になってしまいます。
後から見ると、自分でも「なんでこんなわかりにくいコードを書いたんだろう？」と思うことは、
熟練したエンジニアでも決して珍しくありません。
同じようなクラスをコピペで増やしていって後で修正が大変になる、などがその例ですね。
しかし複雑なコードになればなるほど修正も大変です。
複雑なプログラムほど最初は軽微なものでも、時間がたつとともにどんどん雪だるまのように
複雑さが増えて最後には手をつけられないようになります。
→そのためだけに凄腕のエンジニアを雇うとなれば企業も大変ですね。
そこで、時々コードを見直して改善をするリファクタリングという活動が推奨されています。
複雑なプログラムを・・・
＜放っておくと＞
・コードがぐちゃぐちゃでわけがわからなくなる
・作成者、設計者以外が見たときにわかりずらくなる
・処理設計から離れてしまい違うものになることもある
＜こまめに改善すると＞
・コードはいるもののみ残っているので見やすくなる
・他チームの人や作成者と設計者以外の人が見ても内容が入ってきやすい
・設計に即したものが完成する
２．リファクタリングとは
厳密には、リファクタリングとは「外部から見た動作、仕様を変えずに内部構造を改善すること」を
さします。
例えばtestクラスをリファクタリングする場合、testクラスを呼び出す別のクラスに大きな影響が及ぶような
修正(メソッドの動作内容が全く別のものになるような変更等)は行いません。
リファクタリングという言葉は特殊な書き方というよりは、活動のことを指しています。
リファクタリングという概念が生まれる前は、作成済みでいちど正常に動作したプログラムは
触らないほうが良いという考えが浸透していました。
なぜなら修正してバグが出た時に修正作業がプロジェクト全体に広がって収集がつかなくなる
可能性があるからです。
しかし、プログラム開発には仕様変更や要求が変わることは日常茶飯事であり、
そのためにリファクタリング活動が次第に広がっていきました。
３．代表的なリファクタリング活動
以下のようなものが代表的なリファクタリングです。
①重複部分を１か所にまとめる
コピペしたなどの理由で似たようなコード部分が複数の箇所に出てくる場合、
それを１つのメソッドにまとめて呼び出せるようにしたりします。
②メソッドやクラスを分割する
大きく複雑になりすぎたメソッドの一部を、別メソッドとして切り出します。
通常、privateメソッドとして切り出すことが多いでしょう。
③外部ライブラリや新しいJavaのバージョンの文法を利用する
たくさん行数を使って書いた処理も新しく登場した外部ライブラリや新しい文法を使うことで
シンプルになることがあります。
もちろんライブラリは使ってよいもののみ使用しましょう。
４．リファクタリングの注意点・デメリット
基本的に、リファクタリングはどんどん行ったほうが良い「良いこと」です。
しかし、リファクタリングを行うのも時間(=コスト)がかかります。
ですから、かかるコストを上回るメリットが得られそうにない場合は、
「保守性が低いコードであっても、あえてリファクタリングすべきでない」場合があります。
注意点① 納期直前はリファクタリングのメリットが得られにくい
期限が目の前まで迫っている状況でリファクタリングしても、そのあとすぐに製品が
完成してしまえば「修正が容易になる」というメリットを生かせません。
これは完璧にしてからリリースしたいと考えている筆者からするとあまりよくなさそうですが。
→やったほうが良いのでは・・
納期ギリギリだと要するにテストなど検証業務をきちんと行うほうが良いケースも多いということですね。
注意点② むやみにやらない、やりすぎない
テストと同様、リファクタリング活動もやろうと思えばきりがないような無限にできてしまう活動です。
それに、リファクタリング時点では完璧と思えるまで突き詰めて考えた設計も数か月後に見れば
最適でない可能性もあります。
時間は無限ではありませんので、コストや手間が無駄にならないよう、適度にリファクタリングを
行うのが大事ですね。