運用上注意すべきデータ（コード検査ルール運用上注意すべき10の主要指標）

コード検査ルールを運用する際に注意すべき 10 の指標

この記事は、Huawei Cloud コミュニティ「コード検査ルール オペレーターは一般的にどのような指標に注目しますか? - クラウド コミュニティ - Huawei Cloud」から共有されたもので、著者は gentle_zhou です。

コード検査サービスのメトリック操作ダッシュボードには、前述のアラーム操作モジュール（その指標については、この記事「コード検査アラーム操作は一般的にどのような指標に焦点を当てますか？ - クラウドコミュニティ - Huawei Cloud」を参照してください）が含まれており、もう1つ必須のモジュールはルール操作モジュールです。このモジュールは、コード チェック ルールの分析、処理、レポートに重点を置いています。チーム プロジェクト マネージャーは、ルールの全体的なステータスを監視および管理できます。詳細については、前回の記事「なぜコードの静的チェックでルールを運用する必要があるのか​​？ - クラウドコミュニティ - HUAWEI Cloud」を参照してください。

今日はこれについてさらに詳しくお話しします。ダッシュボード内のルール操作モジュールでは、ユーザーは一般的にどのような指標に注目しますか?ルール自体の次元のデータには、ルール名、ルールバージョン、ルール内容、関連言語、関連ツールとカテゴリ、アラームカテゴリ、適用範囲など、大まかに分類できます。ルール関連のディメンションのデータ: ルールに関連付けられた保守担当者、ルールに関連付けられた参照ステータス、およびルールに関連付けられたルール セットに関する情報。

ルール名により、ユーザーは文字通りの意味からルールの意味と機能を大まかに理解できるため、ルールの識別と管理が容易になります。ルールベースの運用における最も基本的な指標の 1 つとして、ユーザーが会社、業界、部門のルールをすばやく理解して識別し、さまざまな部門がどのルールを好んで使用するかを知るのに役立ちます。

HUAWEI CLOUD CodeArts Checkコードチェックサービスを例にとると、ルール名の設計は明快さとシンプルさに基づいています。

ルールが進化するにつれて、さまざまなメジャー バージョン (1 年または半年にわたる反復) とマイナー バージョン (随時行われる小さな最適化と改善) を含む複数のバージョンが必然的に存在します。バージョンは通常、バージョン番号の別名であり、バージョン番号には通常、ルールの更新ステータスを反映した時刻日付 (作成時刻、変更時刻、オンライン時刻などを表す) も含まれます。

コードチェックサービスの操作ダッシュボードのルール操作モジュールには、ルールバージョンの記録が存在する必要があります。ルール バージョン インジケーターは、ユーザーが異なるバージョンのルールを区別するのに役立つだけでなく、管理者がルールの進化プロセスを理解し、異なるバージョンのルールがビジネスに与える影響、ルール最適化の進化履歴、ルールの安定性を評価するのにも役立ちます。

ルール名によってユーザーがルールの意味を大まかに理解できる場合、ルールの内容は、ルールが何であるか、ルールの背景、ルールを使用できる場所、ルールの正しい例と間違った例、ルールが参照する仕様などをユーザーに明確に理解させるものです。

ルールの内容は、ユーザーがルールを理解し、ルールの確認方法や基準を習得するのに役立つ非常に重要な指標であると言えます。したがって、ルールの内容が完全かつ詳細であるかどうか、またその内容が正確かつ詳細であるかどうかが、運用ダッシュボードのユーザーが気にする点です。

HUAWEI CLOUD CodeArts Checkコード検査サービスを例にとると、概要は説明、正しい例、エラー例、修復提案、およびルール内容の詳細な紹介のための参考資料に分かれています。

ルール開発者は、関連するプログラミング言語とその言語特性に基づいて適応型ルールを設計および開発します。特に、Java、C、C++、Python などの一部の主流言語については、成熟した完全なコード チェック サービスのルールでカバーされるはずです。

