SonarQube をより有効活用する #JTF2021 #JTF2021_D 髙市 智章 (Tomoaki Takaichi) Jul, 18, 2021 JTF2021

自己紹介 @Takaichi00 tomoaki.takaichi.5 ・髙市 智章（タカイチ トモアキ） ・Java でのシステム開発 ・CI / CD ・Container / k8s ・アジャイル開発実践 共著: クリーンなコードへの SonarQube即効活用術 www.amazon.co.jp/dp/B086ML43DH

❏ なぜ SonarQube を使うのか、SonarQube が生まれた背 景はどのようなものか、SonarQube はどう活用すべきか ❏ SonarQube 1つ1つの細やかな機能を紹介、というよりか は SonarQube をどう活かしていくかということをメイン にお話する 本日お話すること

❏ なぜソフトウェアの品質は重要なのか? ❏ これまでよく行われてきた品質に対するアプローチは何が 課題だったのか? ❏ SonarSource 社が提唱した「Continuous Inspection (継 続的インスペクション)」はこれまでのアプローチとどのよ うに異なるのか? ❏ SonarQube を用いて、品質や技術的負債に対してどのよ うなアプローチを取るべきなのか? 本日お話すること

SonarQube とは

❏ SonarSource 社によって開発されている、ソースコードの静的解析 / 統計情報の収集・表示を行うツール ❏ 25以上のプログラミング言語に対応 ❏ Web UI からダッシュボードが表示でき、解析結果の確認、プロジェク トルールの設定などが可能 ❏ ソースコード管理ツール、CI/CD ツールなどとの連携 ❏ 豊富なプラグイン SonarQube とは 引用: www.sonarqube.org

❏ テストカバレッジ、バグの恐れがあるコードなどを確認 ❏ SonarQube が提示する様々な統計情報から、リファクタリング の指針を得る ❏ Quality Gate を活用し、品質の高いクリーンなコードを保てる ようにする ...などなど SonarQube の活用例 引用: www.sonarqube.org

なぜ SonarQube を使うのか? どうしてどうしてこん なことをしているんだ ろう...? 新入社員の頃の自分

なぜソフトウェア品質は重要なのか

❏ 「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

❏ 「ソフトウェアデリバリのパフォーマンス」を統計的に優位な 形で改善できる24のケイパビリティの中に、「継続的デリバリ 」が含まれている ❏ 組織のパフォーマンス(収益性 / 市場専有率 / 生産性)を向上さ せるために、「継続的なデリバリ」は効果的である 継続的デリバリがソフトウェアパフォーマンスを向上させる 組織のパフォーマンス 継続的なデリバリ 向上

❏ 継続的デリバリの基本原則は以下の5つ 継続的デリバリの基本原則 1. 「品質」の概念を生産工程の最初から組み込んでいく 2. 作業はバッチ処理で進める 3. 反復作業はコンピュータにまかせて人間は問題解決に当たる 4. 徹底した改善努力を継続的に行う 5. 全員が責任を担う ⇒ SonarQube はこれらの原則の実現をサポートする ⇒ソフトウェアデリバリのパフォーマンスが向上 ⇒ 組織のパフォーマンスが向上

❏ ソフトウェアの品質は外部品質と内部品質に分類される 外部品質と内部品質 ● 外部品質: 振る舞いに間違いは無いか、使いやすいかなど 利用時に関わる品質 ● 内部品質: 保守性、柔軟性、 再利用性など、ソフトウェア 内部に関わる品質 ⇒ 今回の発表 (SonarQube) は内部品質にフォーカス

❏ 内部品質 (= 保守性、テスト容易性、理解容易性、変更容易性) が高い状態であればあるほど、開発のリードタイムは短くなる ❏ 短い開発のリードタイムが学びを促進させ、外部品質を生み出 す要因となる 内部品質を高めることでリードタイムを短くできる 出典: 「質とスピード」, https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition?slide=55 ⇒ 継続的デリバリの原則に基づいて SonarQube を活用することで、高い内 部品質の維持を目指す

❏ 「品質」の概念を生産工程の最初から組み込むことで、ソ フトウェアデリバリのパフォーマンスが上がり、組織のパ フォーマンスが上がる ❏ 内部品質を上げることで開発のリードタイムを短くするこ とができ、良い外部品質を生む要因となる ❏ 開発者だけでなく、プロダクトに携わるあらゆる方がこの 認識を持つことが重要と考える ❏ 「品質 (内部品質) は後でいいから機能優先で」という考えに立ち 向かわなければ行けない 品質のまとめ

これまでよく行われてきた品質に対す るアプローチは何が課題だったのか?

❏ 結合テストフェーズ前、もしくはリリース前などにソース コードの品質チェックが実施される ❏ 品質チェックは、開発チームではない第三者による専門家 チームによって実施される。しかし、そこで検出された問 題に対応するのは開発チーム。 これまでよく行われてきた品質管理方法

