skillup

技術ブログ

プログラミング全般

調査スキルについて

投稿日:

本日は実務でとても大切な不具合の発見方法について

通常のプログラマとして仕事をしておりますと、通常の実装よりは不具合時の調査のほうが難しいことが多々あります。

もちろんものによるんですが、経験のある人とない人でスピードがもろに違うだけにここら辺はスキルを言語化しておきたいところ。

といってもひとえにログの調査につきます。

バグの調査や修正ってある意味、探偵や刑事に近い技術が必要だと思うんですね。

刑事なんかでも現場百篇なんて言葉ありますが、プログラムのバグの場合、この現場に相当するのはソースとログになります。

異常な動作が起こっている場合、どこまで正常な動きが起こっているのか、いつから不具合が起きたのかは記録をみるのが一番早いです。

そのためにもログには必ずこまめに出力しておくようにしましょう。これないとプログラムの記録がないわけで、つまり「現場」の調査自体ができなくなります。

出しておきたい内容としては下記のような情報でしょうか。

時間

これ忘れることはあまりないかもしれないですが、ないと前後関係自体わからないので必ず出力しましょう。

プログラムの行数

事件が起こった時に調査するのはまずは時間と場所。場所はこの場合、プログラムの行数になります。どこで事件がおこっているのか。画面から想像がつくときもありますが、複雑なプログラムの場合、なかなか難しいこともあるでしょう。

エラー内容

if文などでエラーが起こった場合にはしっかりとエラー内容を書いておきましょう。プログラムなんて3日立てば内容を忘れていることが多いので、記録として残しておかないとあとで自分を苦しめることになります。

ステータス情報系

状態を表すような主要なパラメーターなどはログに吐き出しておくと、プログラムの動きが見えやすいでしょう。こまめに出力しておくとあとで自分を助けてくれます。

SQL

データはほぼ100%に近い確率でデータベースを使いますので、どんなSQLが吐かれたかはとても大事です。SQLはすべて出すぐらいの勢いで。

あとは容量にも気を付けておかないと肥大化したり、小さいとすぐにログの量自体がなくなってしまいます。

参考リンク

http://blog.8bit.co.jp/?p=8815

 

-プログラミング全般

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

シェルの基礎+ユーザー切り替え関連

雑誌を見ていたらシェルの特集があったので、ちょっとメモリます。 補強したいところのみ要点をチェック。 Contents0.1 実行パスについて0.2 ビルドインコマンド0.3 シェル変数・環境変数0. …

no image

webの仕組み その2 リクエストとレスポンス

クライアント(ブラウザ)はサーバーとの接続を確立した後、各種リクエストを送信します。サーバーはそれにこたえテキストや画像などのリソースをクライアントに転送します(これがレスポンスです。) Firefo …

no image

テストプロセスに関して

日々是テスト。 プログラマになってから数年がたちますが難点はずっと同じでテストですね(汗) 以前にかいたエントリーなどは下記参照。 参考 データベースによるテストデータ作成 Excelによるテストデー …

no image

便利すぎる道具の弊害

現在、Javaのプロジェクトでは会社でNetbeansを使っていますが、IDEを使っているばっかりに理解できていないところがありました。便利すぎる道具の弊害ですね・・・ IDEについて一応説明をしてお …

no image

オブジェクト指向 データベース層

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にデータベース層の考え方について。 Contents1 データべース層1.1 要点1.1.1 典型的なダメテーブル設計1.1 …