Upgrade to Pro — share decks privately, control downloads, hide ads and more …

人類よ! コードレビューも完全自動化の時代へ?!今風なイケてる静的解析を大活用しよう! / Automated Code Review

Dai Fujihara
September 16, 2021

人類よ! コードレビューも完全自動化の時代へ?!今風なイケてる静的解析を大活用しよう! / Automated Code Review

mabl Japan コミュニティウェビナーでは、mablを導入・実践するユーザー企業さまによる経験、実践情報を共有していただいたり、ソフトウェア品質やテスト自動化のエキスパートをお招きしてその知見を発信していただいております。

今回のテーマは「静的コード解析 & コードレビュー」です。

mablはブラウザのE2Eテストをノーコード・ローコードで自動化するツールですが、品質を作り込むには、 最後の最後にテストをしている場合ではありません。なぜなら、「テスト」がボトルネックになってしまうからです。

よって、仕様検討や設計といったコーディングの前段階でのテストも重要になってきます。コーディング中のテストも重要でしょう。

ゲストとして自動コードレビューサービスを提供するSider代表の浅原明広氏と、創業者である角幸一郎氏をお招きします。

浅原氏はUSに生活・ビジネス拠点を置きながら、現在は開発者体験を向上するツールのPdMとして活躍されています。

角氏は2014年に国内で自動コードレビューサービス sider.review を立ち上げ、2018年にUS拠点を設立して、日米両方でビジネスを推進されています。

今なぜ静的解析なのか? 次世代の静的解析はどうなっていくのか? コードレビューゼロの時代はやってくるのか?

日米それぞれのビジネス環境の違いを理解する両氏を交え、今後の開発プロセスのありかたを議論していきます。

イベントURL: https://mabl-japan.connpass.com/event/219463/
Sider社: https://siderlabs.com/?lang=ja

Dai Fujihara

September 16, 2021
Tweet

More Decks by Dai Fujihara

Other Decks in Programming