運用ダッシュボードでは、言語ごとにルールを分類することで、ルールの可読性と保守性が向上し、ユーザーは言語に基づいてプロジェクトの特性や開発者の言語習慣に合ったルールをフィルタリングし、ルールに一致するエンジンツールを選択して、ビジネスプロジェクトのよりターゲットを絞った検出とスキャンを実行できるようになります。

ルールをコード チェック サービスで機能させたい場合は、ルール自体に加えて、ルールを実行するための対応するエンジン ツールも必要です。どのエンジンがルールを実行するか、また、これらのエンジンが自社開発か、オープンソースか、商用かは、すべてルール ユーザーにとっての懸念事項です。たとえば、一連のルールが部門や専門家によって認識されているものの、実際の適用では、生み出される効果が大きく異なるというシナリオがよくあります。 1 つの可能性は、これらのルールが異なるエンジンと一致することです。一部のエンジンは効果的で、ルールを適切に実行できるため、検査とスキャンの効果が得られます。ただし、マッチングエンジン自体の効率や性能が平均的であれば、スキャン効果が大幅に低下する可能性があります。

Huawei Cloud CodeArts Checkコード検査サービスを例に挙げてみましょう。異なるルールは異なるエンジン ツールに対応しており、ルールの詳細インターフェースのラベルに表示されます。

ちょうど私が「なぜコードの静的チェックはルールを運用する必要があるのか​​？」で述べたように、記事で述べたように、ルールは法律や規制に似ています。では、違反したルールは民事、交通、刑事のカテゴリに属しますか？このとき、表示にはアラームカテゴリが必要です。

一般的に、アラームのカテゴリは、安全性、品質、スタイルの 3 つのカテゴリに分類して表示できます (もちろん、品質とスタイルのカテゴリを組み合わせて表示することもできます)。会社の品質部門が 3 つの主要カテゴリの粒度が粗すぎると感じた場合は、さらに細分化することができます。

Huawei Cloud CodeArts Check コード検査サービスの分類を例に挙げます (分類列に記載されている「セキュリティ強化機能パッケージ」は、セキュリティ カテゴリの拡張ブランチに属し、一部のセキュリティ問題シナリオに対してより詳細なスキャンを提供します)。

適用範囲について言えば、コードチェックツールの使い方を簡単に紹介する必要があります。一般的なクラウド サービス、コード リポジトリによって提供されるアクセス制御レベルのスキャン、パイプライン/手動でトリガーされるバージョン レベルのスキャンに加えて、R&D 担当者がローカル IDE でコードを開発するために必要な IDE プラグイン スキャンも重要です。ここでは、これら 3 つの使用方法を、バージョン レベル、アクセス制御レベル、IDE プラグイン レベルと呼ぶことにします。これら3つの方法がサービスの適用範囲と言えます。

ルールについては適用範囲も有効です。ルールの適用範囲は、ルール自体の特性、コンパイルが必要かどうか、サポートエンジンのスキャンに大量のコンピューティングリソースが必要かどうか、汚染分析が必要かどうかなどに基づいて分割されます。コンピューティングリソースをほとんど占有せず、コンパイルを必要としない一部のルールは、IDE プラグインのスキャン範囲として選択できます。操作ダッシュボードのルール操作モジュールでは、適用範囲に応じてルールを分類することで、ユーザーは異なる範囲内でどのルールを選択して適用できるかを把握できます。

ビジネスの発展や業界の脆弱性に対する認識の変化に応じて、ルールは継続的に更新および最適化されます。したがって、ルールのオンライン、オフライン、変更、リリース、管理を担当する専用の保守部門と保守担当者が必要です。

ルールに関連付けられた保守担当者情報を操作ダッシュボードに表示する理由は 2 つあります。

