15 апреля 2026 г.

Как делать code review аналитику

Зачем code review

  • Ловить ошибки. Один глаз видит 70% багов, два — 95%.
  • Обмен знаниями. Читающий учится у writer.
  • Consistency. Команда пишет в одном стиле.
  • Documentation. PR-обсуждения — контекст для будущего.

Что именно ревьюить

SQL

  • Дашборды.
  • ETL джобы.
  • dbt models.
  • Ad-hoc analyses (если они будут в shared repo).

Python

  • Jupyter notebooks (да, если в Git).
  • Python-скрипты.
  • Airflow DAG.

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

  • BI-tools (Looker, Tableau — если versioned).
  • dbt config.
  • Airflow config.

Чеклист SQL-ревью

Функциональность

  • Запрос решает правильную задачу?
  • Корректно обрабатывает edge cases (NULL, 0, empty)?
  • Учитывает timezone где важно?

Качество

  • Читабельный (formatted, commented where needed)?
  • Использует CTE вместо вложенных подзапросов?
  • Без SELECT *?
  • Alias-ы осмысленные?

Performance

  • Не seq scan больших таблиц?
  • Фильтр до JOIN / агрегации?
  • Индексы используются?

Безопасность

  • Нет hardcoded credentials?
  • Не падает при edge inputs?

Тесты

  • Для dbt — есть tests (unique, not_null, relationships)?

Чеклист Python-ревью

Функциональность

  • Делает то, что нужно?
  • Обработка ошибок (try/except)?

Качество

  • PEP8-compliant?
  • Понятные имена переменных и функций?
  • Комментарии / docstrings?
  • Нет дублирующегося кода (DRY)?

Производительность

  • Векторизация вместо apply (где возможно)?
  • Не грузим лишнего в память?

Безопасность

  • Credentials в env vars, не hardcoded?
  • SQL queries параметризованы?

Этикет ревью

Для reviewer-а

1. Быть constructive

❌ «Это плохо».

✅ «Можно улучшить так: [пример]. Это даст [benefit]».

2. Разделить «must» и «nice»

  • blocker: — надо fix.
  • suggestion: — nice to have.
  • nit: — мелочь (наименование).
  • question: — прояснить.

Префиксы помогают priority.

3. Praise good parts

«Отличный use CTE — намного чище, чем подзапросы».

4. Не переписывать

Не «вот я написал за тебя» — а «думал ли про такой вариант?».

5. Быстрый turnaround

Review в течение 1 дня. Больше — и author забудет context.

Для author-а

1. Small PRs

1 PR = 1 логическое изменение. Не 10 features одним PR.

2. Самоcheck перед submit

Пройдите по чеклисту. Вы увидите 50% проблем сами.

3. Description матерен

Что, зачем, как тестировали. Не «fix bug» — «Исправил deadlock в cohort calculation».

4. Ответь на каждый комментарий

Даже если просто «fixed». Игнорируя — confusing.

5. Не take criticism personally

Review кода != review вас. Separate это.

Пример good PR description


Попробовать силы на подобных вопросах проще всего в [тренажёре Карьерник](https://t.me/kariernik_bot/app?startapp=web_blog_kak-delat-code-review-analitiku_mid1) — прямо в Telegram, без регистрации через сайт.

## Что

Добавил retention_d30 в mart_user_metrics_daily.

## Зачем

PM попросил добавить D30 в dashboard «User Health».

## Как

- Изменил `mart_user_metrics_daily.sql` — добавил calculation.
- Обновил schema.yml — описание колонки.
- Tested на last 90 days — corresponds с manual calculations.

## Testing

- [x] dbt test
- [x] dbt run
- [x] Manual check — совпадает с Python notebook

## Questions для reviewer

Есть ли более efficient способ через LAG? Сейчас через correlated subquery.

Чётко и понятно.

Антипатерны

1. Мега-PR

Pull request на 50 файлов. Reviewer сдаётся.

Решение: маленькие, focused PRs.

2. «LGTM» без reading

Reviewer apruve без ревью. Пропускает баги.

Решение: require реальный review от серьёзного person.

3. Nitpicking

Стоик-комментарии на формат, а не логику.

Решение: linter автоматизирует форматирование.

4. Эго

«Я senior, не принимаю feedback от junior».

Решение: все код-ревью — equal. Junior может заметить ошибку.

5. Token review

Reviewer без context одобряет. Плохой signal.

Решение: reviewer должен понимать code, или сказать «не разбираюсь, просите другого».

Tools

GitHub / GitLab

Pull Requests / Merge Requests. Стандарт.

Inline комментарии

Сразу в коде. Не в Slack.

Linter / formatter

  • SQLFluff для SQL.
  • black / ruff для Python.

Часть CI, автоматически проверяет форматирование.

Automated tests

dbt tests, pytest. Часть PR pipeline.

Пройти 30–50 задач по теме за вечер можно в Telegram-тренажёре. Это то, что отличает «знаю» от «уверенно отвечу на собесе».

Для новичков

Когда только пришёл

  • Reviewing чужой код = быстрое обучение.
  • Не бойтесь задавать вопросы в комментариях.

Когда ваш PR ревьюится

  • Первые PRs будут с множеством комментариев.
  • Это норма, не позор.
  • После 5-10 PRs количество комментариев уменьшится.

Парный подход

Новичок + senior pairs вместе пишут первые PRs. Обучение через совместную работу.

На собеседовании

Вопросы:

  • «Как вы делаете code review?»
  • «Какие инструменты?»
  • «Что делать, если не согласен с reviewer-ом?»

Good answer: конкретика + этикет + продуктивность.

Процесс в команде

1. Branch workflow

git checkout -b feature/my-feature
# changes
git push origin feature/my-feature
# open PR

2. Minimum 1 approver

Для важных таблиц / моделей — 2 approvers.

3. CI checks

  • Linter passes.
  • dbt test passes.
  • Unit tests pass.

4. Merge

После approve + CI green.

5. Deploy

Auto или manual — зависит от pipeline.

Для dbt-моделей

Особые checks:

  • Modeled correctly (staging, marts)?
  • Tests добавлены (unique, not_null)?
  • Documentation обновлена?
  • Не сломает downstream models?

dbt compile + dbt run в CI обязательны.

Читайте также

FAQ

Сколько PR-ов ревьюить в день?

1–3. Больше — качество падает.

Ругаться с reviewer — ок?

Нет. Дебатировать — да, ругаться — нет.

Junior может ревьюить senior?

Абсолютно. Учится сам, может заметить ошибку.

Как часто переписывать код после PR?

Иногда нужно 3-4 итерации. Это норма, не failure.

Тренироваться в Telegram