関数ツリーの限界

機能追加、バグ修正をする際、テスト範囲や修正箇所を特定する作業が一般的に必要となります。この作業をするためにgrepを活用して、関数の呼出し関係、関数と変数の参照更新関係を調べます。grep作業と頭の中の整理だけで作業を進めると、必ず混乱してしまいます。

そのため、多くのソフトウェア技術者の方は、grep作業の結果を『関数ツリー』の形式でメモ書きしていると思います。『関数ツリー』は「どの関数がどの関数を呼んでいるか」「どの関数がどの変数を参照更新しているか」が明確になり、テスト範囲や修正箇所の特定に役立ちます（下図）。



また、『関数ツリー』を自動生成してくれるツールがいくつかあるため、ツールを活用しているソフトウェア技術者の方も多くいらっしゃると思います。多くのソフトウエア開発現場では、ドキュメントを作りなさいと言われていると思いますが、この『関数ツリー』をドキュメントに貼りつけると、設計書として形になります。このように多くのソフトウェア開発現場は、『関数ツリー』を活用して開発効率を高める活動を行っています。このような良い活動は、さらに良い成果をもたらすスパイラルとなります。

 



 

しかし、grepや自動生成ツールを使って作成した『関数ツリー』を用いてソフトウェア開発を行っていると、いずれ限界が来ます。場合によっては、ソフトウェアの品質低下、又は取り返しのつかない品質劣化に陥る危険性もあります。それは何故でしょうか。

理由は、『設計図』を活用したソフトウェア開発を行っていないからです。「え？『関数ツリー』は『設計図』でしょ？！」と疑問を持たれる方が多くいらっしゃると思います。残念ながら『関数ツリー』は『設計図』ではありません。『関数ツリー』は『実装図』です。さらに分かりにくくなってきたと思いますので、言葉を整理したいと思います。

　『実装図』とは、現状をありのまま図に書き表したものです。
　『設計図』とは、設計者の何かしらの考えや意図が反映された構造を書き表したものです。

と書くと、何となく納得して頂けるのではないでしょうか。つまり、『関数ツリー（実装図）』は、ソースコードの造りをそのまま、ありのまま書き表したものです。もちろん、ソースコードが完璧ならば問題はありませんが、実際はグローバル変数が存在していたり、双方向依存の関数呼出しが存在していたり、必ずしも現状のソースコードの姿が正しいとは限りません。特に緊急なバグ修正や無理な機能追加を行った場合、ソースコードの構造を劣化させている可能性があります。『関数ツリー』だけを頼りに機能追加、バグ修正を行っていると、いずれ設計初期段階の構造は崩れていきます。

 



 

『関数ツリー』は取り組み始めたころは、効果が出ます。ただそれは当然の事です。grepだけで開発を行うよりは当然効果があります。しかし、本来の設計構造、すなわちソフトウェアアーキテクチャを無視した実装を繰返していると、必ずソースコードの品質は劣化していき、開発効率を下げる原因になってしまいます。これが『関数ツリー』の限界です。あるレベルまでは良い効果が得られると思いますが、一定のレベルで頭打ちになってしまうのです。

『設計図』は、ソフトウェア技術者の『意図』『考え』『判断』『根拠』などが盛り込まれている図でなければなりません。もちろん、実際のソースコードは無視できませんので、『設計図』と『実装図』を対比しながら、どこに機能を盛り込めば良いのか、同時にどこを改修しないといけないのかを考えて行かなければなりません。

『設計図』とはなにか、『改修方法』とはどんなものか、については別の機会に・・・。