　プログラムを開発しているときに、「この依存性は変だな」と感じるときがある。

　そのようなときは、doxygen とgraphviz でinclude の依存性を確認しよう。ヘッダファイルで宣言されている内容を知るべき範囲以上に、そのヘッダファイルのincludeが波及していないか。
　「動けばいいんだ」というスタンスのコーディングをしていると、単体テストさえ「動かない」コードができあがる。

###危険な兆候

ヘッダファイルのincludeがソースコード全体に広く深く広がっている。
名前空間の依存関係が、相互にお互いを利用する関係になっている。
ヘッダファイル名から予想される範囲を超えて、ヘッダファイルの依存関係が広がっている。

その結果「単体テストしようとすると、結局全体のコードをlinkの対象に含めなくてはならなくなった」などという状況が発生しやすくなります。開発者は、どのコードは○○のモジュールには本来関係しないはずということを知っているでしょう。そのようなときに、何が依存性を招いてしまったのかを確かめます。

###対策の手順

このモジュールは "something.h" のヘッダを本来必要としない設計であるべき思う。
そのモジュールの中の#include "something.h"の行をコメント化してみる。
そのとき見つからなくて、ビルドエラーを生じたマクロ名を調べてみる。
それが、"something.h" の大半だったら、必要なincludeです。
それが、"something.h"のごく少数の宣言だったら、something.h からbar.h (仮名)として切り出して、#include "bar.h"　に置き換える。

この手法で、"something.h"をincludeするモジュールの範囲が広すぎるのを解消することができます。
　

###Doxyfileの書き方
それでは、自分の関わっているソースコードに危険な兆候が生じていないかを知るためにdoxygenでDoxyfileに次の行を含めておきます。

INCLUDE_GRAPH          = YES
INCLUDED_BY_GRAPH      = YES

CALL_GRAPH が YES であれば、各関数が　　　直接・間接に呼び出す関数を示す、呼び出し関係図が描画されます。
CALLER_GRAPH が YES であれば、各関数を　　　直接・間接に呼び出す関数を示す、被呼び出し関係図が描画されます。

[http://www.doxygen.jp/]
(http://www.doxygen.jp/diagrams.html)から引用

こうすることで、依存性の広がりを抑えて、単体テストをしやすいコードに少しづつ変えていくことができます。

参考にしたURL
Doxygen を使おう

[doxygen+graphvizでファイルの依存関係をグラフ化]
(http://d.hatena.ne.jp/heisseswasser/20110322/1300771800)

How to create header include graph using Doxygen