Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

【JTF2021】SonarQube をより有効活用する / Effective SonarQube

【JTF2021】SonarQube をより有効活用する / Effective SonarQube

JTF2021 で登壇した 「SonarQube をより有効活用する」の資料です。

https://techfesta.connpass.com/event/213069/

Takaichi00

July 18, 2021
Tweet

More Decks by Takaichi00

Other Decks in Technology

Transcript

  1. 自己紹介 @Takaichi00 tomoaki.takaichi.5 ・髙市 智章(タカイチ トモアキ) ・Java でのシステム開発 ・CI /

    CD ・Container / k8s ・アジャイル開発実践 共著: クリーンなコードへの SonarQube即効活用術 www.amazon.co.jp/dp/B086ML43DH
  2. ❏ なぜソフトウェアの品質は重要なのか? ❏ これまでよく行われてきた品質に対するアプローチは何が 課題だったのか? ❏ SonarSource 社が提唱した「Continuous Inspection (継

    続的インスペクション)」はこれまでのアプローチとどのよ うに異なるのか? ❏ SonarQube を用いて、品質や技術的負債に対してどのよ うなアプローチを取るべきなのか? 本日お話すること
  3. ❏ SonarSource 社によって開発されている、ソースコードの静的解析 / 統計情報の収集・表示を行うツール ❏ 25以上のプログラミング言語に対応 ❏ Web UI

    からダッシュボードが表示でき、解析結果の確認、プロジェク トルールの設定などが可能 ❏ ソースコード管理ツール、CI/CD ツールなどとの連携 ❏ 豊富なプラグイン SonarQube とは 引用: www.sonarqube.org
  4. ❏ 「LeanとDevOpsの科学」では、組織のパフォーマンス (収益性 / 市場専有率 / 生産性) は、「ソフトウェアデリバ リのパフォーマンス」が予測要因の一つとされている なぜソフトウェア品質は重要なのか?

    出典: https://img.ips.co.jp/ij/18/1118101029/1118101029-520x.jpg 出典: https://d2l930y2yx77uc.cloudfront.net/production/uploads/images/17728222/picture_pc_7ad9d39bff46bb8813d1c7c8812fa5c9.png
  5. ❏ 「ソフトウェアデリバリのパフォーマンス」を統計的に優位な 形で改善できる24のケイパビリティの中に、「継続的デリバリ 」が含まれている ❏ 組織のパフォーマンス(収益性 / 市場専有率 / 生産性)を向上さ

    せるために、「継続的なデリバリ」は効果的である 継続的デリバリがソフトウェアパフォーマンスを向上させる 組織のパフォーマンス 継続的なデリバリ 向上
  6. ❏ 継続的デリバリの基本原則は以下の5つ 継続的デリバリの基本原則 1. 「品質」の概念を生産工程の最初から組み込んでいく 2. 作業はバッチ処理で進める 3. 反復作業はコンピュータにまかせて人間は問題解決に当たる 4.

    徹底した改善努力を継続的に行う 5. 全員が責任を担う ⇒ SonarQube はこれらの原則の実現をサポートする ⇒ソフトウェアデリバリのパフォーマンスが向上 ⇒ 組織のパフォーマンスが向上
  7. ❏ リリースの遅延、もしくは低品質のままのリリース ❏ 品質問題の発見がリリース直前になり、対応コストも高い ❏ 昔実装したコードを再学習しなければならない ❏ 新たな変更があった場合、以前の品質チェックは陳腐化するため、再度品質 チェックを行わなければならない ❏

    品質向上に関する責任が曖昧 ❏ 品質チェックのチームはコーディングをしないため、「品質が悪いのは開発チーム のせい」と考える ❏ 開発チームは「品質のチェックは品質チームの責任」と考える これまでよく行われてきた品質管理方法の課題
  8. ❏ こうした課題のなか、SonarSource 社は「継続的インス ペクション (Continuous Inspection) を提唱 ❏ Continuous Integration

    の登場にも触発 ❏ 開発サイクルのなかで内部品質の検査とフィードバックを 定期的に行い、開発の初期段階から品質を高めるというア プローチ (≒ 継続的デリバリーの原則 その1) 継続的インスペクションとは CONTINUOUS INSPECTION (White Paper) : https://www.sonarsource.com/docs/sonarsource_continuous_inspection_white_paper.pdf
  9. 1. ソフトウェア品質に関するデータには、開発者や管理者だけでなく、全てのステークホ ルダーからアクセスできる 2. ソフトウェア品質の責任は開発チームが持つ 3. ソフトウェアの品質は開発プロセスの一部、品質基準を満たすことで開発を完了とでき る 4. ソフトウェアの品質要件は客観的なものである。主観的に合格/不合格を判断しない。

    5. ソフトウェアの品質要件は、できるだけ全ての製品にも共通なものとする 6. ソフトウェアの品質は、最新のコードを対象に計測する 7. スペルチェッカーのように、修正が容易なうちにエラーを発見する 8. 新たなコードに欠陥が発生した場合は通知を行い、欠陥の追跡と対策の判断を下せるよ うにする 9. 現在の全てのコードと、新しく実装されたコードの両方の品質が確認できる。新しく発 生した欠陥を追跡できる。 10. 新しく発生した欠陥や既存の重要な欠陥に対しては、解決のためのアクションプランを 立てる 継続的インスペクションの10原則
  10. ❏ 品質起因のリリースの遅延、低品質リリースの解消 ❏ 内部品質は常に高い状態 ❏ 継続的な改善よる変更コストの低減 ❏ 高い内部品質による高い変更容易性 ❏ 品質に対する責任を明確に

    ❏ 開発チームが責任を持って品質に取り組む ❏ 特性に応じた品質基準を柔軟に定義 ❏ プロダクトに適した品質測定が可能 ❏ 品質に関する同じ問題の繰り返しを予防 ❏ 開発チーム内にナレッジが蓄積されていく 継続的インスペクションが目指す効能
  11. ❏ SonarQube は SonarSource 社が開発しているというこ ともあり、継続的インスペクションの10原則に従っている 10原則と SonarQube の対応 1.

    SonarQube のダッシュボードは Web UI から誰でも確認することができる 2. SonarQube を CI (Continuous Integration) に組み込むことで、開発プロセスの一部に内部品 質の担保を組み込むことができる 3. Google Coding Style, Airbnb JavaScript ガイドなどの有名なルールを Quality Profile (プロ ジェクトの品質基準) として適応し、品質を客観的に確認できる 4. Quality Profile を他のプロジェクトに流用することで、均一な条件で品質を測定できる 5. IDE と統合し、コードの欠陥をリアルタイムに発見できる 6. 既存の欠陥と新規に発生した欠陥の両方を測定できる 7. SonarQube を運用することで開発チームが品質に対するアクションプランを立てることがで きる 8. SonarQube を用いて、プログラミングの参考書だけでは学ぶことのできない教育を継続的に 行うことができる
  12. ❏ 「継続的デリバリー」という本では、Continuous Integration はツールではなくプラクティスであると書かれている ❏ Continuous Inspection も同等のことが言える ❏ SonarQube

    をツールとして導入しているだけでは、継続 的インスペクションは実現されない (= ソフトウェアデリ バリのパフォーマンスは向上しない) ❏ SonarQube が CI に組み込まれ、毎日確認しているが、機能開発 に追われて何もしていないという状態は継続的インスペクション の原則を満たしているとは言えない 「CI」 はツールではなくプラクティス
  13. ❏ なるべくプロダクト開発の最初、イテレーション0のよう な場で SonarQube を CI パイプラインに組み込む ❏ 継続的デリバリの基本原則: 「品質」の概念を生産工程の最初から

    組み込んでいく ❏ Quality Profile, Quality Gate の設定も実施 ❏ 類似するプロダクトから Quality Profile, Quality Gate を流用 できないか? 開発の初期段階から CI パイプラインに SonarQube を組み込む Quality Profile: SonarQube がソースコードの分析に使うルールセット Quality Gate: カバレッジ、バグの数などから定める品質基準
  14. ❏ Quality Profile, Quality Gate は適当か? ❏ 新たな言語、プラグイン、フレームワークなどを採用して Quality Profile

    が陳腐化していないか? ❏ Quality Gate の設定値が厳しすぎる、緩すぎることはないか? ❏ setter, getter, 自動生成するコードなどがカバレッジを下げて いないか? 意味のある解析が実施されているか? ❏ 「SonarQube をメンテナンスする時間なんて無い」という状態 は開発がうまく行っていないサインかもしれない ❏ 内部品質を犠牲にして開発スピードを上げるという状態は短期的なもので しかない SonarQube を定期的にメンテナンスする
  15. ❏ SonarSource 社のブログでは、技術的負債が発生してい る状態は「水漏れ」に例えられている ❏ 家で水漏れが発生した際、いくら床をモップで拭いても、 新たに発生する水漏れを止めなければ家は水浸しのまま ❏ 新しく発生する水漏れ (=技術的負債)

    から対処し、その後 床の水 (=残存する技術的負債) を掃除するほうが合理的 技術的負債は「水漏れ」のようなもの 出典: https://blog.sonarsource.com/water-leak-changes-the-game-for-technical-debt-management
  16. ❏ CI パイプラインで Quality Gate が失敗したら解決のため のアクションを促す、Quality Gate が失敗したら何かし らの形で通知する

    ❏ Quality Gate が失敗したらパイプラインを失敗させるとい うのも一つの手 ❏ コミットの都度以外にも、定期的 (例えば毎朝) に SonarQube のメトリクスを確認し、改善のアクションを 起こす 定期的に SonarQube を確認してアクションを起こす
  17. ❏ 特に開発がある程度進んだコードに対して SonarQube を 導入した際は、カバレッジや重複率などの Quality Gate の値に何を指定すればいいかわからないことも多い ❏ 「水漏れ」の考えのもと、新しく実装されたコード

    (On New Code) で「カバレッジが低くないか」「Bug が含ま れていないか」「重複率が多くないか」などを Quality Gate で設定するのが一つの手 Quality Gate の閾値には何を設定するか?
  18. ❏ SonarQube の Measures > Project Overview では、上から重 要度が高い順に統計情報の項目が並 んでいる

    ❏ それぞれの項目で「On New Code」 「Overall」に分類されている ❏ 「On New Code」の負債から重要度 が高い順に返済していく 重要度が高いものから対応する
  19. 補足: On New Code ❏ 「On New Code」では、デフォルト期間は「Previous Version」となっている ❏

    例えば Java (Maven Project) であれば、pom.xml で 指定する version が前のものと比較 ❏ その他、日数指定 (1日ごと) や特定のタイミングで実施し た解析との比較を実施することも可能
  20. ❏ Cyclomatic Complexity (循環的複雑度) ❏ プログラムの分岐やループなどの制御フローに着目、テストのし やすさから複雑度を計測 ❏ Cognitive Complexity

    (認知的複雑度) ❏ 人間がソースコードを読むときの理解のしやすさ、ネストが深す ぎるなど可読性にフォーカスして計測 補足: Cyclomatic Complexity と Cognitive Complexity
  21. ❏ どちらも Cyclomatic Complexity は “4” 補足: Cyclomatic Complexity と

    Cognitive Complexity 参考: https://www.sonarsource.com/resources/white-papers/cognitive-complexity/
  22. ❏ Cognitive Complexity は左が “7” で右は “1” ❏ 人間の読みやすさ、可読性にフォーカス 補足:

    Cyclomatic Complexity と Cognitive Complexity 参考: https://www.sonarsource.com/resources/white-papers/cognitive-complexity/