1. HOME
  2. ソリューション
  3. 失敗しないリファクタリングの進め方:課題発見から継続的改善までの実践ガイド

失敗しないリファクタリングの進め方:課題発見から継続的改善までの実践ガイド

「何が問題」で「なぜ問題」なのかを明確にし、
症状に応じた解決策を立案する

解決策を立案するためには、まず「何が問題」で「なぜ問題」なのかを明確にする必要があります。それを怠ると、見当違いな結果となってしまい、達成したい効果を得ることができません。問題を確実に掴んだうえで、症状に応じた解決策を立案します。

ここでは、ツリーマップから得られる「サイズが大きくて複雑な関数」の解決策を立案します。

下図は、「派生開発」で複数機種に対応したことで、問題が生じた関数の例です。

「派生開発」で機種が増えるにつれ、関数内部の機種による色分けは、徐々に複雑にまだらになっていく。このような関数は、複雑機種を共通化したのではなく、単に一本化・統合化しているだけといえる

問題は「肥大化・複雑化」、なぜ問題かは「バグの温床になる」から

上図のように、対応する機種が増えることによって作りこまれた「肥大化」と「複雑化」は、保守性を低下させます。例えばA機種のみに対する変更があった場合、このような「肥大化」した関数は、変更箇所を見つけることが難しく、また、変更箇所も分散しています。そして「複雑化」したことで、深いネストと入り組んだ制御構造を持つ関数は、誤った対応を誘発します。

解決先は「判断と実行の分離」

このようなケースでは、関数を分割することで、品質を改善することが可能です。まずは、機種ごとに処理を実行する部分を特定し、それを関数として切り出します。そして、それらを呼び出す関数を作ります。すなわち、機種の「判断」と、機種ごとの「実行」を分離します。こうすることで、特定機種への変更を局所化し、変更しやすいコードに改善することができます。

「派生開発」でA機種のみに変更が発生した場合、改善前では関数全体にわたって、A機種部分を探さなくてはならない。それに比べ、改善後では変更部分を探すのが簡単で、なおかつ変更が局所化される

「変更前のテスト」で目標として作りこむ“振舞い”を確認する

リファクタリング」の注意すべきことポイントの一つは「振る舞い」を変えないということです。そうすることにより、「リファクタリング」の影響を局所的にとどめることができます。

とはいえ、いきなりコードを変更したものを置き換えて実行するのは、危険を伴う可能性があります。まずは「リファクタリング」箇所とその周りのモジュールとのインタフェースを確認するためのテストプログラムを作成することから始めます。

「リファクタリング」のbefore/afterで振舞いを変えない

テストプログラムでは、「リファクタリング」対象の部分をブラックボックスとして、周りのモジュールとのインターフェイスについて、それぞれ正常値・異常値・境界値を入力した場合をテストします。

「リファクタリング」前にテストを実施し、テスト結果を保存しておきます。このテスト結果が、「リファクタリング」における振舞いの仕様となります。

【リファクタリングbeforeのプログラム】「リファクタリング」箇所と関係するモジュールとのインタフェースを抽出⇒【テストプログラム】関係するモジュールを模すテストプログラムを作成⇒【リファクタリングbeforeのプログラム】+【テストプログラム】=【変更前テスト結果】「リファクタリング」実施前のプログラムでテストした結果が、目指すべき振舞いの仕様となる

「振舞い」と「結果」を自働的に評価する

「④コードの変更」を実施した後、「⑤変更後のテスト」で振舞いが変わっていないことを確認します。下図はGoogle testフレームワークを使ったテストプログラムの例です。テストフレームワークでは、フレームワークが用意している仕組みを使って、単体テストを簡単に作成することができます。下図のように、フレームワークを使うことで、テスト結果も分かりやすく表示してくれます。

最終的に「⑥結果の評価」で「リファクタリング」の目標である保守性の問題が解決されていることを確認します。

⑤⑥の結果がNGだった場合は「②解決策の立案」もしくは「④コードの変更」に戻り、繰り返し「リファクタリング」を実施します。この繰り返しが煩わしいと、継続的に「リファクタリング」をしていく上で、大きなブレーキとなってしまいます。この煩わしさを解消するためには、CIフレームワークを使ったシステムで自働化することが有効です。

CIフレームワークを使ったシステムでは、「ビルド」「テスト」「静的解析」を自働的に実行することで、生産性を大幅に上げることができます。

冒頭で「リファクタリング」を踏みとどまらせている要因の一つとして「多忙」をあげました。本来「リファクタリング」は、日常的な開発の中で取り組むべきことです。できるだけ簡単かつ効率的に続けられる環境で実施することが、継続的に「リファクタリング」をしていくための大事なポイントといえます。

CI(継続的インテグレーション)フレームワークを使用して生産性を上げ、「リファクタリング」を日常的な開発の中で継続して実施できるように効率化する|テストプログラムを使用して「リファクタリングbeforeのプログラム」と「リファクタリングafterのプログラム」を実行してもテスト結果は変わらない

頑張ってるけど、ちっとも楽にならない…何で?

すぐに成果を出すために頑張ってるけど、自前ではもう限界

効果的だろうけど高額なコンサルには手がでない…

あなたに合う一番最適な解決方法を
エクスモーションがご提案いたします。

コンサルタントが教える成功の秘訣

シニアスペシャリスト 玉木淳治

品質が低下したレガシーコードの保守に頭を悩ませる開発現場のエンジニアは、みなさまざまな問題認識を持っています。問題を改善していくためには、現場での困りごとを発生させる要因となっているソフトウェア設計上の問題を、客観的事実による裏付けとともに明らかにしなければ、大きな改善効果は望めないのではないでしょうか。

「レガシーシステム」の可視化と改善のサービスでは、ソースコードの調査と現場エンジニアへのヒアリングを通し、設計の問題点を把握することからスタートし、ソフトウェア構造のあるべき姿を設計する支援や、「リファクタリング」を進めるためのプロセス設計・運用の支援まで、ソースコードの改善をトータルに支援いたします。

レガシーコードの品質にお困りの方は、ぜひ私たちにご相談ください。

玉木淳治

レガシーリファクタリングの関連サービス

適用支援

レガシーリファクタリング実施支援サービス

ソースコード診断による問題の把握から、あるべき姿への改善まで、設計技術支援とプロセス設計によって、レガシーコードの改善を総合的に支援します。

適用支援

要求仕様書作成サービス

「要求仕様書」を作成したいのに作成する工数が取れないといったお客様に向けて、エクスモーションが制御仕様書や機能仕様書などの既存資料の調査や開発者へのヒアリングを行って「要求仕様書」を作成します。

「リファクタリング」による品質改善についての理論を学び、問題発見・コードの変更・CIフレームワークを使ってのテストまでを実践する本格的トレーニングです。テスト自動化ツール「Google Test」とCIフレームワーク「Jenkins」を使用します。

レガシーリファクタリングに関する記事を見る

他のソリューションを見る

最新コラム