skillup

技術ブログ

プログラミング全般

調査スキルについて

投稿日:

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

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

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

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

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

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

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

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

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

時間

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

プログラムの行数

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

エラー内容

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

ステータス情報系

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

SQL

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

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

参考リンク

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

 

-プログラミング全般

執筆者:


comment

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

関連記事

no image

オブジェクト指向 クラスの設計と業務ロジックの整理

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にクラスの作り方について。 Contents1 クラス設計と業務ロジック1.1 要点1.2 感想 クラス設計と業務ロジック …

no image

フレームワーク作成時の注意ポイント

以前も多分書いていますが、フレームワーク作成時のポイントなどを列挙。 次元が違うものも多々含まれているかも。 ルーティング機能 基本設定情報の読み込み キャッシュ機能 データベース Form情報の管理 …

no image

変数の役割について

前回のエントリーの主眼は変数を置くことで、適切な情報量に分割し、コードを読みやすくしよう、ということでした。 今回はそれとは少し逆の観点でして、不要な変数を削除して、コードを読みやすくしよう、というこ …

no image

テストプロセスに関して

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

no image

PCクラッシュ時に備えて

先日、ずっとメインで使っていた会社のノートPCがクラッシュし、再起不能になりました。ファイルなんかはクラウドで管理していたものが多かったので実害はあまりなかったんですが、当然ゼロではありませんでした。 …