❏ リリースの遅延、もしくは低品質のままのリリース ❏ 品質問題の発見がリリース直前になり、対応コストも高い ❏ 昔実装したコードを再学習しなければならない ❏ 新たな変更があった場合、以前の品質チェックは陳腐化するため、再度品質 チェックを行わなければならない ❏ 品質向上に関する責任が曖昧 ❏ 品質チェックのチームはコーディングをしないため、「品質が悪いのは開発チーム のせい」と考える ❏ 開発チームは「品質のチェックは品質チームの責任」と考える これまでよく行われてきた品質管理方法の課題

❏ 様々なソフトウェアやソースコードを全て同じ指標で評価する ことのコスト ❏ プロダクトごとに品質の評価指標は異なるはずだが、リリース判定会議などでは不 具合検出数のような絶対的な指標で品質を評価評価してしまいがち ❏ リリース判定会議を通すためだけの無駄なカバレッジ上げ、修正作業が発生 ❏ 品質に関する同一の問題が繰り返し起こる ❏ 品質に関する開発者教育の必要性が考慮されていない ❏ 組織全体としての長期的な品質改善につながらないため、何度も同じよう な品質の問題が繰り返し発生する これまでよく行われてきた品質管理方法の課題

継続的インスペクション (Continuous Inspection)

❏ こうした課題のなか、SonarSource 社は「継続的インス ペクション (Continuous Inspection) を提唱 ❏ Continuous Integration の登場にも触発 ❏ 開発サイクルのなかで内部品質の検査とフィードバックを 定期的に行い、開発の初期段階から品質を高めるというア プローチ (≒ 継続的デリバリーの原則 その1) 継続的インスペクションとは CONTINUOUS INSPECTION (White Paper) : https://www.sonarsource.com/docs/sonarsource_continuous_inspection_white_paper.pdf

1. ソフトウェア品質に関するデータには、開発者や管理者だけでなく、全てのステークホ ルダーからアクセスできる 2. ソフトウェア品質の責任は開発チームが持つ 3. ソフトウェアの品質は開発プロセスの一部、品質基準を満たすことで開発を完了とでき る 4. ソフトウェアの品質要件は客観的なものである。主観的に合格/不合格を判断しない。 5. ソフトウェアの品質要件は、できるだけ全ての製品にも共通なものとする 6. ソフトウェアの品質は、最新のコードを対象に計測する 7. スペルチェッカーのように、修正が容易なうちにエラーを発見する 8. 新たなコードに欠陥が発生した場合は通知を行い、欠陥の追跡と対策の判断を下せるよ うにする 9. 現在の全てのコードと、新しく実装されたコードの両方の品質が確認できる。新しく発 生した欠陥を追跡できる。 10. 新しく発生した欠陥や既存の重要な欠陥に対しては、解決のためのアクションプランを 立てる 継続的インスペクションの10原則

継続的インスペクションの10原則のまとめ 1. 品質に関するデータはいつでも、誰でも確認できるように する 2. 開発チームが品質に関する責任を持ち、オーナーシップを 持って改善行う 3. 品質は開発の初期段階から常に良い状態を保ち、問題が埋 め込まれてもなるべく即時に対応する

❏ 品質起因のリリースの遅延、低品質リリースの解消 ❏ 内部品質は常に高い状態 ❏ 継続的な改善よる変更コストの低減 ❏ 高い内部品質による高い変更容易性 ❏ 品質に対する責任を明確に ❏ 開発チームが責任を持って品質に取り組む ❏ 特性に応じた品質基準を柔軟に定義 ❏ プロダクトに適した品質測定が可能 ❏ 品質に関する同じ問題の繰り返しを予防 ❏ 開発チーム内にナレッジが蓄積されていく 継続的インスペクションが目指す効能

❏ 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 を用いて、プログラミングの参考書だけでは学ぶことのできない教育を継続的に 行うことができる

❏ 「継続的デリバリー」という本では、Continuous Integration はツールではなくプラクティスであると書かれている ❏ Continuous Inspection も同等のことが言える ❏ SonarQube をツールとして導入しているだけでは、継続 的インスペクションは実現されない (= ソフトウェアデリ バリのパフォーマンスは向上しない) ❏ SonarQube が CI に組み込まれ、毎日確認しているが、機能開発 に追われて何もしていないという状態は継続的インスペクション の原則を満たしているとは言えない 「CI」 はツールではなくプラクティス

SonarQube を用いた 品質や技術的負債との向き合い方

❏ なるべくプロダクト開発の最初、イテレーション0のよう な場で SonarQube を CI パイプラインに組み込む ❏ 継続的デリバリの基本原則: 「品質」の概念を生産工程の最初から 組み込んでいく ❏ Quality Profile, Quality Gate の設定も実施 ❏ 類似するプロダクトから Quality Profile, Quality Gate を流用 できないか? 開発の初期段階から CI パイプラインに SonarQube を組み込む Quality Profile: SonarQube がソースコードの分析に使うルールセット Quality Gate: カバレッジ、バグの数などから定める品質基準

