デバッグ方法

今や開発ツールがデバッガーを持つのは当たり前ですが、昨今というかサーバークライアント構成でのアプリケーションが主流になってからそもそもデバッグというのは非常に難しくなってしまったといえると思います。

これは開発の主流がウェブに移りつつある現状でも変わりないというかより難しくなっているといっても過言ではありません。

さらに今後スマホやタブレットが端末の主流となるにつれますますデバッグはやりにくくなるかもしれません。

実際現在のデバッガーは想像以上に高度なソフトウェアであり、デバッガーの裏側で行われていることはかなり複雑です。

その分操作も習熟度および準備（というか段取り）に応じてかなり効率性に差がでるものです。

しかしどんなに習熟しても本質的な効率の悪さはなかなか解消しにくいものです。

本質的な効率の悪さは、サーバ上の処理とクライアント側の処理というコンテキストの違う処理が入れ替わりながら実行されていくというところにあります。

さらにウェブアプリケーションの場合、サーバとクライアントの関係はステートレスなものが主流なのでなおさらそのコンテキストの切り替えの捕捉が複雑になりがちです。

なのでデバッガーが得意とするステップ実行を逐次実行していくというアプローチはどうしても時間がかかり効率的ではありません。

ところでインターシステムズの開発環境でアプリケーションを開発する人々はデバッガを駆使するよりは他の方法を取るケースが結構あると思います。

それはグローバル変数という永続変数にプログラムの途中結果を逐次記入する処理を追加することによってデバッグ情報を取得するという方法です。

グロバール変数はかなり複雑な構造も簡単に構築できるので、バグ解析に必要十分なデバッグ情報を構成することも極めて簡単です。

まあこの手法は野放図に行うと気づいたらデバッグ情報がごみとなって散乱するという問題やうっかりそのデバッグ情報の取得処理が本番システムに紛れ込んで、実害はないけどゴミデータがたまるなどという弊害も起こりがちですが、そこはプロジェクトマネージメントでなんとかできるレベルだと思います。

インターシステムズのEnsembleという統合プラットフォームはすべての途中経過のメッセージを永続化するというのが最大の特徴ですが、これも言い換えればこのデバッグ情報を系統だてて取得できるようにフレームワーク化したといえないこともないと思います。