タイムリーな修理を怠ることで再構築が必要になる
—Richard Whately

リファクタリングの概要

ソフトウェア開発の目的はユーザーと利害関係者に最新のビジネス価値を納品することである。ビジネスとユーザーパラダイムの進化に重ね、不断の技術変化がビジネス価値の維持と増加への障害となる。未来へ続く道は2つある:

  • 既存システムに、フィーチャーを追加し続け、最終的に保守不能な「破棄」状態になる。
  • 継続的にシステムを更新し、現在のビジネス上の価値だけではなく、今後のビジネスの価値を効率よく提供するための基盤を提供する。

2番目の選択肢がアジャイルなやり方である。このモデルを利用し、企業のソフトウェア資産における投資の耐用年数を可能な限り延長することができる。また、ユーザーはこの先何年も価値のフローを体験し続けることができる。ソフトウェアの開発や保守に役に立つ重要なアジャイル手法の1つが「リファクタリング」である。このページでは、チームバックログ項目とするリファクタリング作業のさまざまな側面をカバーする。

詳細

リファクタリングとは

図1はリファクタリングのエッセンスを示した。リファクタリングの本質は、モジュール、メソッド、プログラムのようなものを、その外観、機能が変更しない方法で更新することにある。モジュールの機能を変更する可能性のあるプログラムの更新とは対照的に異なっている。

図1. リファクタリング作業は、より大きなものに、更新のための独立された環境である

図1. リファクタリング作業は、より大きなものに、更新のための独立された環境である

例えば、リファクタリング作業は処理速度の増加や異なる出所からの内部データの取り込み、あるいはセキュリティに関する問題のようなことを対処する。
リファクタリング作業の1種には、コードをより効率的で、より保守しやすく、さらに読みやすくするために、コードのいくつかの側面をすっきりとしたものにすることが含まれる。エンドユーザーや顧客が、応答時間が減少したことを除いて、実質的な変化を経験しない。期待する目的が正しく達成できたことを検証するために、各変更後に直ちにテストすることはリファクタリングの原則である。より大きな目的を達成するために、リファクタリング作業は一連のマイクロリファクタリング作業に分割されてもよい。正確さを保証するために、逐次に各変更に対しテストをしなければならない。この反復プロセスは、任意の段階でソフトウェアの完全性を維持し、実証する。必然的にソフトウェアの保守性を高める。

リファクタリングの役割

ファクタリングは、モジュールの外部に副作用を引き起こすことなく、任意規模のリリースした(テストされ受け入れ済み)システムにモジュールを保守するためのグローバルに安全な方法である。リファクタリングが安全である理由は、そのプロセスに反復テストが含まれているからである。この反復テストは、リファクタリングの結果を環境(通常影響されたモジュール。しかし、リファクタリングの結果が共有されることが可能である)にリリースする前に、満たされる必要がある。

リファクタリングの重要性

リファクタリングは、日次スタンドアップや反復デモなどと同じように、アジャイルにとっては不可欠である。このように、リファクタリングは、アジャイル開発の技能と科学の具体的な部分であり、当然ながら、この短い記事では表面に触れるだけである。アジャイルチームは、この重要なトピックに関する以下の文章の一部またはすべてを読んで、議論するのが賢明だろう。アジャイル開発は「事前に大量の設計(BUFD)」プロセスを避けるようにするので、システムは、新しいユーザーニーズや新興技術要素が発見されると、急速に進化する必要がある。

リファクタリングの管理

SAFeは、リファクタリングを含め、すべての作業の可視化を保つことの重要性を強調する。ユーザー価値のある作業と同じ、リファクタリング作業も組織のすべてのレベルで、計画され、見積もりされ、優先順位付けられなければならない。ポートフォリオレベルでは、アーキテクチャーエピックカンバンアーキテクチャーエピックのフローを確立する。これによって、今後の機能のためのアーキテクチャー滑走路を構築する。アジャイルリリース列車は、通常特定のシステムに限定され、1つのプログラムインクリメント(PI)で完成しなければならないような新しいアーキテクチャーフィーチャーを消費する。

一番下のチームレベルで、これらの大きなバックログ項目がリファクタリング作業に分割され、1つのアジャイルチームによって、1つの反復内で実装できる特殊なチームバックログ項目となる。チームは自分達のコード資産に一番近いので、ソリューションや改善しなければならない領域へのアイデアは常にたくさんあるだろう。

