dowse とは
解こうとしている問題
大規模な、特にモノレポのコードベースで、開発チームは常にこの問いに直面します。
限られた時間で、どこを直せば一番効くのか？
技術的負債は無限にあります。リファクタリング候補も無限にあります。でも時間は有限です。
従来の静的解析（ESLint, SonarQube 等）は「ある時点のスナップショット」を見て、すべての問題を等価に並べます。何千件もの警告を生むだけで、優先順位を付けられません。そして 複雑だが誰も触らないコードを直しても、投資対効果はほぼゼロです。
核心的な洞察
この分野を切り拓いた CodeScene の Adam Tornhill が示した洞察は単純です。
すべてのコードは等価ではない。「頻繁に触る × 複雑な」コード（= hotspot）だけが本当に問題で、そこに投資すれば ROI が最大化する。
そして「頻繁に触る」は git 履歴に書いてあります。
コード構造（静的解析）と変更履歴（version control mining）を掛け合わせる ―― これが behavioral code analysis（振る舞いに基づくコード分析） です。
dowse が加えるもの
dowse はこの洞察を TypeScript モノレポに特化して解き直します。
1. パッケージ境界を第一級に扱う
CodeScene は 39 言語対応の汎用ツールで、モノレポは「フォルダの集まり」として後付け対応されています。npm/pnpm workspace や Turborepo/Nx のパッケージ境界・依存グラフを理解しません。
dowse は workspace 設定を直接読み、パッケージグラフの上で振る舞い分析します。その結果として得られるのが次の機能です。
2. 隠れた結合を見つける
依存関係がないのに、繰り返し同時に変更されているパッケージ対 ―― 構造に現れない結合です。
Nx や Turborepo の affected は「ビルド対象」を出しますが、こうした結合は見ません。依存グラフを見ているだけでは絶対に気づけない箇所です。
実際のリポジトリでの検出例:
@acme/admin-web ↔ @acme/doctor-web 結合度 33%、91 回の共変更、依存関係なしdowse why で中身を見ると、server-api.ts や認証ページが両方にほぼ同一の形で存在し、「セッション失効時の再ログイン誘導を 3 面に追加」といったコミットで一緒に変更されていました。共有された抽象ではなく、コピーされたコードだったわけです。
3. 変更頻度が本物か検証する
git の行 diff は意味の変化を判定できません。識別子のリネーム、整形、コメント修正は行 diff 上は大きな変更に見え、変更頻度を膨らませます。CodeScene 自身も「型リネームで churn が誇張される」ことを弱点として認めています。
dowse は各リビジョンの AST を比較して、意味が変わっていない変更を見分けます。実測では、hotspot 上位 20 ファイルの 568 リビジョンのうち 55 件（9.7%）が偽の変更頻度で、最悪のファイルは 42% が水増しでした。
4. スコアの根拠をすべて公開する
CodeScene の Code Health は式・閾値・重みが非公開で、再現も検証もカスタマイズもできません。
dowse はすべて公開します。
health = 10 − Σ(weight × severity)そして「どの smell が何点引いたか」を関数名と行番号まで表示します。手で再計算できるということです。
さらに「LoC だけで決めた場合のスコア」も併記します。両者の差が小さいなら、その health は実質ファイル長の言い換えでしかない ―― それを利用者が検証できるようにするためです。
5. 直して、効果を実測する
提案するだけでは「本当に効いたのか」は分かりません。dowse は実際に修正させ、型チェックとテストで検証し、複雑度がどれだけ改善したかを数値で返します。
packages/cli/src/analyze.ts
cognitive -41 / cyclomatic -22 / LoC -111
型チェック ✓ テスト ✓ $1.86「ROI が最大」という主張を、予測ではなく実測で示します。
dowse が向かないもの
- 多言語のコードベース ―― TS/TSX に全振りしています。汎用性は CodeScene に譲ります。
- git 履歴のない、または浅いリポジトリ ―― 変更頻度が計算できないため、機能の半分が動きません。CI では
fetch-depth: 0が必須です。 - 個人の評価 ―― bus factor や ownership はチームのリスク把握のための指標です。開発者の成績表として使わないでください。Tornhill も同じ警告をしています。