影響分析

コード変更を行う前に、その波及効果を理解します。

影響分析とは？

影響分析は次の質問に答えます：「このファイルを変更したら、他に何が影響を受けるか？」

これにより：

• 変更をより慎重に計画できる
• 必要なテストを特定できる
• 予期しない破壊を回避できる
• 変更に必要な工数を見積もれる

影響分析の実行

Web インターフェース

1. プロジェクトを選択
2. 可視化でファイルをクリック
3. 影響を分析 をクリック

CLI

> /analyze src/services/user.ts

API

curl -X POST https://api.archicore.io/api/v1/projects/:id/analyze \
  -H "Authorization: Bearer あなたの_API_KEY" \
  -d '{"path": "src/services/user.ts"}'

結果の理解

src/services/user.ts の影響分析

╭─────────────────────────────────────────╮
│ 直接依存関係 (5)                        │
├─────────────────────────────────────────┤
│ → src/utils/crypto.ts                   │
│ → src/db/models/user.ts                 │
│ → src/config/auth.ts                    │
│ → src/types/user.ts                     │
│ → src/utils/validation.ts               │
╰─────────────────────────────────────────╯

╭─────────────────────────────────────────╮
│ 依存元 - 影響を受ける (8)               │
├─────────────────────────────────────────┤
│ ← src/controllers/auth.ts               │
│ ← src/controllers/profile.ts            │
│ ← src/controllers/admin.ts              │
│ ← src/middleware/auth.ts                │
│ ← src/services/session.ts               │
│ ← src/api/routes/users.ts               │
│ ← tests/user.test.ts                    │
│ ← tests/auth.test.ts                    │
╰─────────────────────────────────────────╯

リスクレベル：中
影響を受けるテスト：2

影響レベル

レベル	説明	アクション
低	依存元が少ない、isolated な変更	標準レビューで進める
中	複数の依存元、中程度のリスク	徹底的なテストを推奨
高	多くの依存元、コアモジュール	広範なテスト、段階的ロールアウトを検討
重大	クリティカルパスに影響	追加レビュー、フィーチャーフラグを推奨

変更のシミュレーション

提案された変更の影響をプレビュー：

> /simulate
変更を説明してください：UserService.getUser() に新しいパラメータを追加

シミュレーション結果：

更新が必要なファイル：
  1. src/controllers/auth.ts:34 - getUser() を呼び出し
  2. src/controllers/profile.ts:12 - getUser() を呼び出し
  3. src/services/session.ts:45 - getUser() を呼び出し

更新が必要なテスト：
  1. tests/user.test.ts - 5 つのテストケースが getUser() を呼び出し
  2. tests/auth.test.ts - 3 つのテストケースが getUser() を呼び出し

見積もり工数：中（8 ファイル、15 呼び出し箇所）

ベストプラクティス

変更を行う前に

1. 影響分析を実行 修正予定のファイルに対して
2. 依存関係チェーンをレビュー - 影響範囲を理解
3. 影響を受けるテストを特定 - 更新されることを確認
4. 循環依存をチェック - 影響を増幅させる

影響を減らす

1. インターフェースを使用 - 抽象に依存
2. SOLID 原則を適用 - 単一責任が影響を限定
3. モジュールを疎結合に - 直接依存を減らす
4. ファサードレイヤーを書く - 実装詳細を隠蔽

例：安全なリファクタリング

// 前：直接依存
// User の変更がすべてのコンシューマーに影響
class UserController {
  constructor(private userService: UserService) {}
}

// 後：インターフェース依存
// UserService の実装変更はコンシューマーに影響しない
interface IUserService {
  getUser(id: string): Promise<User>;
}

class UserController {
  constructor(private userService: IUserService) {}
}

CI/CD 統合

パイプラインに影響分析を追加：

# .gitlab-ci.yml
impact-analysis:
  script:
    - archicore analyze --changed-files
    - if [ $IMPACT_LEVEL == "critical" ]; then
        echo "重大な影響を検出 - 追加レビューが必要";
        exit 1;
      fi