便利なスレッドベースのログを実装します

プログラマーの中には熱狂的な人がたくさんいます。 あなたの仕事に心からの関心を示し、この環境での自由時間であっても特別な本やフォーラムを読んでください。そうでなければ、例外ではありません。 では、なぜ結果がそれほど低品質のソフトウェアなのでしょうか？ プログラミング言語全体の欠点について議論し、少なくとも12個のデザインパターンを知っている学生が、突然、低品質のシステムの作成に積極的に参加するのはどうですか。 彼のキャリアの始まりではなく、年々。



はい、あなたは給与が書かれたコードの行数またはまばたきせずに長時間モニターを見る能力に依存している多数の低スキルの人を参照できます。 しかし、ほぼすべての部門にそのような従業員がいます。 建築業者は建築家よりも低い資格を持っていますが、これは建物が追加の「パッチ」なしで完全に使用するのに最も適していることを妨げません。



私の意見では、2つの主な理由があります。 最初については何もする必要はありません。 これは時間、または、彼らがより頻繁に言うように、絶え間ない変化です。 ソフトウェア製品を開発するとき、たとえそれが顧客のすべての要件を満たしているとしても、請負業者にとって予期しないことが多い、さらなる改善が必要になります。 それらはほとんど避けられないものであり、必ずしもシステムアーキテクチャに適合するとは限りません。 時間が経つにつれて、ソフトウェア複合体は使用できなくなります。 しかし、時間はさらに大きなものを破壊しました-驚くべきことは何もありません。



2番目の理由ははるかに平凡です。 ささいなことへの不注意。 特にプロジェクトの開始時。 そして、チームが若いほど、壊滅的な影響をもたらします。 もちろん、演算子がスペースで区切られていることを確認するよりも、マルチメソッドを使用する可能性について議論するほうがはるかに興味深いです[1]。 そして、そのような些細なことは、究極の機能と特別な関係はありません。 プロジェクトの時間と予算が限られているため、最初に主要な要件に集中することをお勧めします...



それはさらに良いことになります。 それは土台のない家のようなものです。 顧客は、広々とした部屋、エレベーター、各階のバスルームを要求しました-彼はおそらく基礎について知らないでしょう。 しかし、構造全体に耐えられる品質基盤が必要です。 そして、建築家から建築家まで、パフォーマーはそもそも世話をする必要があります。



根拠のないことを続けないために、私は影のある、しかし基本的でしばしば必要なサブシステムの例を挙げます。 これはロギングです。 多くのシステムには、診断メッセージを表示する機能が含まれています。 ただし、通常は主な機能ではないため、十分な注意は必要ありません。



同時に、適切に設計されたロギングサブシステムは、プロジェクトの最初から多くの迷惑なエラーを回避するのに役立ち、欠陥が発生してから検出されるまでの時間を大幅に短縮します。 結局のところ、プロジェクトの完了までに作業の最初に見逃されたすべてのミスは、巨大な雪だるま式に変わり、システムとそのすべての作成者をその下に埋めようとします。

まず、注意を払わない診断メッセージを表示するためのモジュールの表示方法を定式化します。

• 完全なインターフェース
• クロスプラットフォーム
• IDEコンソールでのメッセージの表示
• 利便性と使いやすさ
• 開発者ツール

完全なインターフェース ロギングモジュールは、開発の最初から完全な操作セットを提供する必要があります。 インターフェイスは完全に実装されていない場合がありますが、実装する必要があります。 そのため、重大度（エラー、警告、情報）に応じて診断メッセージを分離できると非常に便利です。 最初にある種のメッセージを作成してから分離を導入することは不可能です-システムの一部は、この一般化された結論で既に開発されています。たとえ人々が行われたすべてを掘り下げることを余儀なくされたとしても、開発者がすぐにそうするようにこの作業を正しく行うことはまずありません。



多くの場合、1週間後に自分のコードを他の人のものであるかのように見ます。 数か月後、実装の多くのニュアンス（特に、重大な問題、およびわずかな偶発事象）が永久に失われることは明らかです。



