.svg)
.svg)
Первый код-ревью — это стресс. 47 комментариев к твоему PR, половина — про именование переменных, четверть — про архитектуру, которую ты не понимаешь. Хочется закрыть ноутбук и уйти в курьеры. Но код-ревью — это не экзамен и не наказание. Это самый быстрый способ вырасти от джуна до мидла. Эта статья — практическое руководство: как не принимать критику на личный счёт, что делать с каждым типом комментариев и как превратить ревью в ускоритель карьеры.
1. Зачем джуну код-ревью
Реальность рынка
| Показатель | Значение (2025) |
|---|---|
| Медианная зарплата IT в России | 182 700 ₽ |
| Зарплата Junior (без опыта) | 50 000–80 000 ₽ |
| Зарплата Middle (1–3 года) | 120 000–180 000 ₽ |
| Зарплата Senior (3–6 лет) | 200 000–350 000 ₽ |
| Рост зарплат в IT за год | +17–19% |
| Время перехода Junior → Middle | 1–2 года |
Что ускоряет рост джуна
| Фактор | Влияние на рост | Почему |
|---|---|---|
Код-ревью от сеньоров | Очень высокое | Прямая передача опыта, исправление ошибок |
Работа над реальными задачами | Высокое | Контекст, бизнес-логика, ограничения |
Парное программирование | Высокое | Наблюдение за мышлением сеньора |
Чтение чужого кода | Среднее | Изучение паттернов и подходов |
Онлайн-курсы | Среднее | Теория без практики |
Книги | Низкое-Среднее | Долго, мало обратной связи |
Что даёт код-ревью джуну
| Польза | Описание |
|---|---|
Обратная связь | Узнаёшь, что делаешь не так, пока ошибка не ушла в прод |
Изучение стандартов | Понимаешь, как принято писать код в команде |
Архитектурное мышление | Видишь, как сеньоры думают о структуре |
Знание кодовой базы | Через комментарии узнаёшь о других частях системы |
Навык коммуникации | Учишься объяснять свои решения |
Уверенность | Со временем комментариев становится меньше |
2. Психология код-ревью: почему больно
Три стадии реакции на критику
Большинство разработчиков, особенно в начале карьеры, проходят через три эмоциональные стадии:
| Стадия | Что чувствуешь | Что думаешь |
|---|---|---|
1. Защита | Раздражение, обида | «Но ведь работает! Зачем придираться к мелочам?» |
2. Сомнение | Неуверенность, страх | «Может, я вообще не подхожу для этой работы?» |
3. Рост | Спокойствие, интерес | «Это поможет мне писать лучше. Запомню на будущее» |
Цель — быстрее добраться до третьей стадии.
Почему критика воспринимается лично
| Причина | Механизм | Как преодолеть |
|---|---|---|
Код = часть тебя | Ты вложил время и силы | Отделять себя от кода: «Это не я, это мой код» |
Синдром самозванца | Страх, что «раскроют» | Все были джунами. Ошибки — норма |
Публичность | Комментарии видит вся команда | Это стандартный процесс, не позор |
Непонятные термины | Чувствуешь себя глупо | Спрашивать — нормально и правильно |
Много комментариев | Кажется, что всё плохо | Количество ≠ качество. 50 мелких замечаний лучше 1 критичного |
Ключевой сдвиг мышления
| Старое мышление | Новое мышление |
|---|---|
| «Меня критикуют» | «Мой код критикуют» |
| «Я плохой разработчик» | «Я учусь быть лучше» |
| «Они придираются» | «Они делятся опытом» |
| «Это атака на меня» | «Это защита кодовой базы» |
| «Надо защищаться» | «Надо понять и улучшить» |
Что помогает
Пауза перед реакцией — прочитай, закрой, вернись через 10 минут
Фокус на действии — что конкретно нужно исправить?
Благодарность — сеньор потратил время на твоё обучение
Статистика — считай, сколько замечаний повторяется (должно уменьшаться)
Перспектива — через год ты будешь ревьюить других
3. Типы комментариев на код-ревью
Классификация комментариев
| Тип | Описание | Приоритет | Пример |
|---|---|---|---|
Блокирующий | Код не может быть смержен | Критичный | «Это сломает прод», «SQL-инъекция» |
Важный | Нужно исправить | Высокий | «Нарушен принцип SRP», «Нет обработки ошибок» |
Рекомендация | Лучше исправить | Средний | «Можно вынести в отдельную функцию» |
Nitpick (NIT) | Мелочь, можно игнорировать | Низкий | «Лишний пробел», «Можно короче» |
Вопрос | Ревьюер не понимает | Средний | «Почему здесь именно так?» |
Похвала | Что-то сделано хорошо | — | «Отличное решение!», «Хороший рефакторинг» |
Как распознать тип комментария
| Маркеры в тексте | Тип | Что делать |
|---|---|---|
| «Нужно», «Обязательно», «Это баг» | Блокирующий | Исправить немедленно |
| «Стоит», «Лучше бы», «Рекомендую» | Важный/Рекомендация | Исправить или обсудить |
| «NIT:», «Мелочь», «Можно» | Nitpick | На твоё усмотрение |
| «Почему?», «Зачем?», «Не понимаю» | Вопрос | Объяснить или добавить комментарий в код |
| «Круто!», «Хорошо», «Нравится» | Похвала | Запомнить, что работает |
Примеры реальных комментариев
Блокирующие
| Комментарий | Проблема | Что делать |
|---|---|---|
| «SQL-инъекция в этом запросе» | Безопасность | Использовать параметризованные запросы |
| «Это удалит все данные пользователя» | Потеря данных | Добавить проверку, бэкап |
| «Race condition при параллельных запросах» | Конкурентность | Добавить блокировку/транзакцию |
| «Бесконечный цикл при пустом массиве» | Логика | Добавить проверку на пустоту |
Важные
| Комментарий | Проблема | Что делать |
|---|---|---|
| «Функция делает слишком много (SRP)» | Архитектура | Разбить на несколько функций |
| «Нет обработки ошибок» | Устойчивость | Добавить try-catch, валидацию |
| «Дублирование кода (DRY)» | Maintainability | Вынести в общую функцию |
| «Нет тестов на этот кейс» | Покрытие | Написать тест |
Nitpick
| Комментарий | Суть | Приоритет |
|---|---|---|
| «NIT: лишний пробел» | Форматирование | Низкий (линтер поймает) |
| «Можно написать короче: x ?? 0» | Стиль | Низкий (если работает) |
| «Предпочитаю const вместо let» | Стиль | Низкий |
| «Порядок импортов» | Форматирование | Низкий |
4. Самые частые замечания и как их избежать
ТОП-10 замечаний на код-ревью джунов
| Место | Замечание | Частота |
|---|---|---|
| 1 | Плохие названия переменных/функций | 85% |
| 2 | Нет обработки ошибок | 78% |
| 3 | Дублирование кода (DRY) | 72% |
| 4 | Слишком длинные функции | 68% |
| 5 | Нет тестов или плохие тесты | 65% |
| 6 | Хардкод значений | 60% |
| 7 | Неоптимальные запросы к БД | 55% |
| 8 | Отсутствие комментариев к сложной логике | 50% |
| 9 | Нарушение code style команды | 48% |
| 10 | Избыточная сложность | 45% |
Замечание 1: Именование
| Плохо | Хорошо | Почему |
|---|---|---|
|
| Понятно без контекста |
|
| Ясно, что делает функция |
|
| Отражает бизнес-логику |
|
| Булевы начинаются с is/has/can |
|
| Множественное число для коллекций |
Правила именования
| Тип | Правило | Пример |
|---|---|---|
| Переменные | camelCase, существительные |
|
| Функции | camelCase, глагол + существительное |
|
| Классы | PascalCase, существительные |
|
| Константы | UPPER_SNAKE_CASE |
|
| Булевы | is/has/can/should + прилагательное |
|
Замечание 2: Нет обработки ошибок
| Плохо | Хорошо |
|---|---|
| Игнорировать исключения | Логировать и обрабатывать |
| Пустой catch-блок | Хотя бы логировать ошибку |
| Возвращать null | Бросать исключение или Optional |
| Общий Exception | Конкретные типы исключений |
| Показывать стектрейс юзеру | Понятное сообщение об ошибке |
Замечание 3: Дублирование кода (DRY)
DRY = Don't Repeat Yourself. Если код повторяется 3+ раз — выноси в функцию.
| Признак проблемы | Решение |
|---|---|
| Copy-paste блоков кода | Вынести в функцию |
| Похожая логика в разных местах | Создать общий хелпер |
| Одинаковые SQL-запросы | Вынести в репозиторий |
| Повторяющаяся валидация | Создать валидатор |
Замечание 4: Слишком длинные функции
| Признак | Норма | Что делать |
|---|---|---|
| Больше 20–30 строк | 5–15 строк | Разбить на подфункции |
| Несколько уровней вложенности | 1–2 уровня | Early return, extract method |
| Много параметров (5+) | 1–3 параметра | Объект-параметр или разбить |
| Делает несколько вещей | Одна задача | Single Responsibility Principle |
Замечание 5: Хардкод
| Плохо | Хорошо |
|---|---|
|
|
|
|
|
|
|
|
5. Принципы, которые упоминают на ревью
SOLID
| Принцип | Расшифровка | Что значит | Типичный комментарий |
|---|---|---|---|
S | Single Responsibility | Класс/функция делает одно дело | «Эта функция делает слишком много» |
O | Open/Closed | Открыт для расширения, закрыт для изменения | «Лучше добавить новый класс, чем менять существующий» |
L | Liskov Substitution | Наследники заменяют родителей | «Нарушена контрактность интерфейса» |
I | Interface Segregation | Много маленьких интерфейсов лучше одного большого | «Слишком много методов в интерфейсе» |
D | Dependency Inversion | Зависеть от абстракций, не от реализаций | «Лучше инжектить зависимость» |
Другие принципы
| Принцип | Что значит | Типичный комментарий |
|---|---|---|
DRY | Don't Repeat Yourself — не дублируй код | «Это уже есть в utils, переиспользуй» |
KISS | Keep It Simple, Stupid — делай проще | «Слишком сложно, можно проще» |
YAGNI | You Aren't Gonna Need It — не делай лишнего | «Зачем это? Нет такой задачи» |
Fail Fast | Падай быстро при ошибке | «Лучше упасть сразу, чем тихо сломаться» |
Composition over Inheritance | Композиция лучше наследования | «Не надо наследовать, лучше композиция» |
Как запомнить принципы
| Принцип | Мнемоника |
|---|---|
| SRP | «Функция = одна задача» |
| DRY | «Копипаст = плохо» |
| KISS | «Если сложно объяснить — упрости» |
| YAGNI | «Нет задачи — нет кода» |
6. Как отвечать на комментарии
Правила ответа
| Правило | Почему важно |
|---|---|
Отвечай на все комментарии | Показывает, что ты прочитал и понял |
Благодари за полезные замечания | Создаёт позитивную атмосферу |
Объясняй свои решения | Помогает ревьюеру понять контекст |
Признавай ошибки | Показывает зрелость |
Задавай вопросы | Углубляет понимание |
Не спорь ради спора | Экономит время всех |
Шаблоны ответов
| Ситуация | Плохой ответ | Хороший ответ |
|---|---|---|
| Согласен с замечанием | «Ок» | «Исправил. Спасибо, не знал про этот паттерн» |
| Не согласен | «Нет, так лучше» | «Я сделал так потому что X. Но если Y важнее, переделаю» |
| Не понимаю комментарий | (Игнорировать) | «Можешь пояснить? Не уверен, что понял правильно» |
| Замечание спорное | «Это субъективно» | «Интересная мысль. Есть ли гайд команды по этому?» |
| Нашёл баг | «Упс» | «Хороший catch! Исправил и добавил тест на этот кейс» |
Когда не соглашаться
Иногда ревьюер не прав. Как вежливо не согласиться:
| Ситуация | Как ответить |
|---|---|
| У тебя есть контекст, которого нет у ревьюера | «Тут есть нюанс: [контекст]. Поэтому сделал так» |
| Замечание противоречит другому ревьюеру | «[Имя] предложил X, а ты — Y. Как лучше поступить?» |
| Предложение ухудшит производительность | «Такой вариант будет O(n²) вместо O(n). Важно ли это здесь?» |
| Это вкусовщина | «Оба варианта работают. Есть ли командное соглашение?» |
Чего не делать
| Ошибка | Почему плохо |
|---|---|
| Игнорировать комментарии | Ревьюер не поймёт, исправил ли ты |
| Отвечать «ок» на всё | Не показывает понимания |
| Защищаться агрессивно | Создаёт конфликт |
| Удалять комментарии без ответа | Теряется история обсуждения |
| Писать «это работает» | Работающий код ≠ хороший код |
7. Как задавать вопросы
Почему вопросы важны
«Задавать вопросы на код-ревью — лучший совет, который я получил как джун. Когда я начал спрашивать о том, чего не понимаю, я узнал намного больше о системе» — разработчик Pinterest
Какие вопросы задавать
| Тип вопроса | Пример | Что узнаешь |
|---|---|---|
Почему так лучше? | «Почему Optional лучше null здесь?» | Принципы и best practices |
Где почитать? | «Есть статья/доку про этот паттерн?» | Ресурсы для обучения |
Как в нашей кодовой базе? | «Где пример такого подхода в проекте?» | Стандарты команды |
Что будет если? | «Что сломается, если оставить как есть?» | Последствия решений |
Это важно сейчас? | «Это блокер или можно в следующем PR?» | Приоритеты |
Как формулировать вопросы
| Плохо | Хорошо |
|---|---|
| «Не понял» | «Правильно ли я понимаю, что нужно сделать X?» |
| «Зачем?» | «Какую проблему это решает?» |
| «Это обязательно?» | «Это блокер или рекомендация?» |
| «Где это написано?» | «Есть ли документация или пример в кодовой базе?» |
Чему можно научиться через вопросы
| Область | Примеры вопросов |
|---|---|
Архитектура | «Почему сервисы разделены так?», «Как это масштабируется?» |
Производительность | «Почему этот запрос медленный?», «Как профилировать?» |
Безопасность | «Какие есть уязвимости?», «Как защититься от X?» |
Процессы | «Как это деплоится?», «Кто ревьюит критичные изменения?» |
Бизнес | «Почему такое требование?», «Кто пользователь?» |
8. Как готовить PR к ревью
Чек-лист перед отправкой
| Шаг | Что проверить | Инструмент |
|---|---|---|
1. Self-review | Прочитай свой код как ревьюер | GitHub diff |
2. Тесты | Все тесты проходят | CI/CD |
3. Линтер | Нет ошибок линтера | ESLint, Pylint и т.д. |
4. Форматирование | Код отформатирован | Prettier, Black |
5. Комментарии | Удалены TODO, console.log, закомментированный код | Глаза |
6. Размер | PR < 400 строк | GitHub |
7. Описание | Понятное описание изменений | PR template |
Структура хорошего PR
| Раздел | Что писать | Пример |
|---|---|---|
Заголовок | Что сделано (императив) | «Добавить валидацию email в форму регистрации» |
Описание | Зачем и как | «Пользователи вводили невалидные email. Добавил regex-проверку» |
Скриншоты | До/после (для UI) | Скриншот формы |
Как тестировать | Шаги для проверки | «1. Открыть /register 2. Ввести невалидный email» |
Связанные задачи | Ссылка на тикет | «Closes #123» |
Размер PR имеет значение
| Размер PR | Строк кода | Время ревью | Качество ревью |
|---|---|---|---|
| Маленький | < 100 | 15–30 мин | Высокое |
| Средний | 100–400 | 30–60 мин | Хорошее |
| Большой | 400–1000 | 1–2 часа | Среднее |
| Огромный | 1000+ | Несколько часов | Низкое (пропустят баги) |
Оптимально: до 400 строк. Большие изменения лучше разбить на несколько PR.
Что делать, если PR большой
| Стратегия | Когда использовать |
|---|---|
Stacked PRs | Последовательные изменения (PR2 зависит от PR1) |
Feature flags | Можно мержить незаконченное |
Разделение по слоям | Отдельно: модели, сервисы, API, UI |
Рефакторинг отдельно | Сначала рефакторинг, потом фича |
9. Как учиться на комментариях
Система обучения
| Шаг | Что делать | Инструмент |
|---|---|---|
1. Записывай | Фиксируй все новые замечания | Notion, заметки |
2. Группируй | Объединяй похожие замечания | Таблица/теги |
3. Изучай | Читай статьи по теме | Habr, Medium, книги |
4. Применяй | Проверяй себя перед PR | Чек-лист |
5. Отслеживай | Считай повторы | Статистика |
Таблица для записи замечаний
| Дата | Замечание | Категория | Что изучить | Повтор? |
|---|---|---|---|---|
| 01.03 | «Нет обработки ошибок» | Error handling | Try-catch, Optional | — |
| 05.03 | «Функция слишком длинная» | SRP | Clean Code, глава 3 | — |
| 12.03 | «Нет обработки ошибок» | Error handling | — | Да (2-й раз) |
| 15.03 | «N+1 запрос к БД» | Performance | Eager loading, JOINs | — |
Метрики прогресса
| Метрика | Как считать | Хороший результат |
|---|---|---|
| Комментариев на PR | Среднее за месяц | Уменьшается со временем |
| Повторяющихся замечаний | % повторов от всех | < 20% |
| Время до approval | От создания до approve | Уменьшается |
| Блокирующих комментариев | Количество в месяц | → 0 |
Ресурсы для изучения
| Тема | Ресурс |
|---|---|
| Чистый код | «Clean Code» Роберт Мартин |
| SOLID | «Принципы, паттерны и методики гибкой разработки» Р. Мартин |
| Рефакторинг | «Рефакторинг» Мартин Фаулер |
| Паттерны | «Head First Design Patterns» |
| Тестирование | «Unit Testing» Владимир Хориков |
10. Как самому ревьюить код
Зачем джуну ревьюить
| Польза | Описание |
|---|---|
Изучение кодовой базы | Видишь, как другие решают задачи |
Новые паттерны | Учишься у сеньоров |
Критическое мышление | Развиваешь навык анализа |
Понимание требований | Узнаёшь, что важно для команды |
Видимость | Становишься заметнее в команде |
Что джун может комментировать
| Можно | С осторожностью | Лучше не надо |
|---|---|---|
| Опечатки | Архитектурные решения | «Я бы сделал иначе» без аргументов |
| Непонятные места (вопросы) | Производительность | Критика стиля сеньора |
| Битые ссылки, импорты | Альтернативные подходы | Безапелляционные утверждения |
| Отсутствие тестов | — | — |
| Нарушения гайда команды | — | — |
Как комментировать вежливо
| Плохо | Хорошо |
|---|---|
| «Это неправильно» | «Правильно ли я понимаю, что здесь X?» |
| «Нужно переделать» | «Мне кажется, можно рассмотреть вариант Y. Что думаешь?» |
| «Почему так?» | «Интересный подход. Можешь объяснить выбор?» |
| «Не понимаю» | «Хочу разобраться: как это работает в случае Z?» |
11. Инструменты
Автоматизация проверок
| Категория | Инструменты | Что проверяет |
|---|---|---|
Линтеры | ESLint, Pylint, RuboCop | Стиль, потенциальные баги |
Форматтеры | Prettier, Black, gofmt | Форматирование |
Type checkers | TypeScript, mypy, Flow | Типы |
Security | Snyk, SonarQube, Bandit | Уязвимости |
Test coverage | Jest, Coverage.py, JaCoCo | Покрытие тестами |
Платформы код-ревью
| Платформа | Плюсы | Минусы |
|---|---|---|
GitHub | Популярность, интеграции | Базовый функционал ревью |
GitLab | Встроенный CI/CD, self-hosted | Сложнее интерфейс |
Bitbucket | Интеграция с Jira | Меньше community |
Gerrit | Гранулярный контроль | Сложный в освоении |
Phabricator | Мощные инструменты | Deprecated |
AI-помощники
| Инструмент | Что делает | Цена |
|---|---|---|
GitHub Copilot | Автодополнение, объяснение кода | $10/мес |
CodeRabbit | AI-ревью PR | Free tier |
Sourcery | Рефакторинг Python | Free tier |
DeepCode (Snyk) | AI-анализ безопасности | Free tier |
12. Чек-лист для джуна
Перед отправкой PR
Сделал self-review (прочитал свой diff)
Все тесты проходят
Нет ошибок линтера
Удалил console.log, TODO, закомментированный код
PR < 400 строк (или есть причина)
Написал понятное описание
Указал, как тестировать
При получении комментариев
Прочитал все комментарии
Не реагирую сразу эмоционально (пауза 10 мин)
Определил тип каждого комментария (блокер/важный/NIT)
Задал вопросы, если не понял
Поблагодарил за полезные замечания
При исправлении
Исправил все блокирующие замечания
Ответил на каждый комментарий
Объяснил решения, если не согласен
Записал новые замечания в свой список
Проверил, нет ли повторяющихся ошибок
После ревью
Добавил новые знания в заметки
Изучил тему, если замечание было непонятным
Обновил свой чек-лист перед PR
Посчитал статистику (комментариев стало меньше?)
Итоги
Код-ревью — не экзамен и не наказание. Это самый эффективный способ вырасти как разработчик. Ключевые выводы:
Отделяй себя от кода — критикуют код, не тебя
Классифицируй комментарии — блокер, важный, NIT, вопрос
Отвечай на всё — благодари, спрашивай, объясняй
Записывай замечания — веди статистику, отслеживай прогресс
Готовь PR правильно — self-review, тесты, маленький размер
Задавай вопросы — это ускоряет обучение
Ревьюь сам — учись у других, становись заметнее
Через год активного код-ревью ты будешь ловить баги, которые сейчас не видишь, и давать советы новым джунам. А комментарии к твоим PR превратятся из «42 замечания» в «Approved».
А лучшие вакансии для разработчиков ищите на hirehi.ru