この記事は、Huawei Cloud Community「コード検査ルールは一般的にどのような指標に焦点を当てていますか?」から共有されたものです。"、著者：gentle_zhou。
コード検査サービスの計測運用ダッシュボードには、前述のアラーム運用モジュール（指標についてはこちらの記事「コード検査のアラーム運用では一般的にどのような指標が重視されているのか？」を参照）に加えて、必ず存在するルール操作です。このモジュールは、コード インスペクション ルールの分析、処理、レポートに焦点を当てています。チーム プロジェクト マネージャーの場合、ルールの全体的なステータスを監視および管理できます。詳細については、以前の記事「コードの静的インスペクションにルールが必要な理由」を参照してください。オペレーション？》。
今日はさらに詳しくお話しますが、ダッシュボードのルール操作モジュールで、ユーザーは一般的にどのような指標に注目しますか? これは、ルール自体の次元のデータ (ルール名、ルールのバージョン、ルールの内容、関連言語、関連ツールとカテゴリ、アラーム カテゴリ、適用範囲) と、ルール関連付け次元のデータ (ルールに関する情報) に大別できます。ルールの保守担当者、ルール 関連する参照シチュエーション、ルールに関連付けられたルール セット。
ルール自体の次元
ルール名
ルールの名前により、ユーザーはルールの意味と機能を大まかに理解できるため、ユーザーはルールを識別および管理しやすくなります。ルール操作の最も基本的な指標の 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 コード検査サービスの分類を取り上げます (分類の列に記載されている「セキュリティ強化機能パッケージ」は、セキュリティ カテゴリの拡張されたブランチであり、一部のセキュリティ問題シナリオのより詳細なスキャンを提供します)。
適用範囲
適用範囲に関しては、まずコード検査ツールの使用方法を簡単に紹介する必要があります。一般的なクラウド サービス、コード ウェアハウスによって提供されるアクセス制御レベルのスキャン、パイプラインによって提供/手動でトリガーされるバージョン レベルのスキャンに加えて、開発者がローカル IDE でコードを開発するために必要な IDE プラグインのスキャンも重要です。この 3 つの利用方法を仮にバージョンレベル、アクセス制御レベル、IDE プラグインレベルと呼ぶと、この 3 つの方法がサービスの適用範囲と言えます。
ルールの場合は適用範囲も影響します。ルールの適用範囲は、ルール自体の特性、コンパイルが必要かどうか、サポート エンジンのスキャンに大量のコンピューティング リソースが必要かどうか、汚染分析が必要かどうかなどに基づいて分割されます。コンピューティング リソースの使用量が少なく、コンパイルを必要としない一部のルールは、IDE プラグインのスキャン範囲として選択できます。運用ダッシュボードのルール操作モジュールでは、適用範囲に応じてルールを分類することで、適用範囲ごとにどのルールを選択して適用できるかを把握できます。
ルールの関連付けのディメンション
ルールに関連付けられた保守責任者情報
ビジネスの発展や業界の脆弱性認識の更新に伴い、ルールは継続的に更新・最適化されるため、オンライン・オフライン、ルールの変更・リリース・管理を担当する専任の保守部門と保守責任者が必要となります。 。
運用ダッシュボードにルールに関連する保守責任者の情報を表示する理由は、一般的に次の 2 つがあります。
- 一般的にルールは設計・開発した本人が将来的にメンテナンスする必要があるため、メンテナンス責任者の情報をダッシュボードに表示することでルールの出典や背景が分かりやすくなり、信頼性が向上します。そしてルールの権威。
- ユーザーがダッシュボードでルール関連の問題や提案を見つけたときに、関連する責任者にすぐに連絡できるため、ユーザーと開発者間のコミュニケーションコストが削減され、便利です。
ルールに関連付けられた参照
ルールが開発されると、それが合理的かつ効果的である限り、そのルールは社内のさまざまな製品ライン、部門、プロジェクトで採用され、使用されます。理論的には、参照が多いほど、そのルールは普遍的な適応性を示します。 、ルールの有効性、影響力。
一般に、ルールに関連する引用情報を操作ダッシュボードに表示する理由は次の 3 つです。
- ユーザーおよびルールの潜在的ユーザーが適用可能なシナリオとルールの使用目的を理解し、適切なルールの選択をサポートし、コード インスペクションの効果を向上できるように支援します。
- ルール整備責任者が自らの策定ルールの適用範囲を理解し、内なる期待効果と比較するとともに、コミュニケーションやコミュニケーションを通じてルールの問題点や不備をタイムリーに発見できるプラットフォームを提供します。これらの使用部門の関係者とのフィードバック。
- コード検査サービスの管理者や監督者にとって、ルールの価値と影響を理解し、異なるルール間の違いを比較および評価するのに便利です。
ルールに関連付けられたルールセット
コード検査サービスのユーザーがルールを使用する場合、スキャン対象のルールを直接選択するのではなく、ビジネス特性、コード仕様、セキュリティ標準、または必要な品質要件に基づいて、いくつかのルールを選択し、それらをセットにマージします。続いて。。このセットは一般にルール セットと呼ばれ、ユーザーが追加、削除、クエリを管理しやすくなります。
操作ダッシュボードの表示ルールはこれらのルール セットによって使用され、ユーザーが以下を理解するのに役立ちます。
- ルールのソースと根拠により、ルールのユーザーは、このルールが部門とプロジェクトに表示される理由、そのルールがどのルール セットから来たのか、現在のプロジェクトで参照するのが適切かどうかを理解できます。
- ルールの帰属と分類により、ルールの保守責任者は、ルールがどのルール セットに収集されるか、その使用法が本来の意図と一致しているかどうか、このシナリオに従ってルールを補足および最適化できるかどうかを理解できます。
- ルールの配布と適用範囲により、コード検査サービスの管理者と監督者はルールの価値と影響を評価し、異なるルール セット内のルールの有効性と信頼性を比較および評価できます。
ひいては、企業の業務量が大きくなり、プロジェクト数が増加すると、必然的にルールセットの数も無制限に増加することになります。したがって、どのルール セットがルールに採用されているかを盲目的に表示するのは良い方法ではありません。全社レベルのルールセットに採用されているかどうかなど、誰もが認める代表的なルールセットをいくつか選んで評価することができ、ルールの影響力や効果が全社的に認められている場合には必ず組み込まれることになります。 . 企業レベルでの一元的なルール。そこで、採用されているすべてのルールセットを表示するのではなく、このルールが全社レベルのルールセットに採用されているかどうかを表示することで、ユーザーに受け入れられやすくなり、ルール保守担当者の改善意欲も促進される可能性があります。
結論は
上記の指標情報に注目することで、関係者はルールに関連する重要なデータを取得することができ、利用者はルールの有効性、合理性、保守性、適応性を理解し、評価することができます。また、ユーザーは、不必要な時間とリソースの無駄を避け、運用と保守の観点から信頼性の低い一貫性のないルールを特定し、不明瞭さと混乱を回避し、ルールの実行効果を向上させることができます。もちろん、最終的な目標はユーザーの満足度を確保することです。 。
クリックしてフォローし、できるだけ早くHuawei Cloudの新しいテクノロジーについて学びましょう~
ブロードコム、既存のVMwareパートナープログラム終了を発表 . サイトBが2度クラッシュ、テンセントの「3.29」レベル1インシデント…2023年のダウンタイムインシデントトップ10を棚卸し、 Vue 3.4「スラムダンク」リリース、 ヤクルトが95Gデータ流出を確認 MySQL 5.7、Moqu、Li Tiaotiao... 2023 年に「停止」される (オープンソース) プロジェクトと Web サイトを棚卸す 「2023 中国オープンソース開発者レポート」が正式リリース 30 年前の IDE を振り返る: のみTUI、明るい背景色…… Julia 1.10が正式リリース Rust 1.75.0がリリース NVIDIAがGeForce RTX 4090 Dを中国で特別販売開始