2023年3月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
無料ブログはココログ

 

« プログラム考察:ログ出力(トレースログ) その1 | トップページ | 備忘録 »

2009年11月 8日 (日)

プログラム考察:ログ出力(トレースログ) その2

昨日の続き。

トレースログは、何の情報を取得すればいいかを考えてみた。
正直、これには回答がない。
というのも、プログラムの使用用途、規模によって取得する量、質が変わるべきだからだ。
ミニマムな環境では必要にも満たない最低限のものになるし、パワフルな環境なら十分な情報を取得することも可能である。
バッチシステム、サービスプログラムのような一気に動かすようなものなら、データについて情報を取得することを考慮すべき。しかも、動作の信用性も十分確保しなければならないので、動作経路も分かるようにするべき。ちょっとでもおかしなデータが来たら出力して、その経路も分かるようになっているとベター。
ユーザAPのような小規模ならば利便性を優先させるべきなので、あまり多くの情報を取得すると遅くなってしまうし、セキュリティも甘いからパスワードなどは出力は言うまでもなく、個人情報に関わるデータも出力するべきではない。(ユーザAPだけじゃないけど)

簡単にまとめると、何の情報が必要かの設計するべきで、その指針はそのAP・システムが何のために使われるものか考慮しなければならない。
ログについては、システムが実現したいことの本流ではないので、ないがしろにされてしまうのだが、(バグを除去して安全なシステムへと成長させるには)本当は十分検討しなければならないことなのだ。

以上はマクロな視点なのだけど、ミクロな視点では共通して言えることがある。
main関数のようなプロセスが起動する上位関数辺りでは、扱う情報が少なく、実行回数も少ないので、ログを充実して、何時どんな処理をユーザが依頼したかを記録する。
ループの中や実行回数が多い下位の関数は、ログを出力すると、とんでもない量の情報が出力されてしまって、必要な情報が埋もれてしまう可能性が高い。なので、なるべくループの外や呼び出す側の(実行回数が少ない)関数でログを出力するようにする。あと、危なそうな処理を見極めて、そこに集中させるというのも良いかも。(出来の悪いプログラマが作ったところとか:-p)
また、正常ケースの処理にではなく、異常ケースだけログを出力ようにする。例外キャッチがある言語では、危険なところをキャッチして例外を出力する。

いずれにしても、何の情報を取得するのか(処理の実行順や入出力データ)を考慮し、実行回数の多少を見てどれだけ出力されるのか、ログの要件がシステムに合致するのかなどなどを検討して、最適解を求めなければならない。

土曜日は休出してヘロヘロになってしまった。なので昨日分のこのブログを書いてなかったりする。というのも開発中のシステムが各チームの出来たものを結合して動かしているのだが、オイラが担当したところで、どうしても分からない問題が出てな。しかも、それが領域破壊っぽい・・・。
時間がなさ過ぎて、コーディングは何とか終わったけれど、ログを十分埋め込めてないしもちろんログについて検討なんて夢また夢、机上テストができず、単体テストも出来ていないのでまともに動かないのは予想通りなんだけど、それでいて期間が短くてもう手がない・・・。
領域破壊などの困ったチャンなバグは、机上デバッグでソースを見て、トレースログ埋め込みや修正を試して、繰り返して、ある時、なんでもないようなコーディングミスがぱっと見つかるって時間をかけなければ見つからんようなバグなんだよな・・・。

« プログラム考察:ログ出力(トレースログ) その1 | トップページ | 備忘録 »

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック


この記事へのトラックバック一覧です: プログラム考察:ログ出力(トレースログ) その2:

« プログラム考察:ログ出力(トレースログ) その1 | トップページ | 備忘録 »