Анализатор исходного кода: что реально работает, а что — трата времени

Примерно на третьем году работы в Яндексе я понял одну вещь. Кодревью — это боль. Ты тратишь часы на поиск забытых print(), забытых паролей в конфигах, кривых импортов. А потом всё равно пропускаешь баг, потому что глаз замылся.

Тогда я начал копаться в инструментах автоматизации. Анализатор исходного кода — это не серебряная пуля, но он забирает на себя рутину. Остаётся время на архитектуру и логику. Давайте разберёмся, что есть на рынке, как это работает и что реально приносит пользу.

Статический анализ: быстрая победа

Статический анализатор кода читает исходники, не запуская их. Парсит AST, строит графы потоков данных, ищет паттерны. Python, Java, Go — неважно. Принцип один.

Самое простое — линтеры. Возьмём анализатор кода Python под названием pylint. Он найдёт неиспользуемые переменные, нарушения PEP8, неправильное использование исключений.

pip install pylint
pylint src/

Конфиг для проекта:

# .pylintrc
[MESSAGES CONTROL]
disable=C0114,C0115,C0116  # missing-docstring

[FORMAT]
max-line-length=100

[BASIC]
variable-rgx=[a-z_][a-z0-9_]{2,30}$

Но линтеры — это уровень "entry". Они ловят синтаксис и стиль. Для серьёзного анализа нужны инструменты глубже. SonarQube, например, строит метрики сложности кода, находит дубликаты, считает техдолг.

На одном проекте мы внедрили SonarQube в CI. Через месяц выяснилось: 23% кода — дубликаты. Люди копипастили одни и те же валидаторы из модуля в модуль. Вынесли в общую библиотеку — закрыли тикеты на рефакторинг, которые висели полгода.

Статические анализаторы программного кода делятся на категории:

• Линтеры (ESLint, Pylint, Golint) — стиль и простые ошибки
• SAST-инструменты (SonarQube, Checkmarx, Semgrep) — безопасность и архитектура
• Специализированные (Bandit для Python, SpotBugs для Java) — узкие профили

Из интересного — Semgrep. Это статический анализатор кода Python (и не только), который использует паттерны в YAML. Можно писать свои правила за 10 минут.

rules:
  - id: dangerous-eval
    pattern: eval($X)
    message: "eval() is dangerous. Don't use it."
    severity: ERROR
    languages: [python]

Запускается одной командой:

semgrep --config rules/ src/

Честно? Большинство команд начинают с линтеров и останавливаются. Это уже хорошо. Но настоящий выигрыш — когда статический анализ встроен в пайплайн и блокирует мердж при критических ошибках.

Динамический анализ: тяжёлая артиллерия

Динамический анализ работает во время исполнения. Инструментирует код, запускает тесты, смотрит за поведением в рантайме. Находит то, что статика не видит: утечки памяти, race conditions, неправильное использование API.

Для Python есть замечательный инструмент — Coverage.py. Он показывает, какие строки кода реально выполнились во время тестов.

pip install coverage
coverage run -m pytest
coverage report -m

Вывод покажет, что 40% кода покрыто тестами. А 60% — нет. И это нормально для легаси. Но теперь вы знаете, где дыры.

Более продвинутый уровень — фаззинг. Для C/C++ есть AFL (American Fuzzy Lop), для Python — Atheris. Они генерируют случайные входные данные и ломают ваш код. Находят краш-баги, о которых вы не думали.

# atheris example
import atheris
import sys

def test_one_input(data):
    try:
        parse_user_input(data.decode())
    except Exception:
        pass

atheris.Setup(sys.argv, test_one_input)
atheris.Fuzz()

Но динамический анализ требует инфраструктуры. Нужно гонять тесты, нужен стейджинг, нужны данные. Внедрять сложнее. Обычно начинают со статики, потом добавляют динамику для критических модулей.

SAST: охота за уязвимостями

Если вы работаете с чувствительными данными, статический анализатор кода Python с фокусом на безопасность — необходимость. Bandit находит хардкоженные пароли, слабую криптографию, SQL-инъекции.

pip install bandit
bandit -r src/ -f json -o report.json

Пример того, что Bandit ловит:

# Плохо
password = "admin123"
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

# Bandit укажет на обе строки

По моему опыту, на каждом втором проекте есть хардкоженные креды. Разработчики коммитят .env, оставляют API-ключи в тестах. Потом эти ключи утекают. SAST-инструменты — это первая линия обороны.

Внедрение в CI/CD: с чего начать

Ну вот смотрите. У вас есть команда из 5 человек. Каждое ревью занимает час. В неделю — 20-30 часов команды на ревью. Это полтора человека-недели.

Статический анализ в CI сокращает это время. Автоматика ловит глупые ошибки, люди смотрят логику.

Для GitLab CI:

# .gitlab-ci.yml
stages:
  - lint
  - test
  - security

lint:
  stage: lint
  image: python:3.11
  script:
    - pip install pylint
    - pylint src/ --exit-zero
  allow_failure: true

security:
  stage: security
  image: python:3.11
  script:
    - pip install bandit
    - bandit -r src/ -f json -o bandit-report.json
  artifacts:
    paths:
      - bandit-report.json

Для GitHub Actions:

# .github/workflows/analysis.yml
name: Code Analysis
on: [pull_request]

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install semgrep
      - run: semgrep --config auto .

Ключевой момент: не блокируйте мердж на первых порах. Дайте команде привыкнуть. Через месяц включите жёсткий режим — критические ошибки блокируют. Ещё через месяц — предупреждения тоже.

Что выбрать: сравнение подходов

Короче, если вы только начинаете — берите линтер для вашего языка и Bandit/semgrep для безопасности. Это даёт 80% результата за 20% усилий.

Для зрелых команд — SonarQube или аналоги. Они дают метрики, историю, техдолг. Можно показать руководству красивые графики. Но внедрение — это недели, не дни.

AI-анализ: новый игрок

За последние два года появился новый класс инструментов — AI-анализаторы. Они не просто ищут паттерны, а понимают контекст. Находят логические ошибки, которые статика не видит.

Мы в Distiq как раз занимаемся этим. AI-бот анализирует каждый MR, оставляет инлайн-комментарии, находит баги и уязвимости. Работает с GitLab, GitHub, GitVerse. Поддерживает Python, JavaScript, TypeScript, Java, Go, PHP — основные языки.

Чем это отличается от классического статического анализа? AI понимает семантику. Он видит, что переменная user_id используется в SQL-запросе без экранирования, даже если это не паттерн. Видит, что логика ветвления приведёт к недостижимому коду.

Внедряется за минуту — добавляете webhook, и бот начинает работать. Никаких конфигов, правил, YAML-файлов. Серверы в РФ, данные не уходят за рубеж. Для команд, которые хотят автоматизировать рутину и освободить время сеньоров — хороший вариант.