asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

Large Refactorings


Martin Lippert and Stephen Roock

Refactoring in Large Software Projects

John Wiley & Sons Inc (2006/5/28)

より、ラージリファクタリング(Large Refactoring)について。


ファウラーのコードレベルの ベーシックリファクタリング(Basic Refactoring)ではなく、アーキテクチャレベルのリファクタリングのことを、ラージ(大規模)リファクタリングと呼ばれてるっぽい。

ラージリファクタリング必要となる理由はなにか? この本では、いくつかあげられている(以下は個人的解釈であって厳密な翻訳ではない)。

  • 小さなリファクタリングのサボり:小さなリファクタリングによってデザインを継続的に改善してない。そのため、デザイン上の小さな欠点が積もり積もって、大規模な再構成が必要となってしまう。

  • アーキテクチャの不吉な匂い(architecture smells)の出現:アーキテクチャの不吉な匂いが徐々に現れる。アーキテクチャの不吉な匂とは、アーキテクチャレベルでの問題を示す匂い。アーキテクチャの不吉な匂いに対処しようとすると、小さな基本的にはリファクタリングがサポートするスコープを超える。

  • 要求変化:新しい機能(フィーチャ)の追加や要求の変化が、ラージリファクタリングを要求する。機能追加のいくつかは、簡単に追加できたり、簡単なリファクタリングにより追加できるが、場合によっては、大きな再構成が必要。


ラージリファクタリングの正確な定義は難しいらしいけど、この本では、次のような特徴を持つのがラージリファクタリングだといっている。

  • 期間:ラージリファクタリングは、一日以上に及ぶ。
  • チーム:ラージリファクタリングは、チーム全体に影響する。
  • 安全性(Unsafety):安全なベーシックリファクタリングで完全には置き換えられない。追加的な危険な安全でない修正が必要。


この特徴だと、ベーシックリファクタリングとラージリファクタリングのの正確な区別は難しい、と書かれてるけど、色々理由も書いてる。たとえば、メソッド名の変更は、大きなプロジェクトだと、一日以上かかるかもしれないし、チーム全体に影響するかもしれない。けど、単に「メソッドの変更」のリファクタリングにより実現できる。もし、開発環境がこのリファクタリングをサポートしてるのなら、数分で実現可能。


ラージリファクタリングは、普段の小さな基本的なリファクタリングを継続的にやることで解決できるか? この本によるとそうもいかないらしい。

一つは、要求に関する理由のため。新しい要求によっては、現在の構造では対処できないかもしれない。

さらには、アプリケーション領域をうまく理解できていなかったがゆえに、デザインを大幅に変える必要があるかもしれない。

tokuda さんも書いているように、デザインは、人間的な側面の理由が元で変化する。

  • 経験:経験ある従業員は、彼らのドメイン知識をベースにして、より良いデザインを作る可能性がある。
  • 新しい展望:新しいプロジェクトメンバーは、あるデザインがどう構成されるのかついて異なるアイデアを持っていることがよくある。
  • 実験:適切なデザインに達するには、異なるデザインパスを探索することが要求されるかもしれない。


そのため、ラージリファクタリングを避けることは困難、と本では言っている(本ではもうちょっと詳しく説明されているので参照)。

さらには、アーキテクチャの違反が簡単に起こってしまうことも関係する。


以下は上の本の話を基に感想。

結局のところ、システムの再構築、つまり、デザイン構造の変化が避けられない、あるいは、健全に保つのが難しいのは、二つがあるきがする。あるいは、この問題を考えるに当たって、前提としなければならないのは、以下のことだと思う。

  1. 要求変化の不可避:要求変化は避けられない。要求は変化する。

  2. 完全なデザインは実現困難:

    1. 困難なのは、一つは、要求が変化し、そのの変化は完全には予測できないため。したがって、今ある要求 に対しては、良いデザインを生み出すことはできたとしても、要求変化によって、良いデザインの 向きが変わる

    2. もう一つは、そもそも今ある要求に対してさえ、良いデザインを生み出すのは困難。これは、アプリケーションドメインの理解不足に伴う理由などによる。



これに関係する話は、じゃあ、モジュール化の技術やテクニックは、この文脈でどんな役割を担っているのか、ということ。

新しいモジュール化の技術(たとえばアスペクト指向プログラミング)の基では、従来の良いデザイン(たとえばデザインパターン)は、必ずしもよいデザイン or 局所的に最適なデザインとは限らなくなる。むしろ、コードの不吉な匂いとして捉えることができるかもしれない。実際、オブジェクト指向によるデザインパターンの実装を、アスペクト指向や他のモジュール化技術が提供する言語機構を用いてで書き直す(リファクタリング)ということが行われている。

つまるところ、現在のモジュール化技術は、不十分だともいえる。では、全体的に、モジュール化技術の進歩は、何を意味しているのか。

モジュール化の技術の進歩によって、ラージリファクタリングが必要な場合は減少するのか。

ラージリファクタリングは、アーキテクチャレベルでの問題をなんとかするためのテクニック。言語として、アーキテクチャレベルの抽象化の方法を提供する言語もある。たとえば、ArchJava など。このような言語を使えば、ラージリファクタリングが必要なケースは、少なくなって、ベーシックなリファクタリングを継続的に繰り返すだけでシステムを進化させていけるのか。
スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/26-eb631db2
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。