Clever Geek Handbook

SonarQubeプラットフォームを使用してコードの品質を管理します





写真50










この記事では、コード品質の継続的な分析と測定のためのプラットフォームであるSonarQubeの主要な機能を検討し、SonarQubeメトリックに基づくコード品質評価方法の利点について説明します。



はじめに



当社はPVS-Studio静的コードアナライザーを開発しています。 適切な開発方法論の選択とそれに続く実証済みの方法とツールの適用により、コードが正しく記述され、最終製品が必要な品質基準を満たす可能性が大幅に高まると確信しています。 そのような方法論の1つは、静的ソースコード分析の使用です。 静的分析は、他のコードメトリックと併用して、コードベースの現在の状態、この状態のダイナミクス、およびプロジェクトの実装中に発生する可能性のあるリスクを評価できます。



最初に、PVS-Studioの分析結果のプレゼンテーションについて簡単に説明します。 PVS-Studio静的アナライザーの結果は、xml形式で保存されます。 検出されたエラーに関するメッセージのリストは、Microsoft Visual Studioウィンドウまたはスタンドアロンユーティリティで直接開くことができ、コードナビゲーション、並べ替え、フィルタリング、誤検知の抑制などを使用してこれらのエラーを処理できます。



写真5







xml形式で見つかったエラーのリストは、読みやすい形式の1つ、たとえばhtmlに変換できます。 分析結果を含むこのようなレポートは、関心のあるすべてのプロジェクト参加者にメールで送信できます。 プロジェクト参加者に通知する別の方法は、エラーリストを作成した開発者にエラーリストを送信することです。 これを行うために、ユーザーはPVS-Studio配布キットで提供される特別なユーティリティを使用できます。



PVS-Studioの機能について言えば、診断メッセージの大量抑制の機能に言及する必要があります 。 コードベースのサイズが大きくなったアプリケーションライフサイクルの後半の段階で静的分析が導入された場合、コード検査により多数のエラーが検出される可能性があります。 おそらくこの時点では、チームにはすべてのエラーを修正するために必要なリソースがありません。 この場合、開発者はコードの現在のリビジョンで発行されたすべてのメッセージを非表示にし、新しく作成または変更されたコードで見つかったエラーに集中できます。



PVS-Studioで検出されたエラー数のダイナミクスは、Microsoft Visual StudioのPVS-Studioプラグインの分析統計機能またはスタンドアロンユーティリティを使用して取得できます。



写真4







ただし、静的アナライザーの結果を表示する上記の方法は単独で存在し、コード行数、循環的複雑度、コード1000行あたりのエラー数、単体テストによるコードのカバレッジレベル、複製など、他のコードメトリックとは関係ありません。 次の分析後に見つかったエラーとこれらのエラーの数に関するレポートでは、質問に答えていません。多くの間違いがあるのか​​、それとも十分ではないのか？ エラー数のダイナミクスは、コードベースの成長にどのように関連していますか？ コード品質は改善されていますか、それとも悪化していますか？ そして、おそらく、マネージャーの最も重要な質問：すべてがいつ機能するか（エラーを修正するのにどれくらい時間がかかりますか）？ これらの質問により、PVS-Studioレポートをより価値があり有益なものにする方法について考えさせられました。



コードメトリックの収集と制御が役立つのはなぜですか？ 測定していないものを改善することは不可能です。 一部のチームがコードメトリックを収集しないとします。 プロジェクトの開発により、コードベースはますます悪化する可能性があり、長い間、ある時点で技術的負債の額が新しい機能のサポートと追加にかかるコストがますます大きくなるまで、誰も気付かないでしょう。 チームがコードメトリックを常に監視している場合、プロジェクトの状態のダイナミクスが確認され、特定のしきい値に達するとアラームが鳴り始めます。



さらに、チームが問題を認識し、マネージャーにコードの品質の改善にリソースを費やす必要があると確信させたとします。 マネージャーは次に、チームに簡単な質問をします。チームがこれを行うにはどれくらい時間がかかりますか？ プロジェクトのどの部分を改善する必要がありますか？ いくつのバグを修正しますか？ コードの品質が必要なレベルに達したことをどのような基準で評価しますか？また、新しい機能の開発に戻ることができますか？ メトリックを使用すると、これらすべての質問に答えられます。 コードの品質向上の作業を開始する前に、チームが製品の各コンポーネントのコードの現在の状態を記録し、各メトリックのしきい値を決定すると、その達成により製品コードが高品質になったというある程度の自信を持って言うことができ、完了日と停止を予測できます特定のしきい値に到達します。 そのため、たとえば、チームはマネージャーに、コードの品質を改善するための作業を完了した後、会社が採用したコーディング標準が95％に達し、コードの重複が5％に減ったなど、ユニットテストのカバレッジレベルが90％に達したことを示すことができます。



