オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

リファクタリングパターンとは (Joshua Kerievsky氏「リファクタリングの戦略と戦術」の講演から)

»

情報処理学会ソフトウェア工学研究会パターンワーキンググループの実践タスクの一環として開催されたJoshua Kerievsky氏の講演を聴講した。

講演ではソースコードの大規模なリファクタリングをうまく実施するための定石(典型的なパターン)を紹介していた。リファクタリングは保守性、可読性の向上を目的としたソースコードの整理であり、プログラムとしての振る舞いを変更せず整理する。リファクタリングパターンは、リファクタリングの定石であり、たとえば動作が誤っていないことを確認しながら少しずつ整理していく、というような方針を集め、文章化したものだ。

講演紹介ページの講演概要の後半にあるとおり、リファクタリングパターンは6個の戦略と6個の戦術から構成されていた。個々のパターンは際立って目新しいというものではないが、リファクタリングの方針として頭に置いておくと有益だろう。自身のリファクタリングを振り返っても「あ、あのパターンだ」と思い当たるものがあると思う。Kerievsky氏は書籍『パターン指向リファクタリング入門 - ソフトウエア設計を改善する27の作法』(原著: "Refactoring to Patterns")でJolt Awardを受賞している。

講演ではリファクタリングパターンを実際のソースコードと共に紹介されていた。講演では以下のような前提を置いている(一部、私の推測が含まれる)。

  • 長期にわたって保守を続けるソースコードを対象
  • テストコードが存在する(リファクタリング途中で誤った改変をしていないかを確認するための合否判定コードが存在する)
  • ユニットテスト用のフレームワークを利用
  • エディタ、IDE(講演ではEclipse)のリファクタリング支援機能を利用

導入

リファクタリングは、プログラムの振舞いをかえずに将来の保守性、拡張性を高めるための活動。リファクタリングの対象の多くはソースコード。たとえば、入出力バッファの最大値を定数定義しておき、バッファに関連する各所でその定義を参照しておけば、バッファを大きくしたいとき等に一括変更が安全かつ簡単にできる。

ただ、バージョンを重ねていく間に、当初は予想していなかったことが起こったり、より簡潔に書き直すことができるようなコードになる場合がある。講演では、紙に印刷すると28ページになってしまった1メソッド(C++で記述)の紹介があった。また、多くのソフトウェアでver.5までリファクタリングなしに改版が続けられると保守コストが非常に高くなって誰もさわりたくなくなる、という話も紹介されていた。

リファクタリングパターン

講演では、リファクタリング方針を2つの抽象レベルに分けて紹介していた。非常に大きなレベルの方針を「戦略」、もう少し具体的なものを「戦術」と呼んでいるそうだ。戦略には以下が含まれる(他にもある)。いずれも広範囲に広がる変更箇所を局所化して、漏れやミスを減らしつつ、リファクタリングするための方針だ。詳細は書籍「パターン指向リファクタリング入門(amazonへ)」に掲載されていると思うので、誤りがあれば書籍の情報を優先していただきたい。

  • 「Parallel Change」
    変更箇所が多数ある場合に、リファクタリング前のコードとリファクタリング後のコードを同居させ、1箇所ずつ変更するごとにテストコードで確認しながらリファクタリング後のコードへ移行させていく。
  • 「Narrowed Change」
    まず、変更による影響が少なくなるよう変更を局所化、テストコードで問題がないことを確認、その上で変更する。
  • 「Graceful Retreat」
    リファクタリングに失敗したと思ったら、リファクタリングの開始前の状態に完全に戻して(変更をundoして)一から出直す。
  • 「Preparing for Change」
    変更前コードを変更しやすく、かつ変更の影響範囲が小さくなるように前準備し、その後実際の変更を加える。

戦術はもう少し具体性が高い。以下は戦術に含まれる(戦術は他にもある)。

  • 「Inline then extract」
    特定のクラスでしか使われていない、あるメソッドをリファクタリング機能を使って、いったんインライン展開し、その後、抽出機能を使って1つのメソッドにまとめる。
  • 「Encapsulated Dependency 」
    カプセル化(getter, setterの定義とアクセス修飾子の変更)によって影響範囲を小さくする。(そのあと、変更する)

これらは、変更箇所や変更規模が大きなリファクタリングをする際に役立つ。言われてみれば当たり前かもしれないけれども、選択肢の1つとして頭にいれておくとハマらないという典型的なものといえる。

その他の情報

講演概要

講演内容に特に機密はなさそうだったので、とりまとめをされていた鷲崎先生と相談して、Twitterのハッシュタグを#PWG_JKとした。http://twitter.com/#search?q=%23PWG_JK で読める。

shiumachi氏がブログ「Joshua Kerievsky 氏講演会「リファクタリングの戦略と戦術」を書かれている。具体例が多くわかりやすい。

Comment(0)