Subscribed unsubscribe Subscribe Subscribe

リファクタリングを読んで。

リファクタリングについて

リファクタリングとは、プログラムの機能を変えずに、設計と実装を改善することです。 その目的は主に、現存するプログラムのscalability(拡張性)やMaintainability(保守性)を高めることです。 しかし、それがなぜ重要なのかを説明することや、実践することは難しく、すでに定着していない場合は導入がし辛いように思います。 現に現場の実務プロセスでは、バグ改修以外の理由でのコードの改変が認められていないプロジェクトも存在します。 それでもなお、僕はリファクタリングが開発を行う上で有用な考え方だと思います。 それは少し学習しただけでも、以下のような幾つかの気づきがあったからです。

リファクタリングの学習を始めたことによる気づき

  • 良い設計の適用方法のガイドラインになる。
  • IDEなどのツールの活用方法の理解を助ける。
  • テストを書く習慣づけを身につけることができる。

これらはあくまで学習と技術力向上という観点で見たリファクタリングのメリットです。 実際の開発でどのように役に立つかは、まだ経験がないため、その他の方へ譲ります。 つまり、プログラミング上での作法がなぜ重要なのか、それに反するものにどう対処すれば良いのかは学べます。

作法とリファクタリングの関係

例えば変数の命名には以下のような作法があります。 変数名は名詞で、省略せず、短く簡潔に意図を伝えるようにすること。

これを守ることで、同じ変数に対する複数回の代入は行いづらくなります。 なぜなら意味に反する値を入れるわけにはいかないからです。(プログラム上は出来ますが、論外です) すると、結果的にはそれによって式の結果を保持する一時変数が増えます。

ここで例えば、問い合わせによる一時変数の置き換えというリファクタリング手法を適用します。 式の結果を変数に格納するのではなく、式の結果を返すメソッドを作成し、それを利用する。というものです。 このメリットは、メソッドとする事で、その他のプログラムから利用できるようになる事です。

すると、必然的にメソッドが増えていきます。 そうなれば、クラスの抽出というリファクタリング手法が使えるかもしれません。

このように考えると作法が、これらの単純な設計上の問題を導き出すことがわかります。 このようにして、プログラムを書いている中で生まれる設計上の問題に対して、どう対処すべきかをリファクタリングの手法は教えてくれます。

実際のプロジェクトへの適用

個々人による開発能力を向上させることは、多かれ少なかれ全体へ影響を与えます。 上にあげたようにして、個人が良い設計を行なっていく。というような場合にはリファクタリングには大きな価値があると思います。 しかし、実際のプロジェクトへ抜本的に導入することは難しいかもしれません。

なぜならば、個々人の能力と取り組みに左右されることが大きいように思うからです。 それにあくまで拡張性と保守性への改善の取り組みであって、機能追加のような見える成果は出づらいからです。 しかし、よく整理されたプログラムは開発の速度へ影響を与えます。 開発期間中に要件が変わる場合、その場で拡張性が求められることもありえます。

日頃から、プログラマ個々人がすべき時にすることとして、徐々に始めるしかないのかもしれません。

まとめ

マーティン・ファウラーリファクタリングを読んで、実際に幾つかのテクニックを試してみて気づいたことをまとめました。 個人的に一番興味深かったことは、変更を加える際、既存のコードを残したままに変更を加えていた事です。 そうする事で、終始テストはグリーンのまま、レッドになった際は手順のミスが発覚します。 以前は、自分はいきなり破壊的な変更を加えるような事もあったため、安全な手順を踏んだ変更を加えるための手順と原則がわかった事は重要でした。