Сценарий 18: Оптимизация кода

Разработчик или технический лидер улучшает качество кода с помощью анализа на основе ИИ с композитной оркестрацией сценариев безопасности, производительности, архитектуры, рефакторинга и технического долга.

Содержание¶

• Быстрый старт
• Как это работает
• Двухрежимная архитектура
• Детекция композитного режима
• Простой workflow
• OptimizationEngine
• Категории оптимизации
• Workflow утверждения и отмена
• Композитный оркестратор
• 5 подсценариев
• 4-шаговый конвейер
• Стратегии объединения
• Разрешение конфликтов
• Расчёт приоритетов
• Модель Finding
• Конфигурация
• Использование CLI
• Примеры вопросов
• Связанные сценарии

Быстрый старт¶

# Выберите сценарий оптимизации кода
/select 18

Как это работает¶

Двухрежимная архитектура¶

S18 работает в двух режимах, выбираемых маршрутизатором в route_by_intent():

Простой режим анализирует код на возможности оптимизации с помощью OptimizationEngine, генерирует предложения по категориям и представляет их для утверждения с поддержкой отмены.

Композитный режим оркестрирует 5 подсценариев (S02, S05, S06, S11, S12) параллельно, объединяет находки, разрешает конфликты и рассчитывает комбинированные приоритеты для унифицированных рекомендаций по оптимизации.

Запрос -> Классификация интента -> route_by_intent()
  |                                    |
  |  composite_mode?  Нет -> optimization_workflow() [Простой]
  |                   Да  -> optimization_composite_workflow() [Композитный]
  |
  Простой: OptimizationEngine -> Предложения -> ApprovalWorkflow
  Композитный: 5 подсценариев параллельно -> Объединение -> Разрешение -> Приоритеты -> Унифицированные находки

Если композитный оркестратор не включён в конфигурации, он автоматически переключается на простой workflow.

Детекция композитного режима¶

is_composite_optimization_query() в code_optimization_composite.py определяет, когда использовать композитный режим:

• Явные ключевые слова: “comprehensive”, “complete”, “full analysis”, “all issues”, “everything”, “комплексный”, “полный анализ”, “все проблемы”
• Несколько категорий (>=2): Когда 2+ из security, performance, architecture, refactoring, debt упомянуты в запросе

Простой workflow¶

optimization_workflow() в code_optimization.py предоставляет однорежимную оптимизацию кода:

1. Детекция интента: is_optimization_query() сопоставляет с 80 ключевыми словами EN+RU (optimize, performance, security, readability, оптимизировать, производительность, безопасность, читаемость и т.д.)
2. Извлечение параметров: _extract_optimization_params() извлекает пути файлов (через regex) и категории из запроса
3. Анализ: OptimizationEngine анализирует файлы/директории
4. Утверждение: Предложения передаются в ApprovalWorkflow для проверки
5. Ответ: Форматированный markdown со сводкой по категориям и списком предложений

OptimizationEngine¶

OptimizationEngine() из src.code_optimization анализирует код:

• engine.analyze_file(path, categories=...) — анализ одного файла
• engine.analyze_directory(path, categories=...) — анализ всех файлов в директории
• Возвращает список предложений с id, title, category, severity, file_path, start_line

Категории оптимизации¶

Перечисление OptimizationCategory определяет 3 категории анализа:

Категории извлекаются из запроса: “performance” / “производительность”, “security” / “безопасность”, “readability” / “читаемость”. Если не указаны, анализируются все категории.

Workflow утверждения и отмена¶

• ApprovalWorkflow(undo_stack=undo_stack, batch_mode=True) — управление очередью утверждения предложений
• UndoStack() — отслеживание применённых изменений для поддержки отмены
• Предложения хранятся в state["optimization_suggestions"] как сериализованные словари

Композитный оркестратор¶

optimization_composite_workflow() в code_optimization_composite.py оркестрирует комплексный анализ через 4-шаговый конвейер.

5 подсценариев¶

Оркестратор вызывает 5 подсценариев, определённых в OPTIMIZATION_SUB_SCENARIOS:

Подсценарии настраиваются через config.yaml → composition.orchestrators.scenario_18.sub_scenarios.

4-шаговый конвейер¶

Шаг 1: ScenarioInvoker.invoke_parallel()
        ThreadPoolExecutor(max_workers=4), таймаут 60с
        -> Dict[scenario_id -> SubScenarioResult]
            |
Шаг 2: ResultMerger.merge()
        Стратегия: WEIGHTED, порог дедупликации: 0.8
        -> MergeResult (unified_findings, duplicates_removed)
            |
Шаг 3: ConflictResolver.resolve_conflicts()
        Режим: PRIORITY, boost security 1.5x, compliance 1.3x
        -> (resolved_findings, List[ConflictResolution])
            |
Шаг 4: PriorityCalculator.calculate_batch()
        Алгоритм: WEIGHTED_SUM
        -> priority_scores Dict[finding_id -> float]

Шаг 1 — Вызов: ScenarioInvoker(config=orchestrator_config) запускает все 5 подсценариев через ThreadPoolExecutor с max_workers=4 и таймаутом 60 секунд. При parallel_execution: false переключается на последовательное выполнение. Каждый результат — SubScenarioResult с находками, временем выполнения и статусом ошибки.

