はじめに
このチュートリアルでは、既定のブランチで Code Quality 結果のバックログを確認し、リスクに優先順位を付け、影響が最も大きい結果を解決し、結果を関係者に伝えます。 学習内容:
- ダッシュボードを読み、スコアの意味を理解する方法。
- 修復に優先順位を付け、自動修正を適用するか、 Copilot クラウドエージェントに委任するか、または結果を無視するかを決定する方法。
- 修復作業の影響を伝える方法。
- バックログが再び増加するのを防ぐために実行できる追加の対策。
これはガイド付きチュートリアルであるため、速度よりも理解が優先されます。 自動修正を生成する、または検出結果を却下するための基本的な手順については、関連ハウツー リポジトリ バックログのコード品質の結果を修正する を参照してください。
開始する前に
- Code Quality は、所有または管理しているリポジトリで有効になります。 「GitHub Code Quality の有効化」を参照してください。
- 最近 Code Quality 有効にした場合は、既定のブランチの最初の CodeQL スキャンが完了するまで数分待ちます。
このチュートリアルでは、実行中の例を使用します。ダッシュボードに現在、コード品質の "信頼性: 低品質" と "保守容易性: 公平" のスコアが表示されているリポジトリを使用します。
手順 1: 現在のスコアを評価する
- リポジトリの [ Security and quality ] タブに移動します。
- クリックして コードの品質 を展開し、標準の結果 をクリックします。
信頼性と保守容易性のスコアが表示されます。
これらのスコアは、既定のブランチ上の検出結果に基づいて計算されます。
| Metric | Definition | 結果の例 |
|---|---|---|
| Reliability | コードが目的の関数を正しく、予測可能かつ一貫して実行するかどうかを評価します。 信頼性の高いコードはバグから解放され、エラーを安全に処理し、通常およびエッジケースの条件下で期待どおりに動作します。 | パフォーマンス、コンカレンシー、エラー処理、正確性に関する問題 |
| 保守容易性 | 時間の経過に伴うコードの理解、変更、および拡張がいかに簡単であるかを評価します。 保守可能なコードは、ベスト プラクティスに従い、不要な複雑さを回避し、将来の変更とコラボレーションを容易にするために編成されています。 | 未使用/デッド コード、読みやすさ、複雑さ、競合する名前付け、懸念事項の分離が不十分 |
各スコアは、そのメトリックに依然として存在する検出結果の 最も高い 重大度によって決定されます。 スコアを上げるには、現在の最も高い重大度レベルですべての結果をクリアする必要があります。
この例では、 信頼性 に影響を与える エラー レベルの結果がまだ存在するため、信頼性は "Poor" です。 警告とメモは対処する価値がありますが、エラーがクリアされるまでスコアを移動することはできません。
手順 2: ルールで一覧を読み取り、最も影響の大きい結果に注目する
標準の結果 ビューでは、結果はルール別にグループ化されます。 これは、多くの結果を含む 1 つのルールに 1 つの繰り返しのコーディング習慣が反映される可能性があるため、理解するのに役立ちます。 1 回の出現を理解すると、それらすべてに対して提案された自動修正を理解しやすくなります。これにより、修復が迅速かつ簡単に一括で確認できるようになります。
さらに、いずれかのスコアの重大度レベルを完了するルールを探します。ルールをクリアすると、信頼性に影響する最後の残りの "エラー" が削除された場合、スコアはすぐに上に移動します。
この例では、1 つのルール "上書きされたプロパティ" は、128 件の結果のうち 40 個を占め、40 件すべてがエラー レベルです。 これを解消すると、信頼性に影響するエラーレベルの検出結果がすべて削除され、スコアが次の評価帯に上がります。
手順 3: 結果を解決する
ルールを選択したら、各検索を処理する方法を決定します。
| Assessment | 推奨されるアクション | Notes |
|---|---|---|
| 結果は正当です。 | [ 修正の生成 ] をクリックして pull request を開く | |
| 修正を生成 をクリックすると、AI credits が消費されます。 同じブランチに複数の自動修正を追加して、1 つのプル要求で修復作業をグループ化できます。 | ||
| 結果は適用されません。 たとえば、レガシーコード内にあるもの、意図的なパターン、または誤検知であるものです。 | [ 閉じる] をクリックします。 | 結果は解決済みと見なされ、開いている結果の一覧から削除されます。 |
この例では、40 個の "上書きされたプロパティ" の結果に対して自動修正を生成し、pull request を開きます。 1 つのパターンを共有するため、修正プログラムはほぼ同じです。 CI チェックが通過したら、プルリクエストをマージします。
手順 4: 影響を伝える
修復をマージしたら、"標準の結果" ビューに戻り、キャプチャします。
- 変更されたスコア。 たとえば、 信頼性: 低→公平です。
- ロックを解除した要件。 たとえば、 信頼性に影響するすべてのエラー レベルの結果が解決されました。
- オープンな結果の減少。 たとえば、 128 から 88 まで開きます。
この例では、"上書きされたプロパティ" ルールをクリアすると、信頼性が Poor から Fair に移動します。チームがポイントできる最初のスコア向上です。
これがコードヘルスの他の部分とどう関係するか
新しいプル要求で同じ種類の問題が発生した場合、今日解決したすべての結果が明日に再び表示される可能性があります。 バックログが再生成されるのを停止するには:
- 既定のブランチにマージしきい値を設定 して、新しいコード品質の結果を導入するプル要求をブロックします。 「プル要求のコード品質しきい値の設定」を参照してください。
- プル リクエストに指摘事項が表示されたら修正します。 「コード品質の問題が既定のブランチに到達するのを防ぐ」を参照してください。
Troubleshooting
- 修正プログラムをマージした後にスコアが移動しませんでした。 そのメトリックの現在の最も高い重大度レベルで少なくとも 1 つの検出が開いています。
- スキャンは再実行されていません。 Code Quality スキャンは、既定のブランチにプッシュされるたびに自動的に実行されます。 ワークフローが完了するまで数分待ちます。
まとめ
このチュートリアルでは、リポジトリの品質スコアを評価し、重大度とルール別にバックログ作業を優先し、自動修正を使用して結果を解決し、スコア移動として結果を伝えました。
次のステップ
- 最近変更されたファイルの結果を修正することで、技術的負債をさらに削減します。 「最近マージされたファイルのコード品質の結果を修正する」を参照してください。