大規模ソフトウェアの効率的な理解（その4）

巨視的、微視的な理解

大規模ソフトウェアを理解する視点として、巨視的な理解、微視的な理解というのがある。巨視的な理解では、ソフトウェアをトップダウンに全体像から細部へと理解の道筋をたどる。一方、微視的な理解では、逆に細部から全体像へとボトムアップな理解の道筋をとおる。

規模の理解というのは、典型的な巨視的な理解の手法であり、ソースコードの解析は微視的な手法である。どちらも重要な視点で、それぞれの手法をバランスよく利用する必要がある。

大規模ソフトウェアの場合、微視的な視点からスタートすると、その規模のため、時間がおそろしくかかるという特徴があるので、最初は、巨視的な理解からはじめるのが王道である。その理解のプロセスの中で、興味のあるサブコンポーネント(論理的あるいは物理的な部分)へ到達したとして、そのサブコンポーネントの理解は徹底的に微視的な視点からはいるという方法もある。

例えば、あるソフトウェアのバグ修正などという作業の場合、ある程度の巨視的な理解の上、どの部分でバグが発生しているかを同定した後は、ソースコードレベル(微視的な)の理解をしつつデバッグをするというプロセスになる。

またコードリーディングは典型的な微視的な理解の方法論である。(ひらメソッド、コードブログなども参考にされたい)

巨視的理解、微視的理解それぞれに必要なテクニックやツールというのがあるので、それについてもプロのプログラマとしては十分訓練しておく必要がある。

巨視的な理解    規模の把握(ファイル数、行数など)、ディレクトリ構造、ドキュメントの精査、プロジェクトのポータルサイトの確認(サイトマップ)、メーリングリスト、掲示板等コミュニティサイトの確認、名前付け規約の確認、ソースコード管理システム、バグ管理システム、

微視的な理解    ソースコード、ソースコードリファレンス、ChangeLog、バグデータベース、ソースコード管理システム(バージョン間の差分)、検索エンジン、メーリングリスト

トラブルシューティングの場合、前提条件としてあるソフトウェアについての巨視的理解については、ある程度おわっているとして、いきなり微視的な作業からはじまる。例えば、ある不具合についてバグデータベースを検索し、同様の不具合があるのかないのかの調査、エラーメッセージを検索エンジンで調査するなどのフェーズがある。問題を再現したら、デバッガを利用しつつソースコードの解析、分析などをしながら問題点の詳細な理解などをしていく。その時に必要な道具立てもいろいろかわってくる。

このようなツールと手法あるいはプロセスについては明文化した教科書がないので、各人がそれぞれのスタイルで長年の経験のなかで培っている。今回あえて自分のプロセスを公開するのは、このことによって、多くの人に参考にしてもらうとともにさらなる改良をほどこしたいと思っているからである。それがインターネット時代あるいはオープンソース(バザールモデル)の基本的なスタイルであるからだ。

公開することによって進化する方法論といっても差し支えない。
読者諸氏のコメント、トラックバックなどを強く期待するところである。

それぞれのツールと手法についてはまた別途記す。