より高いレベルでは、ビジネス責任者プロダクト管理者及びプロダクトオーナーはリファクタリングのビジネス価値を理解しなければならない。それによって優先順位を決める。

リファクタリング作業の発生源

アジャイルではリファクタリングが重要な役割を担う。リファクタリング作業は、さまざまなところから発生し、プログラムとチームのパフォーマンスの多くの側面をサポートする。図2はプログラムの各方向からのリファクタリング作業の発生源を示す。

図2. リファクタリング作業の可能な発生源

図2. リファクタリング作業の可能な発生源

リファクタリング作業は、ビジネスフィーチャーから要求されることができる。また、アーキテクチャーフィーチャーとして定義されている大規模なリファクタリング取り組みの一部とすることができる。ユーザーストーリーも、コードのいくつかのリファクタリングを要する場合があり、最終に蓄積された技術的負債がチームにリファクタリング作業をバックログに入れることを決心させるかもしれない。したがって、リファクタリング作業は意図的なアーキテクチャーと創発的な設計の両方のためのものである。場合によって、非機能要求(NFR)によって必要とすることもあるかもしれない。チームのリファクタリングへの努力は、特定のリファクタリングストーリーの形式で提供されていないことを強調することが重要である。それらの多くは、「インライン」クリーンアップ作業である必要があり、ユーザーストーリーを実装しながら行われなければならない。このような作業は、対応するストーリーの見積もりに考慮すべきである。(参考文献の[1]、[2]、[3]に記載する継続的リファクタリングテクニックを参照)。具体的なリファクタリング作業は再設計の大部分を表す。この作業は独立したバックログ項目として計画され、追跡される必要がある。

リファクタリング作業の定義と見積もり

ユーザーストーリーの適切な定義と見積もりは難しい。リファクタリングは少なくとも同じレベルの難しさがある。1つのリファクタリングは複数のシステム振る舞いのフローを変え得るので、これは自然なことである。複雑性を対処するために、以下の方法が役に立つ。

  • 過去の反復過程では異なる人が別のユーザーストーリーを実装していたので、また見積もりしたかもしれないので、リファクタリング作業のグループ分析と見積もりを用いる。
  • 各リファクタリング作業のため、短い設計ワークショップを開催する
    • 短くする(10-30分)
    • ホワイトボードを利用する
    • 抽象な文章を避ける
    • これから実施するリファクタリングに関して、内部システムの振る舞いとインタフェースの具体例を用いて議論する
    • 既存のモデルを利用し、システムのさまざまな姿を示す
  • 潜在的な代替案とその影響を考える
リファクタリング作業終了時にどのような価値が達成できるかを理解するのは常に重要である。チームが理想的に「…それにより…」のストーリー形式の部分を利用し、関連する価値の共通の理解を促進する。以下の例がそれを示す(図3)
図3. リファクタリング作業の例

図3. リファクタリング作業の例

リファクタリング作業の分割

リファクタリング作業の分割は重要である。それはユーザーストーリーの分割と同様、インクリメンタルなアプローチのため、チームにより良い開発の流れを維持するために役に立つ。以下表1では、いくつかリファクタリング作業の分割に有用な方法とそれぞれの例を示す。

表1 リファクタリング作業を分割する方法

1. ユーザーシナリオやユーザーストーリーで分割する リファクタリング作業はストーリー毎、あるいはシナリオ毎の方式でインクリメンタルに実施する。あるいは、インクリメントのためのベースとして、機能領域を識別する。
DBのクエリを改善し、データのキャッシュを導入する。なぜならば、システムがより速く実行する …すべてのユーザー管理機能…カタログ閲覧機能 …チェックアウト機能をリファクタリングする
2. コンポーネントで分割する 1つのコンポーネントに関連するすべてをまずリファクタリングし、それから次のコンポーネントに移る。
DBのバッチ処理のインッデクス作成処理を変更する。なぜならば、平均的なWebページのために処理は少なくとも2-3倍速くなることができる …パースのため(パーサーコンポーネント)…エンティティ抽出のため(分析コンポーネント)のため …インデックスに保存のため(インデックスコンポーネント)
3. インタフェース/実装 ステップ1として新しいインタフェースを作成し、古い機能をラップアップする。ステップ2として、機能自身のリファクタリング作業を実施する
すべてのパース用のパラメータを抽出し、1つのXML設定ファイルに入れる。なぜならば、コード変更せずに処理をより簡単に調整できる …PINGIDプロトコルサーバーをインストールし、モック識別プロバイダを用いてテストする…任意の形式のファイルから設定を読み込む…特定の構造やスキーマ検証をサポートするための設定機能をリファクタリングする
4. コンポーネントの絞り込み すべて1つのコンポーネントの機能がインクリメンタルに他のコンポーネントへ移動する。すべてが移動された後、そのコンポーネントを削除する。
カスタム検索インデックスを使用してデータベースを置き換える。なぜならば、インデックスの作成と検索の性能が10?20倍を改善できる …まずインデックスデータをカスタム検索へ移動する …エンティティ辞書を移動する
5. インラインリファクタリング/抽出 インラインで現在のところで機能をリファクタリングする。その後、機能を抽出し、コンポーネントやクラスもしくはメソッド/ファンクションにカプセル化する。
現在のアドホックパースを文法ベースの機能で置き換える。なぜならば、パースルールの変更はより簡単になるし、かつコーディングしない。 …文法定義を利用するためコード(現行)をリファクタリングする…すべての文法関連の機能を抽出し、文法エンジンに入れる

