リファクタリング

エクストリーム・プログラミングで知った概念、リファクタリングについてちょっとだけ。



リファクタリングとは、
「外部から見た振る舞いを変えることなく内部構造を改善すること。」
である。


建築でいったら、内装のリフォームみたいなものか？

・リファクタリングが必要な理由
リファクタリングが必要な理由は、

プログラミングは、基本的に複雑な作業である。よって、初めから最適な解でコーディングできるとは限らない。（プログラマの腕の差もある。）

仕様が変化したり、始めは見えなかった仕様が見えてきて、例外的な処理がどんどん増えてくる

仕様追加などが発生し、そのままのコードで対応しようとするとさらに複雑なコードが出来上がる。

複雑な作業であるが故、一発でよいものが出来る可能性が低い。そのため、最適な形に
作り直すという作業が必要になる。

最近流行の開発環境：Eclipseや、最新バージョンのVisualStudio(まだβ？)でも、リファクタリングの機能を持っている。



以下、経験談。

・その場で思いつく限り一番シンプルなやり方で実装せよ
何の本で読んだか忘れたのだが、こういう言葉があった。

それで、自分は以下のようなインクリメンタルな開発をするようになった。

動く→正しく動く→仕様が明確な形にする→保守性、拡張性を考慮した形にする→チューニング

ソフトウェアってのは動いてナンボなので、動いていることが確認できながらやるというのは
ストレスがたまらなくてよいです。

■動くこと
まず大まかな設計を行う。
そして、クリティカル・パスのみを実装し、自分の思いついた形で実装を行う。
エラー対処などは行わない。これにより、短時間で動くことが確認できる。
↓
■正しく動くこと
クリティカル・パス以外のものを実装し、エラーコードも追加する。
エラーも全体の流れを考慮し、どこにおけばよいか考えて置く。
そうすることによって、例外処理は最低限の形になってくる。
↓
■仕様が明確な形にする
この段階では重複した分岐などをまとめ、シンプルにする。そして、詳細動作設計図を描く。
大体動いていて確認できているので、設計が間違っていることも少ない。
↓
■保守性、拡張性を考慮した形にする
今後どういう仕様変更が発生するのか?を予想し、同じ動きのまま拡張できるように
しておく。
ここは、不変なものと変わるものを見極めることが必要。
まぁ、大体アルゴリズムとデータの分離がちゃんと出来ていればたいていはOKかな？
↓
■チューニング
最後に、パフォーマンスが悪いところがないかを見て、もし、悪いなら他の方法を考えてみる。
この最後のフェーズは、調べることはやるけど、大体実装することはないかな。。。

こんな感じ。

はじめから保守性、拡張性を考慮した形にすることって難しくって、時間もかかる。
でも、そうやって作らないと後で大変になる。
そのため、段階を踏んでインクリメンタルにプログラミングしてく。
一度に全てやらないほうが時間がかからない。一般的なことだとなんか逆っぽいんだけどね。
ソフトウェアの開発は順々に確認しながらやったほうが早くできる。


☆注意すべきところは、
・ちゃんと動作確認すること
・一度に2つの変更を行わないこと
・仕様変更と同時に変更しないこと（仕様変更・リファクタリングと、2段階にわける）

そうしないと、リファクタリングによって余計な不具合を入れてしまう。
この対処には、単体テストを行うってのが非常に有効になってくる。

まぁ、バージョン管理ツールがないとつらいと思うけど、いまどきソースコード管理ツール
使っていないところはなさそうだし。

＃今はこんな感じでプログラミングしてます。

リファクタリングの副次的なメリットとしては、「コーディング・設計能力が高まる」というのが
あると思う。

その理由は、
・問題を分けて考えられるので、考えるのが楽
・同じ仕様でも、複数の実装方法があるのが判ること
・自分で最適解を探すことにより、どうすればよくなるのかが判ってくること
・同じ仕様を追加するのに何度もコーディングして、そのぶん経験が深まること
・すばやいフィードバックにより学習効果が高まる

と、いうところから。

こうやって、複雑なものをシンプルにするというのが、自分のコーディングスタイルに
なって行きました。


XPの中では、一番好きなプラクティスかな。


■リファクタリングに関するリンク
リファクタリング-プログラムの体質改善テクニック
「不吉なにおい」はカナリ有名な言葉ですね。私は借りてぱらぱら読んだ程度ですが・・・。


すんげー長くなっちゃった。。。