SonarQubeを選ぶ理由



SonarQubeは、コード品質の継続的な分析と測定のために設計されたオープンソースプラットフォームです。 SonarQubeは次の機能を提供します。





印象的なリストですね。 SonarQubeの機能に慣れて、リンクhttps://sonarqube.com/をクリックして、実際に試してみてください 。 SonarSourceは、オープンソースプロジェクトを分析するためのこのサービスを提供します。GitHubにオープンソースプロジェクトがある場合は、 https： //sonarqube.com/にアップロードし、SonarQubeレポートを使用してプロジェクトコードの品質を監視できます。



SonarQubeプラットフォームの機能を慎重に検討し、これらの機能がお客様の関心を引く可能性があると判断しました。 そのため、PVS-Studioの分析結果をインポートするためのプラグインを開発することにしました。



ほぼ同時に、お客様の1人が、さまざまなコードメトリックの中央リポジトリを導入することに関心を示しました。 クライアントは、非常に大規模な（1,000万行を超えるコード）および長期（15年を超える活発な開発）プロジェクトを開発します。 当然、そのようなプロジェクトでは、クローゼットに多くの継承されたコードと関連するスケルトンがあり、この場合、私の意見では、プロジェクトコードのステータスとこの状態の変化のダイナミクスを経時的に評価するための一連のメトリックを開発および実装することが絶対に必要です。 当然、クライアントはずっと前にメトリックの収集と分析について決定し、ユニットテスト、テスト実行結果、コードブロックの複製、受け入れられたコーディング標準に従う、コードのコメント密度などのコード品質インジケーターを監視するためのさまざまなユーティリティを導入しました。 .d。 これらのメトリックの収集と並行して、静的コード分析が毎日実行されました。 多数のユーティリティを使用すると、継続的インテグレーションサーバーの構成が複雑になり、追加のスクリプトを作成して各ユーティリティの結果を便利な形式に変換し、すべてのインジケーターを単一のレポートに表示および結合できます。 このアプローチでは、このレポートシステムを作成および維持するためにかなりのリソースが必要でした。



クライアントのニーズとSonarQubeプラットフォームの機能に関する調査に基づいて、このプラットフォームの導入を提案しました。 それが行われました。 実装タスクの一環として、SonarQubeのプラグインが実装され、PVS-Studioの分析結果をSonarQubeにインポートできるようになりました。 SonarQubeの展開プロセスと既存の環境（アセンブリシステム、継続的統合サーバー、バージョン管理システム）との統合は、論理構成メカニズムと多数の詳細なドキュメントによる困難を引き起こしませんでした。 ウィジェットは、クライアントのプロジェクト全体の状態と各プロジェクトのステータスの両方を個別に評価するように構成され、クライアントのニーズ、実行者へのタスクの自動割り当て、全員への通知の配信に応じて、品質プロファイルと品質ゲートが設定されました（これらのSonarQubeメカニズムについては後述します）利害関係者に。



SonarQubeを実装した結果、クライアントは、プロジェクトリスクの評価と予測を可能にするコードメトリックを保存および表示するための集中システムを受け取りました。 個々のツールから一元化されたコード品質管理システムへの移行は、このシステムの展開とサポートを簡素化するだけでなく、プロジェクト管理の分野で飛躍的な進歩を遂げ、プロジェクトのステータスを監視し、情報に基づいた意思決定を行うツールをすべての関係者に提供します。 テスト操作の後、クライアントは既存のALM（アプリケーションライフサイクル管理）ツールキットにSonarQubeを含めることにしました。



