既存アプリケーションの更新

チームで既存のアプリケーションを更新する場合、その最初のタスクの 1 つはコードについて知ることです。チームで行う作業を見積もることができるようにするには、コード内の変更が必要な部分を識別し、変更の影響がどこまで波及するかを判断する必要があります。

チームで単体テストとシステム テストを作成し実行することで、加えた変更により悪影響が生じないようにすることができます。これらのテストがまだ存在しない場合は、チームで作成する必要があります。ただし、既存のアプリケーション全体を網羅する単体テストおよびシステム テストのセットを作成する必要はありません。コードの既存の構造と、加えようとする変更を理解することで、チームは、それらの変更によってアプリケーションに悪影響が生じないようにするために必要なテストの作成に焦点を合わせることができます。

既存のコードを更新する必要がある場合は、次の操作およびツールを利用することをお勧めします。

• 既存の構造について理解します。アーキテクチャ エクスプローラー、有向グラフ、および生成されたシーケンス図を使用して、主要なコンポーネントとそれらの依存関係を把握します。詳細については、「コードの視覚化および理解」を参照してください。

• 既存の動作と必要な変更を理解します。チームは、新しいストーリーについて詳しく話し合うときに、既存の動作について理解している必要があります。既存のストーリーに "as-is" (現状)、新しいストーリーに "to-be" (変更後) とタグ付けします。 これらのタグを、ファイル、フォルダー、およびモデル名の一部として使用します。

  モデルを使用してユーザー ストーリーを明確にすることができます。詳細については、「ユーザー ストーリーのモデリング」を参照してください。

• テストにより、動作を安定化します。自動テストまたは手動テストを追加して、以下を実現します。

  • 製品の既存の動作を理解できるようにする。

  • 製品の動作が変更される部分を明確にする。

  • 変更によって既存の機能が損なわれないようにする。

  詳細については、「早期および頻繁なテスト」を参照してください。

• レイヤー図を使用してアーキテクチャを安定化します。レイヤー図を作成して、以下を実現します。

  • 既存のコードの構造を理解できるようにする。

  • 既存のコード内の変更対象の領域を明確にする。

  • 意図しない依存関係を導入したり、不適切な場所に機能を配置したりして、変更によって無意識のうちに既存のアーキテクチャを損なうことがないようにする。

  詳細については、「レイヤー図によるアプリケーション構造の安定化」を参照してください。

• 必要な変更をストーリーとして記述し、ストーリーのコストを見積もって、それらを製品バックログに適切に配置します。コストを見積もるときは、当然ながら、既存のコードを更新するという事実を考慮します。それぞれの見積もりには、既存の設計を理解したり、自動テストを記述したりするのにかかる時間を含める必要があります。

  詳細については、「プロダクト バックログの作成または追加」を参照してください。

関連項目

『Working Effectively with Legacy Code (レガシー コード改善ガイド)』、Michael Feathers、Prentice Hall、2004。