プログラムを開発しているときに、「この依存性は変だな」と感じるときがある。
そのようなときは、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 であれば、各関数を 直接・間接に呼び出す関数を示す、被呼び出し関係図が描画されます。
こうすることで、依存性の広がりを抑えて、単体テストをしやすいコードに少しづつ変えていくことができます。
参考にしたURL
Doxygen を使おう