skillup

技術ブログ

プログラミング全般

調査スキルについて

投稿日:

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

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

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

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

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

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

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

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

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

時間

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

プログラムの行数

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

エラー内容

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

ステータス情報系

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

SQL

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

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

参考リンク

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

 

-プログラミング全般

執筆者:


comment

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

関連記事

no image

1度に1つのことを

今回のリーダブルコードの概念はやや抽象的。 要は一度に行うタスクは1つにする、というところがポイントになります。 そのための手法として下記のようなことを上げています。 コードが行っているタスクをすべて …

no image

コーディングルール 前半まとめ

リーダブルコードを3分の2ぐらいよんだので現時点でのまとめを。 Contents1 いいコードの定義2 具体的な手法2.1 変数の名称2.2 コード自体の見た目2.3 コメント2.4 制御フロー2.5 …

no image

コードの見た目について

リーダブルコード4章。コードの見た目について。 自分は結構注意されますね。多いパターンとしては空白の位置などがいい加減だったり、今はありませんが、以前はコードの末尾にスペースを空けてセミコロンをうつ変 …

no image

オブジェクト指向について その2

前回のエントリーのように、データとロジックを一体で考えるのは、処理状の有効性のみならず、よりユーザー側に近い処理をかくということにもつながります。 日付の問題に関してもintやshortよりはLoca …

no image

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

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