Шаг 2 — Объединение: ResultMerger(config=merging_config) дедуплицирует находки из всех подсценариев. Использует порог дедупликации 0.8 для определения похожих находок. Отслеживает finding_sources — маппинг каждой находки к исходному сценарию(ям).

Шаг 3 — Разрешение: ConflictResolver(config=conflict_config) разрешает противоречивые рекомендации из разных сценариев. Использует разрешение на основе приоритетов с настраиваемыми коэффициентами: находки безопасности получают приоритет 1.5x, находки соответствия — 1.3x.

Шаг 4 — Приоритеты: PriorityCalculator(config=priority_config) рассчитывает комбинированный балл приоритета (0.0–1.0) для каждой находки, затем сортирует по приоритету и генерирует отчёт с разбивкой по срочности.

Стратегии объединения¶

Перечисление MergeStrategy определяет 4 стратегии:

Разрешение конфликтов¶

Перечисление ConflictResolutionMode определяет 4 режима:

Разрешение конфликтов отслеживает каждое решение в conflict_log с: conflict_id, resolution_method, winning_finding_id, suppressed_finding_ids, reason.

Расчёт приоритетов¶

PriorityAlgorithm.WEIGHTED_SUM (по умолчанию) рассчитывает приоритет по 5 взвешенным факторам:

Другие доступные алгоритмы: MULTIPLICATIVE, MAX.

Модель Finding¶

Dataclass Finding в src/workflow/composition/state.py — унифицированное представление находок из всех подсценариев:

Связанные типы: - SubScenarioResult — отслеживает scenario_id, success, findings, execution_time_ms, error - ConflictResolution — отслеживает conflict_id, resolution_method, winning_finding_id, suppressed_finding_ids, reason - CompositeWorkflowState — расширяет MultiScenarioState 20+ полями для композиции

Конфигурация¶

Композитный режим S18 настраивается в config.yaml → composition:

composition:
  orchestrators:
    scenario_18:
      sub_scenarios:
        - scenario_02  # Security
        - scenario_05  # Refactoring
        - scenario_06  # Performance
        - scenario_11  # Architecture
        - scenario_12  # Tech Debt
      parallel_execution: true
      timeout_seconds: 60
      max_findings_per_scenario: 50
      enabled: true

  merging:
    strategy: weighted
    deduplication_threshold: 0.8
    max_findings: 100

  priority:
    algorithm: weighted_sum
    weights:
      severity: 0.30
      impact: 0.25
      roi: 0.25
      confidence: 0.15
      consensus: 0.05

  conflicts:
    resolution_mode: priority
    security_priority_boost: 1.5
    compliance_priority_boost: 1.3

Использование CLI¶

# Простой анализ оптимизации
python -m src.cli query "Optimize src/core/ for performance"

# Анализ безопасности
python -m src.cli query "Find security improvements in src/api/"

# Анализ читаемости
python -m src.cli query "Analyze src/utils/ for readability issues"

# Комплексный композитный анализ (запускает композитный режим)
python -m src.cli query "Comprehensive code optimization for src/"

# Полный анализ с несколькими категориями (запускает композитный режим)
python -m src.cli query "Analyze security, performance, and architecture of src/"

# Композитный через API
# POST /api/v1/composition/query
# {"query": "Optimize src/", "orchestrator": "scenario_18"}

Примеры вопросов¶

• «Оптимизировать [путь] для производительности»
• «Найти улучшения безопасности в [путь]»
• «Проанализировать [путь] на проблемы читаемости»
• «Комплексная оптимизация кода для [путь]»
• «Полный анализ безопасности, производительности и архитектуры»
• «Найти все проблемы качества кода в [путь]»
• «Какие оптимизации наиболее влиятельны для [модуля]?»
• «Запустить полный анализ [путь] — безопасность, производительность, долг»
• «Показать предложения по оптимизации для [путь]»
• «Проанализировать [путь] на все проблемы»

Связанные сценарии¶

• Аудит безопасности — Сканирование уязвимостей безопасности (S02)
• Рефакторинг — Обнаружение запахов кода и мёртвого кода (S05)
• Производительность — Анализ производительности и горячих точек (S06)
• Архитектура — Анализ зависимостей и связности (S11)
• Технический долг — Измерение технического долга (S12)
• Редактирование файлов — Применение изменений кода (S17)
• Проверка стандартов — Проверка соответствия стандартам (S19)

S18 vs S19: S18 (Оптимизация кода) и S19 (Проверка стандартов) — оба являются композитными оркестраторами, разделяющими одну инфраструктуру композиции (ScenarioInvoker, ResultMerger, ConflictResolver, PriorityCalculator). S18 оркестрирует S02+S05+S06+S11+S12 параллельно (60с) для комплексной оптимизации кода. S19 оркестрирует S08+S17+S18 последовательно (45с) для проверки соответствия стандартам кодирования. S18 фокусируется на поиске и приоритизации улучшений кода; S19 фокусируется на проверке соблюдения стандартов.