SonarQubeは、他のツールとの幅広い統合機能のおかげで、ALMフレームワークの不可欠な部分になりやすいことに注意してください。 SonarQubeのプラグインを使用して、Git、SVN、Mercurial、Team Foundationバージョン管理、ClearCaseのサポートを追加し、LDAP、GitHub、Bitbucket、Azure Active Directoryを介して認証を構成し、サードパーティアナライザーの結果をインポートできます。 IntelliJ IDEA、Eclipse、およびVisual StudioのSonarLintプラグインを使用すると、SonarQubeプロファイルで定義されたルールを使用して、お気に入りのIDEでコードをリアルタイムで分析できます。 Team Foundation ServerおよびVisual Studio Team Servicesとの統合も利用できます。 コード分​​析を実行し、これらのシステムのアセンブリプロセスからSonarQubeにデータを直接インポートするか、たとえば、SonarQubeに組み込まれているQuality Gatesを使用してTeam Foundation ServerおよびVisual Studio Team Servicesでアセンブリの状態を管理できます。 Quality Gateの要件を満たしていない場合、アセンブリは失敗したと見なされます。 したがって、SonarQube開発者は、製品をできるだけオープンにして、開発チームがSonarQubeを環境に統合できるように努めています。



SonarQubeを実装することをお勧めするプロジェクトとチームは何ですか？ 小さなチーム（5人以下）に関与する比較的短期（2〜3か月以内）のプロジェクトでは、SonarQubeを開発プロセスに導入する投資は正当化されない可能性があると思います。 原則として、このようなプロジェクトでは、製品サポートに多額の費用は必要ありません。 そのようなプロジェクトの場合、プロジェクトコードのステータスを監視するための個々のツールに限定することをお勧めします：静的アナライザー、テストによるコードカバレッジの監視、コーディング標準への準拠など。



ライフサイクルが長く、かなりのリソースを必要とする大規模なプロジェクトでは、開発プロセスでのSonarQubeプラットフォームの導入が正当化されます。 さらに、SonarQubeの導入は、プロジェクトの開発のどの段階でも有益です。 私の意見では、最適な戦略は、開発サイクルの初期段階でのSonarQubeの実装です。これにより、チームは最初から品質管理レポートを分析し、設定されたコード品質の基準が遵守されるようになります。 開発の後半でSonarQubeを実装すると、コードの品質を改善するために多額の費用がかかる可能性があります。 そのため、たとえば、静的分析が多数の潜在的なエラーを検出したこと、大量の技術的負債があること、コードがテストでカバーされていないこと、パブリックAPIが文書化されていないことが判明する場合があります。 それでも、ライフサイクルのどの段階でも製品リスクを特定することで、これらのリスクに適切に対応し、それらを最小限に抑えるためのアクションを計画できます。



たとえば、チームは、新しい機能の開発の一環としてコードの一部が変更された場合、このコードのすべての技術的負債がなくなることに同意する場合があります。 発見された欠陥をなくすための投資は、製品のサポートと新しい機能の開発のコストをさらに削減することを可能にします。 また、製品が長い間市場に出回っていて、コード品質検査で多数の問題が明らかになったにもかかわらず、実稼働環境での動作が非常に安定しており、現在、コードベースの品質を改善するのに十分なリソースがない場合、この投資を延期できます。 SonarQubeは、新しいコードに現れた問題に焦点を合わせる機会を提供します。 この機能は、PVS-Studioの大量メッセージ抑制の機能に似ています。



SonarQubeがコード品質を評価する方法



SonarQube品質モデルは、SQALE（ライフサイクルの期待に基づくソフトウェア品質評価）手法の実装に基づいており、特定の機能が追加されています。 ご存じのとおり、SQALE方法論は主に保守性の複雑さに焦点を当てており、プロジェクトのリスクを考慮していません。 たとえば、今日のプロジェクトで重大なセキュリティ問題が発見された場合、SQALE方法論を厳守することで、信頼性、変更可能性、テスト容易性などの既存の問題をすべて排除し、新しい問題にのみ戻らなければなりません。重大な問題。 実際、潜在的な問題がコードに長期間存在し、カスタムバグレポートとして現れない場合、新しいバグの修正に集中することがはるかに重要です。



これを念頭に置いて、SonarQube開発者は、SQALEに基づいて品質モデルを変更し、次の重要な点に焦点を当てました。





標準のQuality Gate SonarQubeは、次のメトリック値を使用して、コードが検証に合格したことを判断します。





Sonarチームは、技術的負債を増やす開発者の7つの大罪を特定しました。





SonarQubeプラットフォームは、これらの7つの罪と戦うために設計されています。



