1/14
Искусство ревью 121
как часть эффективного процесса разработки1
Цели встречи
- Вспомнить, для чего мы ревьюим код
- Погрузиться в процесс с точки зрения разработчика/ревьюера
- Узнать, как ещё эффективнее вносить предложения по улучшению кода
- Рассмотреть преимущества кросс-ревью
- Подвести итоги
Для чего нужно ревью в эффективной команде
- Поиск ошибок
- Исправление ошибок, пока это "дёшево"
- Ознакомление команды с кодовой базой
- Вовлечение всех участников команды в задачу
- Поддержание качества кода
- Улучшение архитектуры и производительности
- Повышение качества документации
- Обучение и обмен знаниями
Структура процесса ревью
Подготовка Pull Request (PR)
Передача PR на ревью
Замечания и вопросы
Внесение изменений, если необходимо
Повторная передача PR на ревью
Слив в мастер и выкладка
Структура процесса ревью
Подготовка Pull Request (PR)
Передача PR на ревью
Замечания и вопросы
Внесение изменений, если необходимо
Повторная передача PR на ревью
Слив в мастер и выкладка
Как понять, что PR готов к ревью?
если ты разработчик
- Код протестирован локально и/или в тестовом окруженииВключая edge/corner кейсы
- Написаны тестыUnit или функциональные, в зависимости от потребностей
- PR описан и понятен
- Использован шаблон
- Обновлена документация, если требуется
- Код чист и готов к проверке
- Пройден линтинг
- Успешно выполнены CI-тесты
Сделать так, чтобы ревьюер мог сосредоточиться на качестве кода, а не на исправлении базовых ошибок
Структура процесса ревью
Подготовка Pull Request (PR)
Передача PR на ревью
Замечания и вопросы
Внесение изменений, если необходимо
Повторная передача PR на ревью
Слив в мастер и выкладка
Что проверять?
если ты ревьюер
- Код читаемый и соответствует стандартам
- Код-стайл соблюден
- Понятные имена переменных, методов, классов
- Логика корректна
- Бизнес-логика соответствует требованиям
- Старый функционал не ломается
- Код покрыт тестамиТесты есть, охватывают достаточно кейсов
- Код безопасен
- Переменные валидируются
- Санация перед запросами/исполнением методов с участием переменных
- Проверяются права пользователя перед исполнением действия
- Не возвращаем пользователю лишнего
- Архитектура качественная
- Реализуемое решение расширяемо и поддерживаемо
- Код продолжает работать при увеличении нагрузки
- Избегается дублирование кода
Понять, соответствует ли код требованиям команды и бизнеса, и предложить улучшения
Структура процесса ревью
Подготовка Pull Request (PR)
Передача PR на ревью
Замечания и вопросы
Внесение изменений, если необходимо
Повторная передача PR на ревью
Слив в мастер и выкладка
Как преуспеть в процессе ревью
- Конструктивные предложения в комментариях, обоснование позиции
- Конкретика и последовательность замечаний
- Готовность к диалогуВозможно, это не ошибка
- Нам это ещё поддерживатьВсё, что будет одобрено на ревью - уйдёт в кодовую базу надолго
- Смело предлагайте улучшения на перспективуНе обязательно полировать код в рамках этого PR - заведи в задачу в техдолг
- Иногда замечаний может не быть - это нормальноPR бывает неплох и без правок
- Проводите ревью регулярноФичи быстрее доставляются на прод, а мы можем планировать своё время
- Приглашайте на кросс-ревью
Кросс ревью
когда ревьюер может быть плохо знаком с сервисом или его частью
- Свежий взгляд на реализацию
- Передача опыта/обучение
- Кросс-командное взаимодействие
- Больше выбор тех, кого можно позвать на ревью
Виды замечаний
определяем, стоит ли блокировать доставку фичи
Блокирующие (Request Changes)
- неверная бизнес-логика
- не учтены corner/edge кейсы
- серьёзные проблемы с производительностью
- проблемы с архитектурой
- код сложно читается и есть предложения по облегчению логики
Неблокирующие
(Approve + комментарий)
(Approve + комментарий)
При условии, что в целом код работает корректно и может быть выложен.
- мелкие нарушения код стайла
- небольшие предложения по улучшению читаемости
- предложения по оптимизации, несущественно влияющие на производительность
- предложения добавить логи
Структура процесса ревью
Подготовка Pull Request (PR)
Передача PR на ревью
Замечания и вопросы
Внесение изменений, если необходимо
Повторная передача PR на ревью
Слив в мастер и выкладка
Работа над замечаниями
- Иногда достаточно пояснений
- Повышенное внимание к исправлениямМожно наделать ещё больше ошибок
Структура процесса ревью
Подготовка Pull Request (PR)
Передача PR на ревью
Замечания и вопросы
Внесение изменений, если необходимо
Повторная передача PR на ревью
Слив в мастер и выкладка
итоги
Ревью — это не только поиск и исправление ошибок
но и инструмент, обеспечивающий высокое качество кода, улучшение архитектуры и обмен знаниями в команде
Важно подходить к процессу ответственно
подготовить PR так, чтобы он был готов к ревью, проверяя функциональность, тесты и соответствие стандартам, а при ревью оценивать код с позиции его читаемости, бизнес-логики и перспектив развития
Конструктивные обсуждения, разделение замечаний на блокирующие и неблокирующие, а также регулярные ревью помогают команде быстрее доставлять фичи и поддерживать долгосрочное качество продукта.
но и инструмент, обеспечивающий высокое качество кода, улучшение архитектуры и обмен знаниями в команде
Важно подходить к процессу ответственно
подготовить PR так, чтобы он был готов к ревью, проверяя функциональность, тесты и соответствие стандартам, а при ревью оценивать код с позиции его читаемости, бизнес-логики и перспектив развития
Конструктивные обсуждения, разделение замечаний на блокирующие и неблокирующие, а также регулярные ревью помогают команде быстрее доставлять фичи и поддерживать долгосрочное качество продукта.
Спасибо за внимание
