2009

今まで色々な言語の参考書を読んできたが、肝心なことが書かれていないと思い、世の中に一言（笑）

開発者に一番重要で必要なスキルは、Log出力機能を付けることだ！
　
1番の狙いとしては不正エラーを捉えることが目的で、後はおまけで色々と適材適所に仕掛けて、ほしい情報を出力すればいい。

じっくりテストをしたとしても運用を開始して本番環境で、ほぼ必ずと言ってよいほど、簡単には分からないエラーが発生する。その際、確実に問題点を絞り出すことが非常に重要となるので、この為だけに仕掛けると言っても過言ではない。この機能があるとないとでは大違いである。

当たり前だが、プログラム内は目に見えない。Log出力してあれば見える形でユーザーに対し「これで大丈夫です」と説明する材料となり、自信を持って説明することが出来る。また説明する開発者もアタフタせずにすむ。（笑）

開発する場合は正常なルートを初めは作ってしまいがちだが、一番はじめにLog出力機能を考えて作成する。最近ではLog4など色々と言語にぶら下がっている出力機能もあるので自作しても良いし、既存のLogClassを使用しても良い。

機能としては、出力機能、出力停止機能、出力先変更機能は最低ほしい。フラグやPathは定数をきっておいても良い。

最低限ほしい出力内容は日時、どこから出力されたか、ステータスはエラーなのかログなのかの切り分け情報、内容と四つはおさえてほしい。もちろんそのシステムにより、必要な情報は出力する。Web系アプリならマルチスレッドでの動作な使用ユーザー情報（IDなど）も必要で可能であればDBへ出力してもいい。

このDBへの書き込みはDB接続を前提としているので接続自体に問題が発生した時に捉えられないことがあるので、基本はローカルにログを吐いて、DB接続が確認できたらDBへも吐き出させるのが有効。（毎日夜中の1時になど）

DB出力は注意が必要で、プログラムエラーのログを吐こうとしたらDB接続エラーとなることが考えられる。エラーのエラーは本末転倒になる。DB出力は十二分に確認が必要。またシステム負荷の度合をみながら設置すること。

■Logを出力するタイミング
・エラー時
・単体起動時、単体終了時
・重要な箇所（DB更新など）

言語に存在し、余裕があればThrow系と連携をとると最適になる。

本当に硬いシステムの中身はLog出力機能が充実しているものであり、不安定なシステムにはLog機能が充実していないことが多い。

これが出来て一人前？・・・当たり前（苦笑）