クロスプラットフォーム。 ロギングサブシステムは、最初に使用するすべてのプラットフォームをサポートする必要があります。 これは、すべてのオペレーティングシステムでアプリケーションを完全かつ継続的にテストできない場合に特に重要です。 iOSでうまく機能したものは、Androidデバイスでは奇妙な動作をする可能性があります。 もちろん、メッセージ出力システムは自動テストに代わるものではありません。 しかし、それらは非常に複雑であり、実装とサポートには多大な人件費が必要であり、道徳的であろうとなかろうと、テストを安全に忘れることがよくあります。 したがって、私は理想を夢見て、何もしないよりも完全に機能する最小限から始める方が良いと信じています。 いずれにせよ、理想的には、ログ記録のためのテストと便利なサブシステムがあるはずです。



IDEコンソールにメッセージを出力します。 基本要件のリストには、「永続ストレージ（ファイルまたはデータベース）へのメッセージの出力」が含まれていないことに注意してください。 通常、これは多くの人がログから期待するものです。 将来のユーザーまたは特別な部門にテストするために、少なくとも何らかの形で稼働中のシステムが提供される場合、ログファイルに必要があります。 しかし、初期段階では、テスターよりもプログラマーに問題を知らせる方がはるかに便利です。



ユーザーインターフェースの機能が非常に遅れる可能性があるため、開発者はこのたびすべて「自分の力で調理する」ことになります。 大きな違いがあります。問題を作成してから数秒または数週間後に見ました。



利便性と使いやすさ。 プログラマーは怠け者です。 問題を報告したいとします：サイズ100 x 120の画像が取得され、現在のアプリケーション設定は128 x 128の最小サイズの制限を設定します。単純な行しか印刷できない場合、開発者は適切な出力を行う必要があります

1. 4つの数値を文字列型にキャストします
2. 受け取ったパーツからラインを作ります
3. ログに行を渡す

言語がフォーマットされた文字列（たとえば、sprintf [2]およびstringstream [3]）に出力する手段を提供する場合でも、さまざまな中間変数を作成し、時間を浪費し、メインロジックを侵食する必要があります...一般に、結果として何かがログに書き込まれても驚かない「無効な画像サイズ」のようなものです。 「受け入れられない」という言葉の意味は、今では理解しやすいものですが、数週間でほぼ完全に失われます。 結果として、設計者は問題のある画像を修正する代わりに、明確化のためにプログラマーに連絡する必要があります。



したがって、ロギングサブシステムは、開発者が手動で少なくとも基本的なタイプの文字列を作成することを強制せずに、出力文字列の便利な書式設定のためのツールを提供する必要があります。 ここでC ++では2つの方向が可能です。



1つ目は、Cのレガシーです。パターンで文字列をフォーマットします。 つまり ログ出力関数には、sprintfと同様のインターフェースと機能が必要です。 これは趣味の問題であり、個人的にはこのオプションは非常に同情的です。 何よりもまず、可変数の異種関数パラメーターを使用する必要がありません。 つまり 入力データを検証する機能は実質的に存在しません。 さらに、単純化されていますが、手動で型を変換する必要があります。 たとえば、符号なしの数値を出力するには、％iの代わりに％uフォーマットコードを使用する必要があることを覚えておく必要があります。 さらに、コンパイル段階では、フォーマットコードの数（順序、タイプ）と実際に転送されるパラメーターが一致しない場合、とらえどころのない問題が発生する可能性があります。



2番目のオプションは出力ストリームです。 前のソリューションのすべての欠点が奪われています：出力演算子をサポートしないオブジェクトが転送された場合、パラメーターの依存関係はありません-コンパイルエラーがあり、すべての種類の驚きではなく、手動でバッファー、キャストタイプなどを選択する必要はありません そして最も重要なことは、異なるタイプの変数を含むメッセージ行の出力を実際に1行で書くことができることです。 はい、特別な困難の実装は期待されていません-標準ライブラリには既にストリームstreamstream [3]が含まれています。これは、文字列への出力をストリーミングするための既成のアルゴリズムがあることを示唆しています。



