Как быстро найти технический долг и архитектурные проблемы в TypeScript/JS проекте: автоматизированный аудит кода с fallow

Я — Денис Шохирев, архитектор агентных AI-систем из Фрайбурга, работаю на стеке Claude, Supabase, n8n, Doppler, self-hosted Postgres. В продакшне B2B-клиентов DACH простая задача: быстро и объективно вытащить технический долг в TypeScript/JS проекте, который уже приносит деньги — без “ревью ради ревью” и долгих демо. На одной из внедрённых мной multi-agent систем fallow за 30 минут вскрыл реальные архитектурные дыры, которые не видели месяцами.

Проблема ручного аудита: субъективность, медленность, поверхностность

Типовой аудит кода в TypeScript/JS проектах — это 1-2 дня ручного “code review”, когда senior смотрит глазами, выискивает “запахи” и пишет длинный список замечаний. На практике:

• Половина замечаний — вкусовщина (“можно и так, и так”),
• Критические уязвимости (SQL-инъекции, плохая работа с секретами) часто ускользают,
• Картину по архитектуре (циклические зависимости, неявные side effects, анти-паттерны) собрать сложно без специальных инструментов.

На трёх недавних внедрениях агентных систем я лично ловил одинаковые паттерны SQL-инъекций в auto-generated DB-слое — и все они прошли ручной аудит “на глазок”.

fallow — что это и почему работает для JS/TS

fallow — open-source инструмент статического анализа для TypeScript и JavaScript, который строит граф зависимостей, находит “мертвый” (неиспользуемый) код, циклические зависимости, сложные точки входа, и даже архитектурные анти-паттерны. Реальный проект: https://github.com/fallow-land/fallow

fallow работает локально, не требует отправки кода в облако, что критично для compliance в DACH/ЕС-рынках.

Типовые “болячки” JS/TS монолита, которые fallow находит за 5 минут

• Циклические зависимости между файлами/модулями: мешают рефакторингу, ломают tree-shaking, усложняют тестирование.
• Мертвый код: оставшиеся после миграций модули, которые никто не вызывает.
• Скрытые точки входа: забытые endpoints, неявные side effects.
• “Feature envy”: модули, которые слишком плотно связаны, нарушая SRP (Single Responsibility Principle).
• Сложные графы зависимостей: сложно понять, что реально влияет на бизнес-логику.

По опыту: в продакшн-проектах с историей 2+ лет всегда есть хотя бы 3-5 критичных циклов и десятки мертвых файлов.

Как внедрить fallow в реальный TypeScript/JS проект

1. Быстрый старт — audit в локальном окружении

npm install -g @fallow-land/cli
fallow -p ./src --format json --report report.json
cat report.json | jq '.'

Результат — подробный JSON-отчёт c графом зависимостей, списком циклов, dead code, orphan-модулей. В команде — расшариваю отчёт в Notion или через n8n автоматом в Slack.

2. Визуализация для архитектурного ревью

fallow -p ./src --format html --report report.html
open report.html

Визуализация циклов и dead code — это не просто “красиво”. На одном из проектов клиент увидел, что их payments-модуль зависит от legacy-auth, хотя по бизнесу это давно не так.

3. Интеграция с CI/CD и автоматическая рассылка

# .github/workflows/fallow-audit.yml
name: fallow audit
on:
  push:
    branches: [ main ]
jobs:
  fallow-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm install -g @fallow-land/cli
      - run: fallow -p ./src --format json --report report.json
      - uses: actions/upload-artifact@v4
        with:
          name: fallow-report
          path: report.json

После пуша в main — автоматический отчёт об архитектурных проблемах в pull request или в Slack через n8n.

Сценарии продакшн-использования fallow

• Регулярный аудит legacy-кода перед major-release;
• Оценка чужого кода при покупке стартапа или аутсорса;
• Автоматическая проверка pull request на появление новых циклов;
• Интеграция с Claude или GPT для генерации summary отчётов для CTO/PM.

Совмещая fallow с semgrep (ищет баги и уязвимости, semgrep.dev), покрываю обе плоскости: архитектуру и безопасность. В B2B/финтехе это must-have: регуляторы (например, BaFin в Германии) требуют доказуемую прозрачность изменений — fallow + скрипт отчёта — готовая база.

FAQ

Можно ли использовать fallow для monorepo с несколькими package?

Да, fallow поддерживает анализ monorepo, но важно запускать его на корне проекта и указывать все входные точки.

Чем fallow лучше depcruise или ESLint?

depcruise хорош для графа зависимостей, ESLint — для стиля и багов, но только fallow прямо ищет dead code и циклы на уровне архитектуры.

Как обрабатывать большие отчёты на 500+ файлов?

Генерирую summary в Claude или GPT: “Приведи топ-5 критичных циклов и dead code”. Не пытаюсь делать “идеально”, достаточно убрать самые опасные места.

Есть ли риск утечки кода при использовании fallow?

Нет, fallow работает локально, никакой передачи данных на внешние сервера. Это критично для compliance в ЕС/Германии.

Можно ли интегрировать fallow в n8n для автоматизации?

Да, через shell-команды и парсинг JSON-отчёта. У меня реализована пересылка summary в Telegram и Slack через n8n по расписанию.

А вы когда в последний раз смотрели на свой JS/TS проект глазами архитектурного графа, а не “по ощущениям”? Где в вашей цепочке контроля чаще всего всплывают критичные косяки — на этапе ревью или только при инцидентах в проде? Я делаю бесплатный аудит стека для DACH-стартапов с продакшн AI. Пишите в LinkedIn или @ger_dennis_ai.