そのソフトウェア資産、ずっと使い続けられますか？：特集・現場で役立つリファクタリング（2/2 ページ）

長期間、改修を繰り返しながら、今なお現役で使い続けられているシステムはないだろうか。気が付けば設計担当者が去り、開発担当者が去り、ただ肥大化・複雑化・属人化したシステムだけが残され、運用担当者が何とかそれを維持し続けている。そんなシステムに対し、ある日、大幅な仕様変更・機能追加の命が下ったら……。

[竹森理奈（富士ソフト），MONOist]

※本記事はアフィリエイトプログラムによる収益を得ています

3．簡易リファクタリング

　A社で行った手法のように、仕様を意識せずにソースコードのみに着目して、未使用コードや類似コードの整理を行い、短期間でソースコードを改善するやり方を、ここでは仮に「簡易リファクタリング」と呼ぶことにします（2．で紹介した（3）の静的解析は不具合の改修に当たるので、リファクタリングには該当しませんが、併せて実施することで大きな効果を期待できます）。

　簡易ファクタリングであれば、短期間に低リスク・低コストでソースコードの軽量化を実現できます。特に、保守性の向上に効果があり、次期開発前の実施であれば、開発工程の短縮効果が見込まれます。

　また、短期間で取り組めるため、開発の合間で実施することも可能です。オフショアで製造したソフトウェアの品質に不安がある場合にも有効です。簡易リファクタリング実施後も、開発作業の中で継続的にリファクタリングすることも重要です。

　簡易リファクタリングの実施手順のおおまかな流れは以下の通りです。

1. ソースコードを分析する（未使用コードの分析、類似コードの分析、静的解析）
2. 分析結果に基づき、ソースコードを軽量化する
3. 簡易リファクタリング前後のソースコードの等価性を確認する

図1　簡易リファクタリングの流れ 【※画像クリックで拡大表示】

　分析に役立つツール類は、高価なものからフリーのものまで市場に多々存在していますし、最近では開発環境に静的解析や分析の機能が組み込まれているものもありますので、必要に応じて選択してください。

　なお、簡易リファクタリングの実施と併せて、関数一覧（関数仕様を含む場合もあり）、関数ツリー（呼び出し関係）、グローバル変数一覧（データ一覧）などをドキュメント化した場合、より大きな効果が期待できます。

　実際、簡易リファクタリングを実施した開発現場からは、以下のような感想が寄せられています。

母体規模が大きく品質も不安定であったが、潜在バグが減り、保守作業量が軽減した（A社）

当初計画より1カ月前倒しで完了できた。今までにない品質を確保できた（B社）

手を付けるのを躊躇していたレガシーシステムの改造の突破口になった（C社）

機能追加やバグ改修時に必要な工数を正確に見積もれるようになった（D社）

表1　簡易リファクタリング実施効果の一例

4．最後に……

　リファクタリングによって大きく改善できるシステムは、世の中にたくさん眠っています。既存のレガシーシステムをゼロから作り直すことは非現実的ですので、リファクタリングを行うことでソースコードを整理し、技術者にとっても、ソースコードにとってもストレスをなくし、健全な状態を保つことが大切です。

　皆さんの現場は、いかがでしょうか。次の3つのいずれかが該当したら、リファクタリングが必要なサインかもしれません。

1. 機能追加へのリスクが大きいと感じる
2. 保守作業へのコストが大きいと感じる
3. 品質向上の実現が難しいと感じる

　現在、保有するソフトウェア資産を安心して使い続けられますか？ リファクタリングを後回しにするのも“リスク”といえるでしょう。複雑なままのソースコードを再利用してからリファクタリングを実施すると、より費用が掛かります。改善すべきソースコードが増えてしまう前に、リファクタリングを検討してみましょう。万一、手を付けられないほど複雑化し過ぎたレガシーシステムをお持ちでしたら、簡易リファクタリングの実施をオススメします。