SonarQubeの主な機能を詳しく見てみましょう。



メインページ



SonarQubeのメインページには、システムに追加されたプロジェクトのリストが表示され、各プロジェクトの簡単な統計が表示されます。ビルドバージョン、コードの行数、バグの数、脆弱性、「チョークのあるコード」のサイン、最後の分析の日付：



写真7







メインページのコンテンツは、SonarQubeのプロジェクトのコードのステータスを視覚化できる組み込みウィジェットの大きなセットを使用して、目的に合わせてカスタマイズできます。



プロジェクト指標



プロジェクトのステータスに関する詳細情報を取得するには、プロジェクトメトリックページにアクセスします。



写真9







ここでは、信頼性、セキュリティ、保守性、カバレッジ、複製、サイズ（コードベースサイズ）、複雑さ、ドキュメント（ドキュメント）のコードメトリックに関する情報が提供されます。コード）と問題。



信頼性メトリックに目を向けると、最後の分析で検出されたバグと新しいバグの総数に関する情報、AからEのスケールでのコード信頼性評価が得られます。Eは最低評価で、少なくとも1つが見つかったことを示します。ブロッカーバグ、および見つかったすべてのエラーを排除するために必要な時間：



写真11







SonarQubeプラットフォームを使用すると、プロジェクト全体から個々のモジュールやファイルに至るまで、コードメトリックを上から下まで分析できます。 そのため、たとえば、信頼性評価をクリックすると、信頼性評価の高い順にソートされたプロジェクトファイルのリストが表示されます。 これにより、コードの最も問題のあるセクションに集中できます。



写真13







次に、ソースコードを含むファイルと、エラーが検出されたコードの特定のセクションに移動できます。



写真15







このトップダウンナビゲーションは、他のメトリックでも使用できます。



[セキュリティメトリック]ページには、脆弱性の総数、新しい脆弱性、セキュリティ評価（AからEまでのスケール）、および脆弱性の修正にかかる時間に関する情報が含まれています。



写真17







保守性ページには、プロジェクトの技術的負債に関する情報が含まれています。



写真19







「トップツーボトム」ナビゲーションのおかげで、ダッシュを使用してコード検出の数でソートされたファイルのリストに移動できます。



写真21







そして、注意が必要なコードに直接：



写真23







[カバレッジ]ページには、テストでのコードカバレッジに関する情報が表示されます。



写真25







複製ページには、プロジェクト内のコードの複製に関する情報が含まれています。



写真27







このメトリックを使用すると、重複した行、コードのブロック、さらにはファイル全体を簡単に見つけることができます。



写真29







[サイズ]ページには、プロジェクトのサイズに関する情報（コードの行数、式、関数、クラス、ファイル、ディレクトリ）が含まれています。



写真31







Complexityページには、プロジェクトの総循環的複雑度に関する情報と、関数とファイルの平均複雑度に関する情報が表示されます。



写真33







ドキュメントページには、コード内のコメントに関する情報が表示されます。プロジェクト内の行の総数に対するコメントのある行の割合、コメントのある行の数、パブリックAPIの数、パブリックAPIのドキュメントのレベル：



写真35







プロジェクトメトリックセクションの最後のタブ-問題-コードで見つかった問題の総数（バグ、脆弱性、コードのにおいの合計）、および状態別の問題の分布（未解決、再発見、確認、誤検知、修正しない）が含まれます。



写真37







エラーとコードのナビゲーション



コードメトリックを分析した後、コードで見つかった問題をSonarQubeでどのように処理できるかを見てみましょう。 これを行うには、「問題」セクションに移動します。



写真39







幅広いフィルタリング機能を備えたコードで見つかったすべての問題を次に示します。これにより、最も重要な問題に集中できます。 SonarQubeでは、フィルター設定を保存して再利用できることに注意してください。



エラーメッセージをダブルクリックすると、問題が見つかったコードに移動できます。 エラーの詳細な説明と修正方法に関する推奨事項も利用できます。



写真41







また、バージョン管理システムとの統合により、アナライザーをトリガーしたコードを誰がいつ変更したかが明確であることに注意してください。



写真43







バージョン管理システムとの統合により、SonarQubeのバグを許可した開発者に自動的に割り当てることもできます。 バグを開発者に手動で割り当て、そのタイプ（バグ、脆弱性、コードの匂い）、重大度、タグを変更し、コメントを追加することもできます。 より使いやすくするために、バグの一括変更機能を利用できます。