• 一般的に言えば、ルールを設計および開発した人は、後でそのルールを維持する責任も負う必要があります。そのため、ダッシュボードに保守担当者情報を表示することで、ユーザーはルールの出典や背景を理解しやすくなり、ルールの信頼性や権威性を高めることができます。
• ダッシュボードでルール関連の問題や提案を見つけた場合、ユーザーは関連する責任者にすぐに連絡することができ、ユーザーと開発者間のコミュニケーションコストを削減できます。

ルールが開発されると、それが合理的かつ効果的である限り、社内のさまざまな製品ライン、部門、プロジェクトで採用され、使用されます。理論的には、引用される回数が増えるほど、そのルールの普遍性、有効性、影響力が増すことになります。

操作ダッシュボードにルールに関連する参照情報を表示する理由は 3 つあります。

• ルール ユーザーと潜在的なユーザーがルールの適用可能なシナリオとオブジェクトを理解し、適切なルールを選択できるようにサポートし、コード チェックの有効性を向上させます。
• ルール保守担当者が開発したルールの適用範囲を理解し、その範囲と期待される結果を比較できるようにするためのプラットフォームを提供します。同時に、ユーザー部門の関係者とのコミュニケーションやフィードバックを通じて、ルールの問題や欠陥を迅速に発見することもできます。
• コード チェック サービスの管理者や監督者にとって、ルールの価値と影響を理解し、異なるルール間の違いを比較および評価することは便利です。

ルールを使用する場合、コード チェック サービスのユーザーはスキャンするルールを直接選択しません。代わりに、ビジネス特性と、従う必要のあるコード仕様、セキュリティ標準、または品質要件に基づいて、それらをセットに組み合わせます。通常、このコレクションはルール セットと呼ばれ、ユーザーが追加、削除、クエリを管理するのに便利です。

操作ダッシュボードでルールによって使用されるルール セットを表示すると、ユーザーは次のことを理解しやすくなります。

• ルールのソースと基礎により、ルールのユーザーは、ルールが部門やプロジェクトに表示される理由、ルールがどのルール セットから来ているか、現在のプロジェクトで参照するのが適切かどうかを理解できます。
• ルールの属性と分類により、ルールの保守担当者は、ルールがどのルール セットに収集されるか、そのような使用法が当初の意図と一致しているかどうか、このシナリオに基づいてルールを補足および最適化できるかどうかを把握できます。
• ルールの配布とカバレッジは、コード チェック サービスの管理者と監督者がルールの価値と影響を評価し、異なるルール セット内のルールの有効性と信頼性を比較および評価することをサポートします。

これを拡張すると、会社の業務量が増加し、プロジェクト数が増えると、ルールセットの数は必然的に制御不能に増加します。したがって、どのルール セットがルールを採用したかを単に示すのも良いアプローチではありません。評価のために、いくつかの典型的で認知されているルール セットを選択できます。たとえば、ルールが企業レベルのルール セットに採用されているかどうかなどです。ルールの影響と効果が会社全体で認識されると、そのルールは必ず会社レベルのルールセットに含まれます。したがって、採用されているすべてのルール セットを表示する代わりに、このルールが会社レベルのルール セットによって採用されているかどうかを表示してみることができます。この効果は、ユーザーにとってより受け入れやすくなり、ルールの保守担当者の改善意欲を高める可能性があります。

上記の指標情報に注意することで、関係者はルールに関連する重要なデータを入手でき、ユーザーがルールの有効性、合理性、保守性、適応性を理解し、評価するのに役立ちます。また、ユーザーは、時間とリソースの無駄を回避し、運用と保守の観点から信頼性の低いルールや一貫性のないルールを特定し、曖昧さや混乱を回避し、ルール実行の有効性を向上させることができます。もちろん、最終的な目標はユーザー満足度を確保することです。

#HuaweiCloudDeveloperAlliance# をフォローしてください。以下をクリックして、Huawei Cloud の最新テクノロジーについて学んでください。

Huawei Cloud ブログ_ビッグデータ ブログ_AI ブログ_クラウド コンピューティング ブログ_開発者センター - Huawei Cloud