コードメトリクス計測による課題可視化と品質確保 / Visualize issues and ensure quality by measuring code metrics

Transcript

1. コードメトリクス計測による課題可視 化と品質確保
2. 自己紹介
 森田 勝駿（@texdeath） AI事業本部 AIクリエイティブディビジョン AIタレント事業部 フロントエンドエンジニア • 2021/08 ~ 中途入社 • ツール開発を担当
3. コードメトリクス
4. コードメトリクス • 開発者が開発中のコードをより理解できるようにするソフトウェア の一連の基準 • 開発チームは潜在的なリスクを特定し、プロジェクトの現在の状態 を把握し、ソフトウェア開発中の進行状況を追跡できる Visual Studio IDE > コードメトリック値より引用 https://learn.microsoft.com/ja-jp/visualstudio/code-quality/code-metrics-values
5. モチベーション • チームの具体的な品質指標が欲しかった • まだ未成熟のプロダクトのうちに品質を保証するための道標 が欲しかった • プロダクトの内在的な不具合の種をあぶり出したかった • 品質は保証したいが、Linterでガチガチにルールを固めて開 発スピードを落としたくはない
6. 技術選定
7. 導入を検討したもの • octocov ◦ GitHub Actionsに特化している ▪ シンプルだったがカバレッジレポート生成やバッジの表示など、特 定の機能用途にしか使えなさそう ▪ ローカル環境で試すのが大変そう • SonarCube / SonarCloud ◦ ダッシュボードがあって分析には活用できそう ◦ カスタマイズの敷居が高い ▪ 体系的な知識がないと使いこなすのは難しそうだと判断した ▪ 初期設定に少し手間がかかった
8. ESLintで解析 • 導入が手軽だった ◦ プロジェクトにもともとESLintを導入していたので、拡張が容易 • 拡張性が高かった ◦ 解析→出力のスクリプトを自前で作るので、よりプロジェクトの環境に 合わせた設定ができた ◦ コンフィグの設定次第で柔軟に解析の調整ができるので、落とし所を探 るのにちょうどよかった • ESLint の complexity を使って循環的複雑度を重点的に計測
9. 循環的複雑度 • ＝サイクロマティック複雑度として扱う • コードが複雑になることで、理解や保守が難しくなる度合い • 関数やメソッド内の分岐やループの数によって決まる指標 • 高い循環的複雑度はバグのリスクやテストの困難さを増加させる
10. 解析方法
11. AST構文解析で判定 • 計測用の eslintrc ファイルを 作成 • eslint の静的構文解析を使い json レポートを出力し、そこ から修正すべき箇所を抜き出 すようにした • リポジトリに JavaScript / TypeScript 以外の言語をあ まり入れたくなかったので Node で作成
12. AST構文解析で判定 作成したJSONレポートから必要なルールを抜き出してまとめる
13. より危険そうな箇所を精査 • コードスニペットを抜き出したあとにさらに精査する • 基本的に eslint の plugin で担保できるようなものをチェックする • ECMA Scriptのルールはプロジェクトのlinterでもチェックしてい るので除外
14. 危険度の精査 • プロジェクトではそこまでeslintを 厳しくしていない • 精査時には様々なルールを設定した 専用のconfigを使う • より現場に即した形で使えるように 修正するかどうかはコードの危険度 によって優先度をつける • 優先度と案件対応状況・対応工数に 応じてチケットを切り対応する
15. 現状の悩み
16. MathWorks > 循環的複雑度より引用 https://jp.mathworks.com/discovery/cyclomatic-complexity.html 今の悩み • 循環複雑度の閾値をどうするか ◦ 現在の設定では10以上 ◦ 11~29 であってもテストコードなどで担保できるのであれば、開発 スピードを落とすくらいならある程度は許容すべき？
17. 今の悩み • 関数名のわかりやすさはESlintでは拾いきれない ◦ ChatGPT API を使いプロンプトに関数名を渡してレビューしても らうのもありかも ◦ ただし、そのまま渡すとまずいので名前は汎用化してリクエスト する ◦ プロジェクトを特定しうる単語のブラックリストを作成し、その 単語が関数名内部に登場したら置き換えるなど
18. 今後考えていること
19. 今後考えていること • 頻繁にレポートに出力されるものをドキュメント化する ◦ 一定数ワーニングが出たコンポーネントや関数、ルールに関して は専用のドキュメントを作り、規約化する • CI に組み込む・パッケージ化 ◦ もろもろコストも考えるとあまりやりすぎたくない • 取り組みを始めたばかりなので成果が出たわけではないが、フロント の環境だけで完結して指標が見えたのは光明
20. EOF