写真44







ルール、品質プロファイル、品質ゲート



ルール、診断ルール、品質プロファイル、および品質ゲートは、SonarQubeプラットフォームの重要な概念です。 静的コード分析を実行するSonarQubeの各プラグインには、このプラグインが実装する診断ルールの説明を含むリポジトリが含まれています。 これらのルールの違反は、コード内の技術的負債を決定し、問題を修正する時間を計算するために使用されます。 使いやすいように、ルールは品質プロファイルに組み込まれています。 デフォルトでは、SonarQubeはサポートされている各言語のデフォルトの品質プロファイルを作成しますが、便利な診断ルールのセットを使用して独自の品質プロファイルを作成できます。 たとえば、コード品質要件が最も厳しい重要なプロジェクトを分析するには、使用可能なすべての診断を含む品質プロファイルを定義できます。重要度の低いプロジェクトでは、重大なエラーのみを含むそれほど厳しくない品質プロファイルを定義できます。においがする。



品質ゲートは、指定されたしきい値メトリック値を使用したプロジェクトコードのコンプライアンス（または不整合）の指標です。 デフォルトでは、SonarQubeに追加されるすべてのプロジェクトは標準の品質ゲートを使用します。これは、次のメトリックとそのしきい値を定義します。



ソースコードの品質に関する独自の要件に基づいて、標準の品質ゲートを変更したり、関心のあるメトリックとそのしきい値を追加または削除して新しい品質ゲートを作成したりできます。



PVS-StudioおよびSonarQube



解析結果をSonarQubeにインポートするために、sonar-pvs-studio-pluginプラグインを開発しました。 プラグインを使用すると、PVS-Studioアナライザーによって検出されたメッセージをSonarQubeサーバーのメッセージベースに追加できます。 プラグインには、静的アナライザーが実行する診断の説明を含むリポジトリが含まれています。 SonarQubeにプラグインを追加すると、C、C ++、C＃用のPVS-Studioというリポジトリが表示されます。



写真45







プラグインリポジトリのPVS-Studio診断メッセージには、コード例とトラブルシューティングのヒントを含む詳細なエラーの説明が付随します。



写真47







プロジェクトコードを静的に分析し、結果をSonarQubeにインポートした後、フィルターを使用して、たとえばPVS-Studioで見つかった未修正の問題をすべて選択できます。



写真49







PVS-Studioの分析結果をSonarQubeに追加するには、sonar-pvs-studio-pluginプラグインをインストールし、PVS-Studio診断をプラグインリポジトリから品質プロファイルに追加し、sonar.pvs-studio.reportPathプロパティでPVS-Studioレポートファイルにパスを渡します。 SonarQubeスキャナーを起動するとき。



SonarQube開発者は、MSBuildのSonarQube Scannerを使用してMSBuildプロジェクトを分析することをお勧めします。 このスキャナーは、標準のSonarQubeスキャナーのラッパーであり、モジュール（ソリューション内のプロジェクト）を自動的に追加し、分析する必要のあるソースファイルへのパスを書き留めることにより、sonar-project.propertiesスキャナー構成ファイルの作成プロセスを容易にします。



しかし、私たちの観点からは、MSBuildのSonarQubeスキャナーの重要な制限に遭遇しました。



まず、C / C ++プロジェクトを分析する場合、このスキャナーはプロジェクトの.vcxprojプロジェクトファイルのClCompileおよびClIncludeプロパティに追加されたファイルのみを分析用のファイルのリストに追加します。 たとえば、ヘッダーファイルがプロジェクトに明示的に含まれておらず、ソースファイルのいずれかのコードに含まれている場合、このファイルは無視され、このファイルの分析結果はSonarQubeで利用できません。



第二に、MSBuildのSonarQube Scannerは、プロジェクトファイルが配置されているディレクトリよりも、分析のためにディレクトリツリーの上位にあるソースファイルを追加しません。このようなファイルのメッセージもSonarQubeから失われます。



これらの制限に基づいて、標準のSonarQubeスキャナーを使用してPVS-Studio分析結果をインポートすることをお勧めします。このスキャナーを使用するには、sonar-project.properties構成ファイルを手動で作成する必要があります。スキャナーの使用とセットアップについては、記事SonarQube Scannerを使用した分析で説明されています。



