【要約】コードをグラフにしたら、リファクタリングの優先順位が見えた [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
- ・「なんとなく汚い」という主観によるリファクタリングの優先順位付け。
- ・grep等を用いた手動の影響範囲調査による、膨大な工数と精度の低さ。
- ・変更が及ぼす破壊的影響の予測困難さ。
- ・技術的負債の返済に関する、ステークホルダーへの説明不足。
// Approach
1.Tree-sitterを用いてソースコードを解析し、AST（抽象構文木）を抽出する。
2.関数やクラスをノード、呼び出しや継承をエッジとするナレッジグラフを構築する。
3.グラフ探索により、変更点からの距離（Hop数）で影響範囲を特定する。
4.Cypherクエリを用いて、以下の要素を抽出する。
- 影響範囲（Blast Radius）が大きい関数- 循環依存（Circular Dependency）が発生しているモジュール
// Result
- ・影響範囲（Hop 1ノード数）に基づく、客観的なリファクタリング優先度の導出。
- ・Cypherクエリによる、重要関数や循環依存の迅速な特定。
- ・技術的負債の議論を、主観的な感覚から数値ベースの議論へと変革。
Senior Engineer Insight
> 大規模開発において、影響調査のコスト削減は喫緊の課題だ。本手法は、開発体験（DX）を劇的に向上させる。特に、AIアシスタント（Cursor等）とMCP経由で連携する設計は、次世代の標準となるだろう。ただし、動的言語における解析精度の限界には注意が必要だ。ASTの結果を過信せず、設計意図の確認は人間が行うべきである。技術的負債の議論を数値化するアプローチは、マネジメント層への説得力も高い。実戦投入の価値は極めて大きい。