受け入れ基準とデモ可能性

システム再設計において非常に共通している曖昧さを対処するため、リファクタリング作業の受け入れ基準を定義することは特に重要である。次の例は、受け入れ基準に反映した特定の側面を示す。そうしないと見逃したり誤解されたりする可能性がある。

図4. リファクタリング作業のために受け入れ基準の例

図4. リファクタリング作業のために受け入れ基準の例

ユーザーストーリーや技術ストーリーの場合と同じ、受け入れテスト基準は分割の基礎として非常に頻繁的に利用されることができる。このようなリファクタリングの分割は、上記の方法の一部と重複し、より深いコンテキスト依存分割能力を提供することができる。図3の第1ステップは「… デバッグロギングなしで、辞書への1つのクエリを使用し、同期設定不可能なバッチ処理を行う」となり、次は「…ファイルからバッチのサイズを読み取る機能を追加する」となる。第3ステップは「非同期的に項目を処理する」となり、最後に「デバッグロギング機能を追加する」となる。各反復後に、アジャイルチームは作業の結果をデモする。これはすべてのバックログ項目に適用され、リファクタリング作業にも例外なし。UIを持つユーザーストーリーか、システム設計の単なる改良のリファクタリング作業かに関わらず、優秀なアジャイルチームはすべてがデモできることを知っている。だから、上記の例(図3)の場合、チームは恐らく以下をデモすることを望むだろう。

  1. 以前のベンチマークと比較し、いくつかのWebページ上で大幅に低減した処理時間
  2. 処理時間のバッチサイズへの依存性。バッチサイズはファイルから設定できる
  3. 非同期処理のためのわずかなコード
  4. 上記すべての操作を捉えるデバッグログファイル
  5. バッチ毎に辞書へのクエリの数(ログファイルから)

これらのいくつかは、利害関係者にとって興味があることは容易にわかる(#1のような)。その他は、コードの内部構造に関する情報を即時に共有するので、チームにとって特に貴重である。この点に関して、プロダクトオーナーはより良くチームと認識を共有し、リファクタリングの必要性をより深く理解しはじめる。

チームのスキルと文化

アジャイル企業では、リファクタリングはチームの必須なスキルである。従って、リアクタリング作業はチームバックログ上に定期的に表すべきである。また、ストーリー見積もり時にもインラインリファクタリングを織り込まなければならない。チーム内、あるいはチーム横断にリファクタリングスキルの共有は大事である。リファクタリング作業の定義、見積もり、分割及び受け入れ基準の定義に関して、スクラムマスターは自分のチームが効率的なアプローチを把握するために、支援をしなければならない。同時に、システム設計技能コミュニティー(CoP)はリファクタリングテクニックに大いに注意しなければならない。プロダクトオーナーは、バックログでリファクタリング作業を洗練化し、リファクタリングの価値を受け入れることができなければならない。


さらに知りたい場合

[1] Fowler, Martin and others. Refactoring: Improving the Design of Existing Code.Boston, MA: Addison-Wesley, 1999. (邦訳:リファクタリング―プログラムの体質改善テクニック、ピアソンエデュケーション、2000)

[2] Martin, Robert. Clean Code: A Handbook of Agile Software Craftsmanship. Upper Saddle River, NJ: Prentice Hall, 2008. (邦訳:Clean Code アジャイルソフトウェア達人の技、アスキー・メディアワークス、2009)

[3] Wake, William. Refactoring Workbook. Boston, MA:Addison-Wesley, 2003.

Last update: 15 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.