デフォルトでは、SonarQubeスキャナーは、ソリューションファイル（.sln）またはプロジェクト（.vcxproj / .csproj）の下のディレクトリツリーにある分析用のソースファイルにインデックスを付けます。ソースファイルがソリューションまたはプロジェクトファイルよりもディレクトリツリー内のsonar.projectBaseDirプロパティで高くなる可能性がある複雑な構造のプロジェクトを分析するには、すべてのソースファイルに最も高い共通ディレクトリを指定する必要があります（極端な場合、これはディスクのルートかもしれません） sonar.sourcesプロパティで、分析用のソースファイル（またはソースファイルへのフルパス）を検索するディレクトリを一覧表示します。



大規模プロジェクトのソースファイルへのパスをsonar.sourcesプロパティに追加するプロセスは非常に時間がかかり、接続されたすべてのヘッダーファイルが含まれていると、簡単ではありません。このタスクを容易にするために、アナライザーの特別な動作モードを実装しました。これにより、SonarQubeスキャナーの構成ファイルを自動的に作成できます。



静的アナライザーを開発するときは、コード内のエラーの検出に焦点を当てており、潜在的な脆弱性やコードの匂いの検索をサポートしていません。そのため、SonarQubeのプラグインを使用する場合、セキュリティと保守性のメトリックは満たされません。プラグインの現在のバージョンは、複製、複雑さ、およびドキュメントの計算を実装していないことにも注意してください。



おわりに



このレビューでは、SonarQubeを使用して、メトリックベースのコード品質管理を実装および適用する方法を示しました。ピーター・ドラッカー（またはおそらくウィリアム・デミング）が言ったように：もしあなたがそれを測定できないなら、あなたはそれを改善することはできない。コードメトリックの定期的な収集、経時変化の分析により、技術的負債が蓄積していること、コードサポートが削減されていることを検出できます。これにより、新機能の開発コストが増加し、製品の新バージョンの提供に伴うリスクが増加します。本「Programmer-pragmatist。」から引用します。見習いからマスター「アンドリュー・ハントとデビッド・トーマスへの旅：



」 « » ( , ) . , . , . « », . , , , .



, , , . , , , , .



あなたは、誰もプロジェクトの「壊れた窓」を回避してそれらを修復する時間がないと思うかもしれません。このように考え続けるなら、ゴミ容器を購入するか、市内の別のエリアに移動することをお勧めします。エントロピーに負けないでください。」



SonarQubeプラットフォームでは、このような「壊れたウィンドウ」を検出できます。 SonarQubeを使用すると、プロジェクトコードのステータスに関する統合レポートにアクセスし、この状態が時間の経過とともにどのように変化するかを見ることができます。トップダウン分析で検出された問題を、プロジェクト全体の関心のあるメトリックの値から特定のコードセクションまで直接調査できますブラウザウィンドウで。 SonarQubeは、コードのトラブルシューティングにかかる​​時間の推定値も提供します。したがって、プロジェクトに大量の技術的負債が蓄積した場合、いつそれを排除する必要があるかをいつでも知ることができます。



SonarQubeの興味深く有用な機能のうち、ALMフレームワークの一部となる他のツールとの統合のための幅広い機能、およびサードパーティのプラグインを使用して既存の機能を拡張する機能にも注目したいと思います。そして、このパワーと利便性はすべて無料ライセンスの下で無料で利用できます。 PVS-Studio静的アナライザーを使用している場合、プラグインを使用して分析結果をSonarQubeにインポートし、その機能を使用してコード品質の問題を調査できます。



SonarQubeプラットフォームの機能に興味がある場合は、ご使用の環境で試してください。 SonarQubeのインストールは非常に簡単で、アーカイブから配布ファイルを抽出し、オペレーティングシステムの実行可能ファイルを実行するだけです。



PVS-Studio静的アナライザーを使用して、C / C ++またはC＃で記述されたプロジェクトを確認することもできます。



便利なリンク









この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Pavel Kusnetsov。 SonarQubeプラットフォームを使用して、ソースコードの品質を管理します。



記事を読んで質問がありますか？
多くの場合、記事には同じ質問が寄せられます。 ここで回答を集めました： PVS-Studioバージョン2015に関する記事の読者からの質問への回答 。 リストをご覧ください。



More articles:


All Articles