JTF2021 で登壇した 「SonarQube をより有効活用する」の資料です。
https://techfesta.connpass.com/event/213069/
SonarQube をより有効活用する#JTF2021 #JTF2021_D髙市 智章 (Tomoaki Takaichi)Jul, 18, 2021 JTF2021
View Slide
自己紹介@Takaichi00tomoaki.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 は適当か?❏ 新たな言語、プラグイン、フレームワークなどを採用して QualityProfile が陳腐化していないか?❏ 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の値に何を指定すればいいかわからないことも多い❏ 「水漏れ」の考えのもと、新しく実装されたコード (OnNew Code) で「カバレッジが低くないか」「Bug が含まれていないか」「重複率が多くないか」などを QualityGate で設定するのが一つの手Quality Gate の閾値には何を設定するか?
❏ SonarQube の Measures >Project Overview では、上から重要度が高い順に統計情報の項目が並んでいる❏ それぞれの項目で「On New Code」「Overall」に分類されている❏ 「On New Code」の負債から重要度が高い順に返済していく重要度が高いものから対応する
補足: On New Code❏ 「On New Code」では、デフォルト期間は「PreviousVersion」となっている❏ 例えば 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/
takaichi00
ritou
nishiharatsubasa
tk3fftk
tomoaki25
tomzoh
matsuihidetoshi
kazukihayase
oracle4engineer
karawoo
junjikoide
riru
sadonosake
robhawkes
eileencodes
bkeepers
smashingmag
sachag
addyosmani
yeseniaperezcruz
morganepeng
pedronauck
moore
iamctodd
paigeccino