開発者の注目を集める手段。 プログラマは忙しいです。 IDE出力コンソールでもエラーに気付かない場合があります。 問題は、情報メッセージの雲の間で簡単に迷子になります。 したがって、最初に、ログは出力レベル設定をサポートする必要があります。 たとえば、「エラーと警告のみを表示します。」 これは必要ですが、これでは十分ではありません-実行するには時々調整が必要です。 そしてプログラマーは忙しいです。



ここに特別なassertマクロ[4]があります。 問題のある場所でプログラムの実行を中断できます。 結果は異なります-Visual Studioでは、ウィンドウが表示された後に実行を継続することができます。Xcodeはサウンドでサウンドを怖がらせませんが、実行を継続することもできません。 一般に、注意が保証されます。 この場合、診断メッセージ自体はIDE出力コンソールの最後にあるコンソールの最後に表示され、多くの場合、停止の理由を探すために呼び出しスタックを調べる必要がなくなります。





図1.警告によるプログラムの中断



記事の最後に、実装の例を示します。 特別な努力を必要とせず、効果を過大評価できないことを示すために、結果として、開発者を刺激して問題に関する詳細なメッセージを作成するだけでなく、問題とその検出の間の時間間隔を大幅に短縮するサブシステムが取得されます。



最初に、ロギングクラスの基本的なインターフェースを見てみましょう。

class Log { public:
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まず、ログの詳細の4つのレベルを（宣言の順に）紹介します。

1. ログの完全シャットダウン
2. エラーのみを出力
3. 警告とエラーを表示する
4. すべてのタイプのメッセージを出力する

  enum DebugLevel { DEBUG_LEVEL_DISABLED = 0, DEBUG_LEVEL_ERROR = 1, DEBUG_LEVEL_WARNING = 2, DEBUG_LEVEL_MESSAGE = 3, };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、有効なタイプのメッセージの3つの識別子を追加します。情報メッセージ、警告、エラーです。

  enum MessageType { MESSAGE_INFO, MESSAGE_WARNING, MESSAGE_ERROR, };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のメソッドは、クラスをインスタンス化するためのものです。 コンストラクターを保護領域に配置することにより、直接作成することは禁止されています。

 static void createInstance();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

利用可能な最後のパブリックメソッドは、ログの詳細レベルを設定するように設計されています。 他はすべて閉じられています。 これは予備のログインターフェースです-将来、実際にメッセージを表示する方法が示されます。

  void setDebugLevel(DebugLevel level); protected:
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

保護された領域は、約束されたプライベートコンストラクターによって開かれます。

  Log();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

唯一の純粋仮想メソッドは、プラットフォームに依存する情報をIDEコンソールに出力するために設計されています

  virtual void writeIDEDebugString(const std::string& message, MessageType type) = 0; private:
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次の3つの方法は、各タイプのアラートを直接出力するのに役立ちます。 プログラマが誤ってそれらを使用しないように、クラスのプライベートエリアに隠されています。

  void writeMessage(const std::string& message); void writeWarning(const std::string& message); void writeError(const std::string& message);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルへの出力方法。 ここでは、記事のトピックと直接関係がないため、その実装は示しません。

  void appendToFile(const std::string& message);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デバッグメッセージを生成するには、ユーティリティ関数が必要です。 通常、タイムスタンプと行の重要度のサインが各メッセージに追加されます。

  void writeMessage(const std::string& message, MessageType type);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラスデータから、ログの詳細レベルとそのインスタンスを保存する必要があります。

  DebugLevel mDebugLevel; static Log* sInstance; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いくつかのメソッドの実装を検討する

メッセージ出力関数は同じタイプであるため、エラーメッセージのソースコードを最も完全なものと見なすことに制限しています。

