Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
【JTF2021】SonarQube をより有効活用する / Effective SonarQube
Search
Takaichi00
July 18, 2021
Technology
0
2.2k
【JTF2021】SonarQube をより有効活用する / Effective SonarQube
JTF2021 で登壇した 「SonarQube をより有効活用する」の資料です。
https://techfesta.connpass.com/event/213069/
Takaichi00
July 18, 2021
Tweet
Share
More Decks by Takaichi00
See All by Takaichi00
自分から始めるアジャイルの道 ~内発的動機をきっかけに変わった価値観~
takaichi00
0
110
Java developer introduced to Rust-ADC2022
takaichi00
0
210
野球人・落合博満さんから学ぶ、アジャイルなマインドセット・プラクティス
takaichi00
1
750
【CICD2021】デプロイメントパイプラインの原理原則を再確認する / Confirm Deployment Pipeline Principle
takaichi00
11
4.3k
JJUG CCC 2021 Spring-Resolving OOME with JFR
takaichi00
2
3k
【Yahoo! JAPAN Agile 2nd】野球人・落合博満さんから学ぶスクラムマスター / デベロッパー
takaichi00
0
2.6k
【Developers Boost 2020】凡人エンジニアの生存戦略
takaichi00
1
2.6k
【ソフトウェアテスト自動化カンファレンス2020】CI パイプラインでのテスト戦略とその実現方法
takaichi00
3
5.2k
【JJUG CCC 2020 Fall】Selenide + Cucumber で実現する UI テスト自動化 + BDD
takaichi00
0
1.6k
Other Decks in Technology
See All in Technology
WINTICKETアプリで実現した高可用性と高速リリースを支えるエコシステム / winticket-eco-system
cyberagentdevelopers
PRO
1
190
Product Engineer Night #6プロダクトエンジニアを育む仕組み・施策
hacomono
PRO
1
460
Nix入門パラダイム編
asa1984
2
200
新R25、乃木坂46 Mobileなどのファンビジネスを支えるマルチテナンシーなプラットフォームの全体像 / cam-multi-cloud
cyberagentdevelopers
PRO
1
130
わたしとトラックポイント / TrackPoint tips
masahirokawahara
1
240
「視座」の上げ方が成人発達理論にわかりやすくまとまってた / think_ perspective_hidden_dimensions
shuzon
2
130
チームを主語にしてみる / Making "Team" the Subject
ar_tama
4
300
よくわからんサービスについての問い合わせが来たときの強い味方 Amazon Q について
kazzpapa3
0
220
ネット広告に未来はあるか?「3rd Party Cookie廃止とPrivacy Sandboxの効果検証の裏側」 / third-party-cookie-privacy
cyberagentdevelopers
PRO
1
130
コンテンツを支える 若手ゲームクリエイターの アートディレクションの事例紹介 / cagamefi-game
cyberagentdevelopers
PRO
1
120
マネジメント視点でのre:Invent参加 ~もしCEOがre:Inventに行ったら~
kojiasai
0
460
LeSSに潜む「隠れWF病」とその処方箋
lycorptech_jp
PRO
2
120
Featured
See All Featured
KATA
mclloyd
29
13k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Git: the NoSQL Database
bkeepers
PRO
425
64k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
Designing the Hi-DPI Web
ddemaree
280
34k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
It's Worth the Effort
3n
183
27k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
664
120k
Making the Leap to Tech Lead
cromwellryan
132
8.9k
Designing on Purpose - Digital PM Summit 2013
jponch
115
6.9k
Transcript
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/