すべてのプログラムは、それが何をしているかを観察できるように、その上に構築された何らかの形のロギングが必要です。これは、プログラムがうまくいかないときに特に重要です。良いプログラマーと悪いプログラマーの違いの1つは、良いプログラマーはロギングやその他のツールを追加して、プログラムが失敗したときにデバッグしやすくすることです。
プログラムが期待通りに動くときは、ログがあるのとないのとではほとんど違いがないことがよくあります。しかし、プログラムが失敗したり、正しくない結果を得たりすると、すぐに良いプログラマーと悪いプログラマーの違いがわかるでしょう。
例1："デバッグ可能なバージョンにしよう"
例えば、正常に動作していないコールケースに関するテストが私のところに来たとしましょう。ログをチェックしたところ、隣のモジュールに問題があることがわかりました。他のモジュールへの呼び出しはnullを返しました。その隣のモジュールにログインしてテストケースを再実行しましたが、それ以上有益な情報は得られませんでした。なぜnullを返したのか、パラメータが間違っていたのか、外部システムで失敗したのか、隣のモジュールにバグがあったのか、手がかりがありません。
このコードの一部を担当している開発者に尋ねようとしたところ、「ああ、何が起こっているのか、デバッグ・バージョンをやってみないとわからない」という答えが返ってきました。失敗です！ある意味、ログから問題を見つけることは可能なはずですが、実行中のシステム上に問題が存在する場合、デバッグバージョンを追加するのは大変な作業です。コードにはログに十分な情報が含まれている必要があるので、少なくとも失敗の原因についてある程度の見当をつけることができます。
例2：「どうやってここまで来たのか見せて」？
製品は、携帯電話***に配信されるショートメッセージの経路を見つけることで機能します。携帯電話の現在地やターゲットユーザーが所属する事業者によって、多くの経路オプションがあり、それぞれに所定のコストやその他の特性があります。これに加えて、他の経路を促進するために一部の経路を禁止するなどの例外もあり得ます。通常、何千もの経路が定義されており、システムはそれぞれのケースで****経路を見つけ、修飾子を追加し、メッセージを配信します。
さて、あるSMSメッセージがルートAを使って配信され、しかし彼はBを使うべきだと考えたとします。もしログの情報がなく、何百もの可能性のあるルートとそのコスト、例外、複雑なアルゴリズムしか残っていないのであれば、なぜAが選ばれたのかを解明するのは幸運なことです。
この実装では、すべての可能なルートがコスト・サイズ順にログにリストされ、ルートが異なる制約によって除外されると、除外されたルートとその理由がログにリストされます。 アルゴリズムへの入力と、ログにリストされたステップ文字情報により、特定のルートがなぜ選択されたかを簡単に見ることができます。
どうしてですか？
では、なぜすべてのプログラマーが調整可能なコードを書かないのでしょうか？理由は3つあります：
1. コードが期待通りに動かないことがあることを謙虚に理解する必要があります。多くのプログラマーはこのことに少なからず腹を立てていることでしょう。
2. コードを徹底的にテストするのであれば、さまざまな場面で動作するか失敗するかを確認する必要があります。それぞれのシナリオに対して、ロギングを含めるのは当然で、もしそれらのシナリオをテストしていなければ、そこにロギングを追加することはまずないでしょう。
3.多くのプログラマーは、製品システムで自分のコードを修正しない傾向があります。もしオンラインシステムに問題があったとしても、ログがなぜ問題があるのかについてのフィードバックを与えてくれないのであれば、次に同じ状況に遭遇したときに役立つようにログを追加しようという強い動機が生まれるでしょう。
コードはデバッグ可能ですか？
もちろん、優れたロギング情報だけでは、プログラムがなぜ失敗したのかの決定的なイメージが得られない場合もあるでしょう。それでもデバッグ・バージョンを作成する必要があるかもしれませんが、通常のロギングは少なくとも問題の可能性に関する隠れた情報を与えてくれるでしょう。
では、準備はできていますか？プログラムが失敗したとき、何が悪かったのかログに残っていますか？
