一般的に「リファクタリング」とは、ここでいう局所的なコードベースリファクタリングのことを指します。しかし、レガシーシステムの品質の状況によっては、問題は局所的な範囲にとどまらず、広範囲にリファクタリングをすることになります。局所的なものと違い、コードレベルの詳細度でいきなり始めるのではなく、設計レベルで改善を検討していきます。
同じ「広範囲な設計改善リファクタリング」でも、「意味論に踏み込む」場合と「機械的」に実施する場合では、やるべきことが大きく変わります。
「意味論に踏み込む」場合、アーキテクチャを形成しているそれぞれのモジュールの意味を考えたうえで、本来あるべき形に改善していきます。
一方、「機械的」な場合は、モジュールの意味を考えず、機械的に「凝集度」を高め「結合度」を下げる方向に、設計を改善していきます。
前者は、今後の保守開発において人が関与する余地が大きく、理解性を上げることが保守品質の確保につながる場合に有効です。後者は、今後の保守開発においては、移植や少しの手直しだけを計画している場合に有効です。
下図は、グローバルデータによるモジュール間結合の問題を、「機械的」に設計改善する例です。意味論に踏み込まず、凝集度と結合度だけに着目することで、このように改善できます。
![局所的な「リファクタリング」と違い、広範囲に「リファクタリング」する場合には設計レベルで改善検討が必要|【把握した問題】グローバルデータを介して、各モジュールが複雑に結合している。グローバルデータの変更が、広範囲に影響を及ぼすことが分かる。【問題点の整理】グローバルデータと、アクセスしているモジュールを分類し、水平方向(赤の破線)、垂直方向(青の破線) に分割する。一つのグローバルデータに、複数の意味を持つ部分(緑の波線)があるので、それも分類する。【目指すべき姿】整理した考え方に基づき、モジュール構成を変更。意味が混在しているグローバルデータは、二つに分割する。](img/kaizen/kikai.gif)
局所的なリファクタリングは、要素のインターフェイスを変えないため、変更箇所に対するブラックボックステストを行うことで機能の互換性が保証できます。一方、広範囲な設計改善では、設計改善後に一度フルテストをして、求められている要求と仕様を満足していることを確認する必要があります。
網羅的なフルテストを実施するためには、満たすべき要求と仕様をモレなく定義することが前提になります。要求と仕様をヌケモレなく記した文書がない場合には、リファクタリングと併せて、USDMなどを使用した要求の定義と仕様化をしっかりと行なう必要があります。