❏ Quality Profile, Quality Gate は適当か? ❏ 新たな言語、プラグイン、フレームワークなどを採用して Quality Profile が陳腐化していないか? ❏ Quality Gate の設定値が厳しすぎる、緩すぎることはないか? ❏ setter, getter, 自動生成するコードなどがカバレッジを下げて いないか? 意味のある解析が実施されているか? ❏ 「SonarQube をメンテナンスする時間なんて無い」という状態 は開発がうまく行っていないサインかもしれない ❏ 内部品質を犠牲にして開発スピードを上げるという状態は短期的なもので しかない SonarQube を定期的にメンテナンスする

❏ SonarSource 社のブログでは、技術的負債が発生してい る状態は「水漏れ」に例えられている ❏ 家で水漏れが発生した際、いくら床をモップで拭いても、 新たに発生する水漏れを止めなければ家は水浸しのまま ❏ 新しく発生する水漏れ (=技術的負債) から対処し、その後 床の水 (=残存する技術的負債) を掃除するほうが合理的 技術的負債は「水漏れ」のようなもの 出典: https://blog.sonarsource.com/water-leak-changes-the-game-for-technical-debt-management

SonarLint でリアルタイムに技術的負債を返済する ❏ SonarLint を利用し、IDE からリアルタイムに解析を実行 することで、技術的負債が発生した直後に返済することが できる ❏ 記憶が新しいうちに技術的負債を返済することで、返済の コストを抑えることができる ❏ 「水漏れ」の例が合理的な理由 ❏ 同じ負債でも発生時期が1日前と6ヶ月前では返済のコスト が異なる

❏ CI パイプラインで Quality Gate が失敗したら解決のため のアクションを促す、Quality Gate が失敗したら何かし らの形で通知する ❏ Quality Gate が失敗したらパイプラインを失敗させるとい うのも一つの手 ❏ コミットの都度以外にも、定期的 (例えば毎朝) に SonarQube のメトリクスを確認し、改善のアクションを 起こす 定期的に SonarQube を確認してアクションを起こす

❏ 特に開発がある程度進んだコードに対して SonarQube を 導入した際は、カバレッジや重複率などの Quality Gate の値に何を指定すればいいかわからないことも多い ❏ 「水漏れ」の考えのもと、新しく実装されたコード (On New Code) で「カバレッジが低くないか」「Bug が含ま れていないか」「重複率が多くないか」などを Quality Gate で設定するのが一つの手 Quality Gate の閾値には何を設定するか?

❏ SonarQube の Measures > Project Overview では、上から重 要度が高い順に統計情報の項目が並 んでいる ❏ それぞれの項目で「On New Code」 「Overall」に分類されている ❏ 「On New Code」の負債から重要度 が高い順に返済していく 重要度が高いものから対応する

補足: On New Code ❏ 「On New Code」では、デフォルト期間は「Previous Version」となっている ❏ 例えば Java (Maven Project) であれば、pom.xml で 指定する version が前のものと比較 ❏ その他、日数指定 (1日ごと) や特定のタイミングで実施し た解析との比較を実施することも可能

エンジニア教育に SonarQube を活用する

❏ SonarQube を活用することで、参考書から言語を学ぶだ けでは知ることのできないような知識も取得できる SonarQube を教育ツールとして利用する 例えば新人さんが以下のような税額計算処理を書いたとき、どこが問題でそれ はなぜか、即座にフィードバックできるか?

❏ SonarQube を利用することで、即座に問題と解決策のフィードバック を受けることができ、その言語の経験が浅い開発者でも属人的になり がちな知識を取得できる ❏ SonarQube を通じ、コードの欠陥を直していくことで、チーム内にノ ウハウを蓄積していく SonarQube を教育ツールとして利用する

まとめ

❏ 「品質」の概念を生産工程の最初から組み込むことで、ソ フトウェアデリバリのパフォーマンスが向上する ❏ 内部品質を上げることで開発のリードタイムを短くするこ とができ、良い外部品質を生む要因となる ❏ SonarQube はこれらの考えや継続的インスペクションの 原則を意識した使い方をすることで、より効果を発揮する 発表のまとめ

クリーンなコードへのSonarQube即効活用術 絶賛発売中! おわりに www.amazon.co.jp/dp/B086ML43DH

ご清聴ありがとうございました @Takaichi00 tomoaki.takaichi.5

❏ Cyclomatic Complexity (循環的複雑度) ❏ プログラムの分岐やループなどの制御フローに着目、テストのし やすさから複雑度を計測 ❏ Cognitive Complexity (認知的複雑度) ❏ 人間がソースコードを読むときの理解のしやすさ、ネストが深す ぎるなど可読性にフォーカスして計測 補足: Cyclomatic Complexity と Cognitive Complexity

❏ どちらも Cyclomatic Complexity は “4” 補足: Cyclomatic Complexity と Cognitive Complexity 参考: https://www.sonarsource.com/resources/white-papers/cognitive-complexity/

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