私はほとんどの時間を C でソフトウェアを書いています。最近は、ミドルウェアに分類されるライブラリに取り組んでいます。それらは、2 つのソフトウェアが通信できるようにするためにのみ存在する必要があります。
開発中、ログを分析すると、バグを追跡して特定するためのはるかに迅速かつ簡単な方法であることがわかりました。明らかに、ライブラリを本番環境で使用するために、ログ出力を頻繁に検査する必要がないことを願っています。
しかし現実には、一部のバグは本番環境でしか発生しません。これの一般的な原因は、ライブラリの反対側の実装が、標準の観点から灰色の領域である何かを実行している可能性があります。そのため、本番環境からログを分析できる必要があります。
では、ミドルウェア タイプの API からログを公開するためのベスト プラクティスは何でしょうか? このトピックに関する文献はありますか?
現在、次の 2 つの考えがあります。
1 つ目は、 を使用し#defineて、ソース コード内のログ ステートメントの存在を制御することです。本番環境では、ライブラリが 2 回コンパイルされる可能性があります。1 つの共有オブジェクトは、ロギング ステートメントが有効になっています。もう 1 つは、ログ ステートメントなしで最適化されます。実行時に動的にリンクされるライブラリを変更することで、ロギングを有効または無効にすることができます。
この#defineアプローチは機能しますが、柔軟性に欠ける可能性があります。さらに、私はパフォーマンスについてあまり心配していません。私は最初に実装し、次に最適化するというアプローチを取ります。
私の 2 番目のアプローチは、UNIX スタイルの哲学に固執し、ファイル記述子を渡すことによってログを有効にする機能をライブラリに持たせることです。これにより、実行時にロギングを有効または無効にすることができます。ファイル記述子が設定されている場合、ロギングが有効になります。設定されていない場合、ログは記録されません。明らかに、これには独自の欠点があります。しかし、それは単純なアプローチです。