ソフトウェアの保守におけるアーキテクチャの理解 ～ Visual Studio ソリューションシナリオ
<< ”Visual Studio 2012 ソリューションシナリオ" では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>
ソフトウェアのライフサイクルについて考えると、その時間のほとんどは「開発」ではなく「保守」や「運用」に費やされることになります。ところで、保守を行う際に、開発を行ったチーム、メンバーがそのままプロジェクトに残っている、というプロジェクトはどの程度存在するのでしょうか？ほとんどの場合、開発プロジェクトにおいて開発を担当したメンバーは、プロジェクトが順調に進めば進むほど、運用、保守フェーズへの切り替えに伴いプロジェクトを卒業し、別のメンバーが運用、保守を担当することが多いのではないでしょうか？
今回のソリューションシナリオでは、ソフトウェアの保守を担当するチームが Visual Studio の機能を活用し、どのように保守に役立てることができるかを紹介します。
開発メンバーと異なるメンバーが保守を担当する場合、以下のような問題が起こりがちです。
- 設計ドキュメントに関して、設計フェーズで作成されたものが存在していたとしても、最終的にリリースされ、運用されているソフトウェアの状態をカバーしている最新かつ全体的な設計ドキュメントが存在しておらず、アーキテクチャの全体像がつかめない。
- 機能強化やデザインの改善のためにコードの変更を行ったところ、他の画面やロジックにおいて副作用が発生してしまい、ソフトウェア全体の整合性が崩れてしまう。
ソフトウェアをより長く、価値あるものとして活用するためには、保守作業を効率化し、変更によるリスクを下げつつ機能強化を積極的に行えるようにすることが銃重要です。
保守におけるこのような課題に対応するためには、以下のようなプラクティス（行動）が挙げられます。
ドキュメントではなくコードを中心に最新のアーキテクチャを理解しよう
開発プロジェクトにおける最終的な成果物は「ドキュメント」ではなく「ソフトウェア」あるいは「コード」そのものです。「コード」を素早く理解するために「ドキュメント」を活用することは重要ですが、本質的なアーキテクチャの理解には「コード」をそのものを活用するのが最も効率的です。
コード変更の前に副作用の範囲やリスクを正しく把握しよう
アーキテクチャに対する思い込みや仮定をもとにしてコードの変更を行ってしまうと、思わぬ副作用を引き起こす可能性があります。コード変更に関しては、単体テストを用意することで変更のリスクを低減させることができますので、変更前に十分な単体テストを用意しておき、コードの変更後にもそれらの単体テストが期待通りに「成功」となるかを確認しましょう。
Visual Studio ではコードを作成する際の支援だけでなく、アーキテクチャレベルでのコードの理解を支援し、副作用の少ないコードの改善を実現するための機能を提供しています。
プラクティス１：ドキュメントではなくコードを中心に最新のアーキテクチャを理解しよう
Visual Studio 2012 では、アーキテクチャの理解のために「依存関係グラフ」という機能を用意しています。この機能を活用すると、ソリューションやプロジェクトにおけるアセンブリ、名前空間、あるいはクラスごとの関係性をグラフとして視覚化することが可能です。
例えば、以下のスクリーンショットでは、”Tailspin Toys” というソリューションに含まれるアセンブリ(Dll)単位の依存性を表示したものです。
それぞれの情報は、さらにブレイクダウンして詳細情報を確認することが可能です。例えば、先ほどの DLL に含まれる名前空間とその関連情報を表示すると以下のような表示となります。
一方で、各メソッドやクラスといったコード側からアーキテクチャの理解を深めたい場合は同様に「コードマップ」の機能を活用することでコードの内容を視覚化することが可能です。例えは、以下の画面ショットでは、OrderLine クラスを中心に、このクラスに依存しているクラス(Order クラス等）とこのクラスが依存しているクラス（Product クラス）を視覚化し、また OrderLine クラスに含まれるメソッドやプロパティの関連を表示したものです。
先に紹介した「依存関係グラフ」においてもメソッド個々のレベルまで情報を視覚化することが可能ですので、併せて活用すると上位概念レベルでの依存関係と、実装レベルでの依存関係の両面からコードの理解が可能になります。
依存関係グラフやコードマップにおいて表示されているクラスやメソッドの情報はクリックすることで、実際のコードを表示し詳細を確認することが可能です。
また、ソリューション エクスプローラーにおいてはクラスやメソッドの粒度で呼び出し関係を整理することが可能です。例えば Cutomer クラスにおいて、「使用元」の表示を選択すると、
ソリューション エクスプローラー上に、Customer クラスを使用しているクラスと該当するメソッドが表示されます（下記の画面ショットの右側）。また、それぞれの該当箇所をクリックすることで、コードを確認することが可能です（画面ショットの左側）。
これらの機能を活用することで、既存のコードの内容を全体的なアーキテクチャから詳細へ、あるいは関心のあるメソッドから全体のアーキテクチャへ情報をつなぎ、確認することが可能になります。
プラクティス２：コード変更の前に副作用の範囲やリスクを正しく把握しよう
Visual Studio 2012 においては、コードを変更した際にその変更に伴い再度実行したほうがよいテストを「推奨されるテスト」としてリスト化する機能があります。
具体的にはテスト用のツールである Microsoft Test Manager において管理しているテスト情報において、「テストの影響」情報を収集するオプションを設定することにより適切な情報が収集、分析されるようになります。
実際にコード変更を行った場合には、コード変更前に Team Foundation Server でビルドされた内容と、コード変更後にビルドされた内容の差分をもとに、そこに関わるテスト ケースを表示します。
また、バグの改修などでコードの変更を行う場合、ソリューション内の “似たコード” を検索する機能を活用することもできます。
これは Visual Studio 2012 において任意のコードを選択した状態でメニューを表示し「ソリューション内で一致する複製を検索」機能を呼び出すことで実施可能です。
あらかじめこのような分析を行っておくことで、似たコードにもバグが潜んでいないかどうかをより積極的に確認することが可能になります。
今回のソリューションシナリオでは、ソフトウェアの保守を担当するチームが Visual Studio の機能を活用し、どのように保守に役立てることができるかを紹介しました。
ソリューションシナリオには、以下のシナリオがあります。
それでは！