Transcript

  1. About Me 『アジャイル開発とスクラム』 https://www.amazon.co.jp/dp/4798129704/ 、『リーン開発 現場』 https://www.amazon.co.jp/dp/427406932X 藤原 大 /

    Dai Fujihara Japan Lead at mabl Inc. CEO at Sekai Co., Ltd. • 現在: 独立してスーパーアジャイルコーチ 開発組織 技術顧問(プロセス、 QA中心) CTOやEMへ コーチング mabl 日本顧客向け業務全般担当 • メルカリ: エンジニアリングマネージャ( EM) Software Engineer in Test(SET) テスト自動化、QA組織立ち上げ • 楽天: EM、アジャイルコーチ • 某SIer: Javaエンジニア • 活動: ◦ 『アジャイル開発とスクラム』寄稿 ◦ 『リーン開発 現場』翻訳 ◦ Twitter: @daipresents ◦ https://daipresents.com/service/
  2. なぜコードレビュー? • こ ウェビナーで アジャイル ・DevOps時代 開発とテスト あり かたを追い求めています •

    アジャイルテスティング 実践 た めに コードレビュー 自動化も有 効です • 今回コードレビューと静的解析 未 来をさぐる旅です
  3. こ ウェビナーで目指すこと • テスト自動化 実践者 話を聞き ながらわいわいする • テスト自動化 成功例が今後増

    えていくため プラクティスを探る • 実践的なアジャイルテスティング が国内でどんどん出てくることを 祈って
  4. 注意点 • 動画 後日公開予定です • Discord 録音公開しません • SNS共有OKです •

    質問 ご自由に投稿ください。 チャットへ 書き込みも大歓迎で す • イベント後 10秒アンケートにご 協力ください
  5. 自己紹介 浅原明広 株式会社Sider ・代表取締役社長 ハワイにある"す る望遠鏡"用 ガンマ線検出器を開発し、かに星雲 研究に20代を捧げ、宇宙物理学分野で博士号取得しました。そ 後、エン ジニアとしてIT分野にキャリアチェンジ。 IBMから株式会社Fixstars

    を経 て、2012年からカリフォルニアに生活・ビジネス 拠点を移し、現在、株式 会社Sider にてDeveloper Experience を向上させるSaaS ソリューション 開発・販売を行っています。 角幸一郎 株式会社Sider・Sider事業担当執行役員 2009年からフリーランスとしてiOS, Android, Ruby(Sinatra, RoR), Java, PHPなどでスマートフォンアプリやサーバサイドアプリケーション、SDK 開 発などを行ってきました。2012年に法人を作り、そ ち、2014年に Siderを創業。2019年10月より株式会社Siderに統合、 ソフトウェア開発 者がより製品 開発に集中出来るような世界を作るべく、開発者・開発 チーム向け 製品を提供しています。
  6. Sider 製品群 Sider Scan Sider 製品概要: - 自動コードレビューサービス - サーバー駆動(オンプレ、クラウド)

    - GitHub/GitLab と接続し、連携 - 有償(1500円/シート/月) 製品概要: - 重複コード分析に基づく修正漏れ検 知ツール - リポジトリを監視し、怪しいコードを見 つけたら通知 - 1リポジトリ 解析 無償 2リポジトリ目から有償 将来的に 機能 取り込み https://siderlabs.com/scan/ https://sider.review/ 17
  7. Sider 製品概要 • 機能1 コードレビュー機能 ◦ 利用シーン: Pull Request/Merge Request

    ◦ 概要: 30以上 解析機で対象となるコードを 分析し、問題点を指摘 • 機能2 コード品質分析機能 ◦ 利用シーン: 振り返り、統合テスト時、 リリー ス前後、など ◦ 概要: クローン、複雑性、コード規模など、 様々なソフトウェアメトリクスからコード 品 質を分析 2. コード品質分析機能 (Sider Web UI) 1. コードレビュー機能 (Sider Web UI or GitHub/Lab 画面) or * *GitLab 版で 機能2 現時点で 利用できません クラウド・オンプレ駆動 https://sider.review/
  8. Sider Scan 製品概要 19 1. リポジトリを監視 2. 変更漏れなど バグを検出し  チームに通知

    1リポジトリ 無償利用可能 今すぐダウンロード https://siderlabs.com/ リポジトリを監視し、ソースコード内に潜むバグを自動検出 不具合 発生を未然に防ぎます
  9. Sider Scan 提供する機能 1. 独自アルゴリズム* で重複コードを高速検出 2. 記述パターンを分析し、変更漏れ等 バグを自動検出 3.

    発見した問題コードを通知 21 Sider Scan で実際に見つかった変更漏れバグ 例 : cdev_count をz_count に変更する を忘れている (Intel Thermal Daemon: https://github.com/intel/thermal_daemon) *特許申請中技術 // get cooling device count uint cooling_device_count; QDBusReply<uint> cdev_count = iface->call("GetCdevCount"); if (cdev_count.isValid()) { cooling_device_count = cdev_count; } else { qCritical() << "error from" << iface->interface() << "=" << cdev_count.error(); return false; } コピー元 // get zone count uint zone_count; QDBusReply<uint> z_count = iface->call("GetZoneCount"); if (z_count.isValid()) { zone_count = z_count; } else { qCritical() << "error from" << iface->interface() << "=" << cdev_count.error(); return false; } cdev_count を z_count に 修正する を忘れていませんか? コピー先
  10. どうやって修正漏れを見つける ? • 修正漏れ検知アルゴリズム1: パターン分析 ◦ 重複コードペア間 コード 「違い」に注目して、「変更パターン」を辞書化 ◦

    重複コード 各行が、作成した「変更パターン」に沿っているかを確認。逸脱する記述を見つ け、変更案とともに指摘 変更漏れ指摘 例: コードクローンにおいて他 変数 型が全て揃っている (緑網掛け) に対して、指摘 引数 (赤網掛け) だけshort で定義されている → 記述パターンに合わないためバグ 可能性がある 22
  11. どうやって修正漏れを見つける ? • 修正漏れ検知アルゴリズム2: 時系列分析 ◦ 重複ペア間 コード 「過去」と「現在」に注目 ◦

    「過去」 完全一致であった に、「現在」 ペア間でコードが異なる行を見つけたら、修正漏 れとして指摘する 現在 過去 23
  12. バグらしさ 評価 • 実際に 、これら 修正漏れ検知アルゴリズムだけだと、大量 誤検知 (偽陽性) が発生します •

    後段処理で、それぞれ 指摘 「優先度」を独自 アルゴリズムで評価し、優先的に見ていた だきたい(おそらくバグに近い) 順でソートします。 • こ 評価処理で、ヒューリスティクスと機械学習による分類を組み合わせています。 24
  13. 実際にあった!著名OSS で 修正漏れバグ 実際に50以上 著名OSSで修正漏れバグを見つけています • OmegaT (翻訳ソフト, プルリクエストマージ済 )

    ◦ https://github.com/omegat-org/omegat/pull/98 • クロノスグループ SPIRV-Tools (グラフィックス言語SPIR-V向けツール群, プルリクエストマージ済 ) ◦ https://github.com/KhronosGroup/SPIRV-Tools/issues/4497 • Google V8 (JSエンジン, プルリクエストレビュー中 ) ◦ https://chromium-review.googlesource.com/c/v8/v8/+/2897323 • phpMyAdmin (MySQL 管理ツール, プルリクエストマージ済 ) ◦ https://github.com/phpmyadmin/phpmyadmin/pull/16904 • Apache Kafka (分散データストリーミング・プラットフォーム , プルリクエストマージ済 ) ◦ https://issues.apache.org/jira/browse/KAFKA-13248 • Vercel 社 Hyper (ターミナルエミュレーター , プルリクエストマージ済 ) ◦ https://github.com/vercel/hyper/issues/5911 • そ 他、NVIDIA, ARM, Intel, Cisco 等 オープンソースプロジェクトでも多数 バグを発見 プルリクエスト準備中 25
  14. 修正漏れ 例1 • おそらくコピペしたと思われる、 2つ 異なるファイル間 重複 コードで、左 ”TimeOrderWindowsStoreBuilde に関する処

    理、コピー元と思われる右 ”WindowStoreBuilde” に関する処 理を行っている。しかし、左 コードで、 WindowStoreBuilder 修正を忘れている • コミュニティに指摘したところ、確かにバグであるとして Pull Request マージ済 • OSS: Apache Kafka • 概要: 大規模チャットサービスなどに採用されてい る分散データストリーミング・プラットフォーム • 言語: Java, Scala • リポジトリ: https://github.com/apache/kafka 26
  15. 修正漏れ 例2 • OSS: Wordpress • 概要: コンテンツ・マネジメントシステム言語 : PHP,

    JS • リポジトリ: https://github.com/WordPress/WordPres s /WordPress-extract/wp-includes/sodium_compat/src/Core32/Curve25519.php (同一ファイル内部で 重複コード ) • 左右 重複箇所を見比べた際に、明らかにインスタンス名 がずれている • 自動生成されたようなコード 連続 (3003行)で、人間 レ ビューで 間違いに気づきにくい 27
  16. 実務に最適なコードレビューガイドライン - 1000 OSSで共通して守られるルール みをSider コーディングガイドラインに採 用。カスタマイズも可能。 多く 人がLinterでチェックしているが実 際に

    守っていないルールをSiderで 無 効化している。以下各言語ごと無効にして いるデファクトなルール数一例 - JS: 2〜 - Python: 26〜 - Java: 多量 - Ruby: 31〜
  17. コード品質 可視化と改善 コード 変更頻度が高い = リファクタリングする意義がある 各種 メトリクスが悪い = 生産性を落としている原因である

    可能性が高い 上記 2軸でリファクタリングする価 値 あるコード(ファイル)を可視化 し、改善を促す
  18. 組織内で ナレッジ 共有 一部引用元: https://github.com/sider/goodcheck-rules 社内で頻回に起こるタイプミス、表記ゆれを抑止 pattern: Github message: Did

    you mean "GitHub"? pattern: ヶ月 message: | Did you mean "か月"? DB 変更時に行ってほしいことを提示 pattern: "ActiveRecord::Schema.define" glob: "db/schema.rb" message: | This PR changes the database schema. When doing a DB migration, please follow these steps: CSS アンチパターンを明示 pattern: regexp: '\s(z-index:)\s*(?!.*\$.*)' glob: '**/*.{css,scss}' message: | z-indexを指定するときに 変数を使ってください。 反映される優先順位がわかりづらくなります。