【要約】ESLint×GitHub Pagesで始める『コードベース健康診断』― 認知複雑度を定点観測して負債を可視化するダッシュボード構築（フロントエンド編） [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発チームがコードの複雑化による保守性の低下に直面した際、既存の計測手法では以下の課題があった。単一の関数だけでなく、ファイル全体の複雑性を把握することが困難であったためである。
- ・関数単位の閾値設定では、低スコアの関数が無視され、ファイル全体の負債を見逃す。
- ・SonarQube等の本格的なツールは、常時稼働するサーバーの運用コストが高い。
- ・ESLintの標準出力には関数名が含まれず、どの箇所が問題か特定しにくい。
// Approach
開発者が低コストで負債を可視化するため、ESLintの出力をPythonで加工する独自のパイプラインを構築した。サーバーレスでの運用を最優先としたアプローチである。
- ・ESLintの閾値を1に設定し、全関数のスコアを強制的にJSON出力させる。
- ・Pythonスクリプトで、関数単位とファイル単位の二段階で閾値判定を行う。
- ・正規表現を用いて、違反行から最大10行遡り、ソースコードから関数名を抽出する。
- ・計測結果をhistory.jsonに蓄積し、Chart.jsを用いてGitHub Pages上でグラフ化する。
// Result
開発者はサーバー運用コストをかけずに、コードの複雑性の推移をGitHub Pages上で確認可能となった。これにより、負債の定点観測が容易になった。
- ・関数・ファイル両面からの多角的な負債検知を実現した。
- ・関数名の自動取得により、修正すべき箇所の特定コストを削減した。
- ・バックエンドと共通のデータスキーマを採用し、ダッシュボードの統合管理を可能にした。
Senior Engineer Insight
> 非常に賢明な設計である。SonarQubeのような重厚なツールを避け、GitHub Pagesという既存資産で『見せる』仕組みを作った点は、運用コストを最小化する思想として高く評価できる。特に、ESLintの閾値を1にして全データを取得し、後段のPythonで集計する手法は、ツールの制約を回避する優れた回避策だ。ただし、関数名取得の正規表現は言語仕様の変更に弱いため、メンテナンスコストには注意が必要である。実戦投入時は、CI/CDパイプラインへの組み込みを前提とすべきだ。