 void Log::writeError(const std::string& message) { if (mDebugLevel >= DEBUG_LEVEL_ERROR) { writeMessage(getLogString(message, "error"), MESSAGE_ERROR); } #ifdef _DEBUG assert(0); #endif exit(EXIT_FAILURE); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、まず最初に、詳細レベルでエラー出力が許可されていることを確認してから、メッセージとメッセージタイプが送信されるwriteMessageユーティリティメソッドを呼び出します。 結果は次のようになります

エラー：[メッセージ]



開発者の注意を引くために、エラー出力が無効になっている場合でも、assertマクロが呼び出されます。 さらに、アプリケーションはサブルーチンの終わりで終了します。 このような解決策をユニバーサルと呼ぶことはほとんどありませんが、このアプリケーションでは、エラーは今後の作業と互換性のない問題を示します。



警告出力も同様に実装されますが、アプリケーションが異常終了することはありません。 情報メッセージメソッドにはアサート割り込みも含まれていません。



次に、writeMessageは次のとおりです。

 void Log::writeMessage(const std::string& message, MessageType type) { std::string text(message); std::replace(text.begin(), text.end(), '\n', ' '); appendToFile(text); #ifdef _DEBUG writeIDEDebugString(text, type); #endif }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その役割は、各ログメッセージが単一行であることが保証されるようにメッセージから改行を削除し、ファイルへの書き込みメソッドを呼び出し、デバッグモードが有効な場合はIDEコンソールに出力することです。



デバッグモードは、_DEBUGマクロによって決定されます。これは通常、Visual Studioで自動的に検出されます。 他の開発環境では、ほとんどの場合、手動で追加する必要があります。 いずれにせよ、これは特定の困難を引き起こしません。





図2. Xcodeのデバッグマクロ属性定義



さらに、プラットフォームごとに、writeIDEDebugStringメソッドをオーバーライドして、ベースクラスから継承した独自のログクラスを定義する必要があります。 一部のプラットフォームでの実装例を示します。

Windows（Visual Studio）

 void Log_Windows::writeIDEDebugString(const std::string& message, MessageType type) { OutputDebugStringA(message.c_str()); OutputDebugStringA("\n"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Android（Eclipse）

void Log_Android :: writeIDEDEDugugString（定数文字列とメッセージ、MessageTypeタイプ）

 { switch(type){ case MESSAGE_INFO: __android_log_print(ANDROID_LOG_INFO, "", message.c_str()); break; case MESSAGE_WARNING: __android_log_print(ANDROID_LOG_WARN, "", message.c_str()); break; case MESSAGE_ERROR: __android_log_print(ANDROID_LOG_ERROR, "", message.c_str()); break; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、Androidの場合、さらに明確になります。メッセージをさまざまな色で表示できます。 赤で表示された問題は、断言しなくても、注意を逃れる可能性はほとんどありません。





図3. Eclipseのタイプに基づいたメッセージの色付け

MacOSおよびiOS（Xcode）

 void Log_Mac::writeIDEDebugString(const std::string& message, MessageType type) { NSLog(@"%s", message.c_str()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

直接的な結論を導き出しましたが、疑問は残り、それをストリームに適切にパックする方法です。 結局のところ、すべての引き出しメソッドを閉じました。



まず、目的のエントリを決定しましょう。 C ++ストリームは、データが渡されるのと同じ方法で出力パラメーターを受け取ることができます。 たとえば、メッセージは大文字で表示されます。

 std::cout << std::uppercase << "test" << '\n';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、ここにはそのような人がいますが、個人的には、表示された情報と出力パラメーターの混合を受け入れることができませんでした。 したがって、この例では、出力は次のように実装されます

 Log::error<<"text"<<std::endl; Log::warning<<"text"<<std::endl; Log::message<<"text"<<std::endl;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり メッセージのタイプに関する情報には、ストリームオブジェクト自体が含まれます。 もちろん、std :: uppercaseのような標準ストリームパラメータは引き続き使用できます。 すべてのストリーム機能は、標準ライブラリクラスから継承されます。

 class Streamer : public std::ostream { public: Streamer(MessageType messageType); ~Streamer(); private: class StringBuffer : public std::stringbuf { public: Buffer(MessageType messageType); ~Buffer(); virtual int sync(); private: MessageType mMessageType; }; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ストリームの各タイプには独自のオブジェクトがあるため、コンストラクターはMessageTypeパラメーターを受け入れます。 std :: ostream [5]から継承する出力クラス自体、ネストされたクラスStringBufferは文字列の形成を担当し、文字列はstd :: stringbuf [6]から継承されます。 ユーザーがメッセージの形成の完了を発表するたびに、 syncメソッドが自動的に呼び出され、そこで直接出力が実行されます。 バッファリングされたストリームの標準メソッドを使用して、出力の完了を報告できます： flushメソッドを呼び出して

 Log::message<<"text"; Log::message.flush();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または単にストリームにstd :: endlを追加する

 Log::message<<"text"<<std::endl;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、出力ストリームを文字列バッファーに関連付ける必要があります。 これは、コンストラクターで行われます。

 Log::Streamer::Streamer(Log::MessageType messageType) : std::ostream(new StringBuffer(messageType)) { }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、破棄時には、バッファを単独で破棄する必要があります。

 Log::Streamer::~Streamer() { delete rdbuf(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バッファーコンストラクターでは、表示されたメッセージの種類を覚えておけば十分です。

 Log::Streamer::StringBuffer:: StringBuffer(Log::MessageType messageType) : mMessageType(messageType) { }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

破壊された場合、念のため、同期を行います。これにより、プログラマがflushまたはendlの呼び出しを忘れた場合にメッセージが「消失」するのを防ぎます。

 Log::Streamer::Buffer::~Buffer() { pubsync(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ストリームがLogクラスのメインインターフェイスにアクセスできるようにします。Logクラスは外部に閉じられているため、内部に配置します

 class Log { public: ... class Streamer : public std::ostream { ... }; static Streamer message; static Streamer warning; static Streamer error; ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メッセージの警告とエラーは、各タイプのメッセージのスレッドインスタンスです。 コンストラクターで渡されたメッセージのタイプ

 Log::Streamer Log::message(Log::MESSAGE_INFO); Log::Streamer Log::warning(Log::MESSAGE_WARNING); Log::Streamer Log::error(Log::MESSAGE_ERROR);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして最後に、ストリーム文字列バッファー同期関数の実装を検討します。

 int Log::Streamer::StringBuffer::sync() { if (Log::sInstance == NULL) { return 0; } std::string text(str()); if (text.empty()) { return 0; } str(""); switch (mMessageType) { case MESSAGE_INFO: Log::sInstance->writeMessage(text); break; case MESSAGE_WARNING: Log::sInstance->writeWarning(text); break; case MESSAGE_ERROR: Log::sInstance->writeError(text); break; } return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ネストされたクラスとして、 Log :: Streamer :: BufferはLogのプライベート（プライベート）エリアにアクセスできます。 明確にする必要があるのはstr（）関数のみです。 これはstd :: stringbufクラスのかなり奇妙なメソッドであり、同時にバッファー値を取得および設定できます。 どちらの形式でも使用されます。まず、この関数を使用してバッファーから文字列を取得し、次にstr（ ""）を呼び出してバッファーをクリアします。

これで、 StreamerクラスはLogの 「公式」インターフェースになりました。 複合メッセージ「i（6）は範囲[1..5]である必要があります」を表示するには、プログラマが次のように記述すれば十分です。

 Log::warning << "i (" << i << ") should be in range [" << I_MIN << ".." << I_MAX << "]" << std::endl;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

あいまいな「間違った」を取得するのと同じくらい簡単です

したがって、非常に単純なイベントロギングクラスの例が示されました。これは、最も時間の制約のあるプロジェクトの最初でも簡単に実装できます（テストを書いたり、プログラマーを説得したり、効果的に制御したり、呼吸したり、眠ったりする時間がない場合）。その品質を大幅に改善します。



[1] en.wikipedia.org/wiki/Multiple_dispatch

[2] www.cplusplus.com/reference/cstdio/sprintf

[3] www.cplusplus.com/reference/sstream/stringstream

[4] www.cplusplus.com/reference/cassert/assert

[5] www.cplusplus.com/reference/ostream/ostream

[6] www.cplusplus.com/reference/sstream/stringbuf