Unixでのプログラミングの技術（だけでなく）。 パート7、透明性のルール
「 エリック・レイモンドによる」Unixのいくつかの簡単な開発ルールに焦点を当てた一連の記事を続けます。これは、私の最も深い信念において、他のオペレーティングシステムに拡張できます。 モジュール性 、 明快さ 、 構成 、 分離 、 シンプルさ 、 コード節約のルールについて、最初の3つのパートですでに話しました。 今日、それは7番目のルールになりました-
透明性ルール：デバッグツールでソフトウェアをすぐに設計
この規則の意味は、次の2つの仮定で表すことができます。
または、典型的なWindows FTPクライアント 。 ようなものは、長い間、普通のユーザーの兵器庫に含まれています。 高度なユーザーですが、いずれにしても 、長い間、プロトコルの複雑さを理解しているのは必ずしもプログラマーではありません。 FTPクライアントが組み込まれ ているプログラムを自分で作成します 。ほとんどの場合、それを選択すると、サーバーに接続しません。 理由-判断できません。 彼は自分を放棄しません。 エラーはすべてです！..
さて、さらに低くなります。 こちらがWindows用のSkypeとICQです。 両方ともプロキシ設定があります 。 また、接続の問題が発生するたびに、 プロキシサーバー に問題があるのか、それとも問題があるのか、それとも私に問題があるのかがわかりません。
行動のログを記録する必要がある場合の例-海。 そして、1人のユーザーの損失がバケツの低下である大規模な産業ソリューションを検討します。 また、アクセシビリティの要件が高いシステムを扱っている場合はどうでしょうか？ 1秒ごとにカウントされるのはいつですか？
Unixの世界では、「それ自体」として機能する標準コンソールアプリケーションにデバッグモードを含めること、および/またはいわゆるログを保持することをお勧めします。 「ログ」。 デバッグレベルを設定し、アプリケーションの動作を確認します。 そのため、接続を開き、そこにコマンドを投げました。ここでは、応答を受け取りました。ここでは、応答は予期せず、プログラムはエラーを報告しました。 一部の「上級」ユーザーが自分で問題に対処し始めるという事実に加えて、この方法でトラブルシューティングの時間を節約できます。
プログラムはかなり長い時間を経て初めて有用なトレースを残すため、ロギングは便利です。 たとえば、ユーザーが特に気付かないエラーについてログを分析できます。 突然、定期的に表示されますか？ ログから、パフォーマンスデータを取得してグラフを作成し、傾向を分析できます。 ジャーナリングを無効にすることは遅すぎることはありませんが、プログラムに含まれていなかった場合、これを行うのはすでに困難です。
たとえば、ArtPublishingでは、デバッグコンソールは次のようになりました。関数テンプレート 呼び出しの階層。 前の記事で引用したフォーラムテンプレートの1つについて、開発者はデバッグフラグをURLに追加することにより、ソフトウェアが内部でどのように動作するかを調べることができます。
上記の例は、正と負の両方で使用できます。 特に、ジャーナルが構造の形で提示されると便利です。 欠点は、たとえば、いくつかの 必須ブロックの構造からの消失を修正するために、そのようなジャーナルから数値データを収集して処理することがかなり難しいことです。 XMLに似ていますが、まったく「有効」ではありません。
高品質の「ログ」が著者の手書きのようなものであることが重要です。これは同僚のプログラマーによって判断されます。 これは、ソースコード内のコメントや、関数、ファイル、フォルダー、変数の正しい名前と同じくらい重要です。 原則として、ログエントリは、エラー、警告、通知、デバッグメッセージの4つの主なタイプに分けられ、タイムスタンプが提供され、データログへの変換時に最大長、エンコード、および改行（テキスト）を忘れてはならないことを忘れないでくださいログ）、しかし一般に-ログのローテーションについて（アーカイブおよび/または古いログの削除）。
ジャーナリングがある場合、通常、異なるワークステーションまたはサーバーで実行されている複数のアプリケーションの動作を一度に監視するのは簡単です。これらのログのストレージにアクセスし、その場で分析します。
モジュールまたはアプリケーションの動作の監視は多少異なります。 ログがプログラム内で何が起こっているかを示す場合、監視は監視のためのいくつかの重要な指標を知覚するための便利な形で反映します。 確立された境界値を超える場合、監視システムは管理者に受動的に（ログに書き込むことによって）または能動的に（電子メール 、SMS）通知する必要があります。 たとえば、開発者 に電子メールで送信 さ れた致命的なプログラムエラーに関するメッセージは同じ監視であり、外部ではなく内部のみです。
不規則な監視は、自動化されたテストシステムに基づいています。 このようなシステムの構築を原則として可能にするためには、ソフトウェアアーキテクチャで「バッチ」作業の可能性を考慮する必要があります。 一連の既製のテストが入力に送られ、完成した結果が出力されます。 このような監視は、ソフトウェアロジックが変更されるたびに実行できます。
最近、配達時間を計算するシステムに従事。 ロジスティクスの機能を考慮に入れたややトリッキーなアルゴリズムがあります。 計算の正確さをすぐに理解することは不可能であり、計算機とテーブルを準備する必要があります。 したがって、メカニズムが正しく機能するかどうかについての質問に迅速に回答するには、「透明性」を追加する必要がありました。ジャーナルを作成するとき、用語を計算するためのすべてのロジックが反映され、素人に理解される必要があります。 もちろん、それをサイトに反映する必要はありませんでしたが、「配達に15日もかかるということがどうして起こったのか！」などの質問に答えることは非常に簡単でした。 また、自動化されたテストシステムも開発されており、多数の状況の期限をすぐに計算し、結果を手動で計算したものと比較します。
透明性ルール：デバッグツールでソフトウェアをすぐに設計
この規則の意味は、次の2つの仮定で表すことができます。
- アプリケーションは正常に動作するだけでなく、正常に動作することも示す必要があります。
- アプリケーションの「高度なデバッグ」の可能性を提供する必要があります。
または、典型的な
さて、さらに低くなります。 こちらがWindows用のSkypeとICQです。 両方とも
行動のログを記録する必要がある場合の例-海。 そして、1人のユーザーの損失がバケツの低下である大規模な産業ソリューションを検討します。 また、アクセシビリティの要件が高いシステムを扱っている場合はどうでしょうか？ 1秒ごとにカウントされるのはいつですか？
Unixの世界では、「それ自体」として機能する標準コンソールアプリケーションにデバッグモードを含めること、および/またはいわゆるログを保持することをお勧めします。 「ログ」。 デバッグレベルを設定し、アプリケーションの動作を確認します。 そのため、接続を開き、そこにコマンドを投げました。ここでは、応答を受け取りました。ここでは、応答は予期せず、プログラムはエラーを報告しました。 一部の「上級」ユーザーが自分で問題に対処し始めるという事実に加えて、この方法でトラブルシューティングの時間を節約できます。
プログラムはかなり長い時間を経て初めて有用なトレースを残すため、ロギングは便利です。 たとえば、ユーザーが特に気付かないエラーについてログを分析できます。 突然、定期的に表示されますか？ ログから、パフォーマンスデータを取得してグラフを作成し、傾向を分析できます。 ジャーナリングを無効にすることは遅すぎることはありませんが、プログラムに含まれていなかった場合、これを行うのはすでに困難です。
たとえば、ArtPublishingでは、デバッグコンソールは次のようになりました。
上記の例は、正と負の両方で使用できます。 特に、ジャーナルが構造の形で提示されると便利です。 欠点は、たとえば、
高品質の「ログ」が著者の手書きのようなものであることが重要です。これは同僚のプログラマーによって判断されます。 これは、ソースコード内のコメントや、関数、ファイル、フォルダー、変数の正しい名前と同じくらい重要です。 原則として、ログエントリは、エラー、警告、通知、デバッグメッセージの4つの主なタイプに分けられ、タイムスタンプが提供され、データログへの変換時に最大長、エンコード、および改行（テキスト）を忘れてはならないことを忘れないでくださいログ）、しかし一般に-ログのローテーションについて（アーカイブおよび/または古いログの削除）。
ジャーナリングがある場合、通常、異なるワークステーションまたはサーバーで実行されている複数のアプリケーションの動作を一度に監視するのは簡単です。これらのログのストレージにアクセスし、その場で分析します。
モジュールまたはアプリケーションの動作の監視は多少異なります。 ログがプログラム内で何が起こっているかを示す場合、監視は監視のためのいくつかの重要な指標を知覚するための便利な形で反映します。 確立された境界値を超える場合、監視システムは管理者に受動的に（ログに書き込むことによって）または能動的に（
不規則な監視は、自動化されたテストシステムに基づいています。 このようなシステムの構築を原則として可能にするためには、ソフトウェアアーキテクチャで「バッチ」作業の可能性を考慮する必要があります。 一連の既製のテストが入力に送られ、完成した結果が出力されます。 このような監視は、ソフトウェアロジックが変更されるたびに実行できます。
最近、配達時間を計算するシステムに従事。 ロジスティクスの機能を考慮に入れたややトリッキーなアルゴリズムがあります。 計算の正確さをすぐに理解することは不可能であり、計算機とテーブルを準備する必要があります。 したがって、メカニズムが正しく機能するかどうかについての質問に迅速に回答するには、「透明性」を追加する必要がありました。ジャーナルを作成するとき、用語を計算するためのすべてのロジックが反映され、素人に理解される必要があります。 もちろん、それをサイトに反映する必要はありませんでしたが、「配達に15日もかかるということがどうして起こったのか！」などの質問に答えることは非常に簡単でした。 また、自動化されたテストシステムも開発されており、多数の状況の期限をすぐに計算し、結果を手動で計算したものと比較します。
| " 以前：コード保存規則 |
All Articles