Насколько душным должно быть код-ревью?
Код-ревью легко превращается в источник раздражения: придирки к стилю, бесконечные итерации, долгое ожидание и неясный фидбек. Но ту же проверку можно сделать полезной для обеих сторон — если договориться о правилах и убрать рутину.
Сабина (DataArt) и Жанара (Ozon) в совместном докладе разбирают боли ревьюера и ревьюируемого и показывают, как давать и принимать фидбек так, чтобы он приносил пользу. Они опираются на собственный опрос разработчиков о том, что делает код-ревью полезным.
В докладе: — как отдать рутину машинам: тесты (pytest), форматирование (black, isort), линтинг (flake8, pylint, mypy, bandit) и Ruff — pre-commit и автоматическое ограничение размера больших пулл-реквестов — как определять стандарты кода для проекта и фиксировать их в документации и чек-листах — как готовить пулл-реквест: ревью самому себе, понятное описание (What? Why?), не смешивать рефакторинг с логикой, уважать время ревьюеров — как принимать фидбек без перфекционизма и уточнять неясные замечания вместо защиты — как давать фидбек: примеры кода, запросы вместо команд, отказ от «ты», отмечать не только недостатки — culture map: почему «okay» у американцев и голландцев значит разное
Презентация
1 / 28Текст презентации
Слайд 1: Насколько душным
Насколько душным должно быть код ревью? Как давать и принимать фидбек так, чтобы он приносил пользу Задайте нам вопросы :) Жанара tg: @zhanariqqq https://www.linkedin.com/in/zhanara-lessova-82095a165 Сабина tg: @otsabyatina https://www.linkedin.com/in/sabintius
Слайд 2: Введение
Введение
Слайд 3: Code review & pull request
Code review & pull request Code Review - это процесс проверки и анализа кода задачи разработчиком перед ее релизом. CR (Code Review) выполняется не тем человеком, который делал задачу, а другими членами команды. Результатом CR является обратная связь по выполненной задаче: необходимость внести правки, либо готовность задачи к последующему тестированию и релизу.
Слайд 4: Мы провели опрос
Мы провели опрос https://docs.google.com/spreadsheets/d/10YVPpMR7PtGENlBvSITH_QdXelqAs2rf0fBlMveTQZ0
Слайд 5: Мы провели опрос
Мы провели опрос
Слайд 6: Мы провели опрос
Мы провели опрос
Слайд 7: Мы провели опрос
Мы провели опрос https://docs.google.com/spreadsheets/d/10YVPpMR7PtGENlBvSITH_QdXelqAs2rf0fBlMveTQZ0 Factors contributing to the usefulness of code reviews
Слайд 8: Разбор проблем и их
Разбор проблем и их решения
Слайд 9: Боли код ревью
Боли код ревью Боли ревьюируемого 1. Комментарии по стилю кода 2. Незначительные придирки, тормозящие релиз (nits) 3. Добавление новых и новых комментариев при повторных итерациях ревью 4. Долгое ожидание ревью 5. Невнимательные/незаинтересованные в качественном анализе ревьюеры - фидбек неэффективный или неясный Боли ревьюера 1. Код который сложно читать из-за непривычного для проекта стиля 2. Большие пулл реквесты - отнимают значительно больше времени 3. Большие пулл реквесты - легче упустить какие-то проблемы, которые приходится указывать при повторном ревью/оверинжиниринг 4. Недостаточное понимание контекста изменений 5. Не хватает фокуса/сил/времени и на ревью и на свои задачи
Слайд 10: Отдать всю рутину машинам TESTING (а всё ли работает?)
Отдать всю рутину машинам TESTING (а всё ли работает?) ● pytest (simple and nice) ● unittest (built-in) CODE FORMATTING (а код читабельный?) ● black (Uncompromising) ● autopep8 (pep8 loving) ● Isort (Sort imports) LINTING (а код качественный?) ● flake8 ● pylint ● mypy ● bandit (аудит безопасности) Боли ревьюируемого 1. Комментарии по стилю кода 2. Незначительные придирки, тормозящие релиз (nits) 3. Добавление новых и новых комментариев при повторных итерациях ревью 4. Долгое ожидание ревью 5. Невнимательные/незаинтересованные в качественном анализе ревьюеры - фидбек неэффективный или неясный Боли ревьюера 1. Код который сложно читать из-за непривычного для проекта стиля 2. Большие пулл реквесты - отнимают значительно больше времени 3. Большие пулл реквесты - легче упустить какие-то проблемы, которые приходится указывать при повторном ревью/оверинжиниринг 4. Недостаточное понимание контекста изменений 5. Не хватает фокуса/сил/времени и на ревью и на свои задачи AND RUFF!
Слайд 11: Isort, black, flake8 - краткий обзор 88 symbols ✨✨
Isort, black, flake8 - краткий обзор 88 symbols ✨✨
Слайд 12: Pre-commit (за кодом следит 👀)
Pre-commit (за кодом следит 👀)
Слайд 13: Big PR size reducer
Big PR size reducer repos: - repo: local hooks: - id: limit name: limit files: src entry: bash -c ( "docker compose run -T --rm <container_name>" " python tools/limit.py $(git diff --name-only origin/main)" language: system pass_filenames: false
Слайд 14: Вы можете настроить файл
Вы можете настроить файл конфигураций в соответствии с конкретными требованиями вашего проекта, например, добавить дополнительные шаги для создания Docker образов, развертывания на облаках или выполнения сквозных тестов, а также настроить команды и зависимости.
Слайд 15: RUFF - стильно модно молодежно
RUFF - стильно модно молодежно https://docs.astral.sh/ruff/
Слайд 16: Определить стандарты кода для проекта
Определить стандарты кода для проекта 1. Создавать стандарты кода (джуны, вы тоже можете это делать) a. Обсуждать на звонках с командой и делать предложения, готовиться и копить аргументы; b. Необязательно сразу придумывать все-все стандарты. Можно делать это шаг за шагом. c. Принятые решения добавлять в документацию проекта, например, чтобы закрепить и ссылаться впоследствии; d. Договориться, что ревьюер держит стандарты под рукой; e. Чек-листы - на создание пулл-реквеста, на проверку пулл-реквеста; 2. Явно указывать, какую структуру файлов команда должна использовать, какие вещи стоит добавлять в логи, в каких случаях записывать метрики; когда трассировать запрос. 3. Новый разработчик не должен задумываться о структуре для добавляемой фичи. Явное лучше неявного
Слайд 18: Коммуникации
Коммуникации
Слайд 19: Готовить пулл реквест 🥣
Готовить пулл реквест 🥣 1. Сделать ревью самой себе 2. Добавь понятное описание к пулл-реквесту (What? Why?) 3. Создать issue в “смутном” месте 4. Комментарии это ок, если ими не злоупотреблять. 5. Не смешивать рефакторинг с изменениями в логике. Основная идея - уважать время своих ревьюеров. Не все команды делают оценку времени на ревью. Иными словами, это задача, которой нет в таск трекере. https://mtlynch.io/code-review-love/ Your teammate arrives at work each day with a finite supply of focus. If they allocate some of it to you, that’s time they can’t spend on their own work.
Слайд 20: Получать фидбек 👂
Получать фидбек 👂 1. Перфекционизм a. Не бери на себя, никто не хочет вредить b. Ты - не твоя работа, и это не про ум (и про выгорание) c. Всем угодить не получится d. Бизнесу не нужны перфекционисты 2. Если ревьюер неправ - перепроверить читабельность своего кода. 3. Неясный фидбек - повод уточнить, а не защищаться. Цель - сделать хорошую фичу. “What changes would be helpful?” 4. Сказать спасибо. Ревьюер тратит свое время и силы, чтобы ты могла быть молодцом! 5. Отслеживание своих паттернов 6. Любой фидбек это возможность ускорить свое развитие. Доить токсичных ревьюеров на знания!
Слайд 21: Culture map
Culture map Americans: Excellent = Okay Okay = Not okay Dutch: Excellent = Wow! Okay = Neutral
Слайд 22: Давать фидбек ✍
Давать фидбек ✍ 1. Примеры кода 2. Избавляемся от «ты» 3. Запросы вместо команд 4. Не только недостатки, но и достижения 5. Улучшение кода на “уровень”(или 2) выше 6. Предотвращение тупиковых ситуаций заранее
Слайд 23: Цитатки
Цитатки ты знаешь достаточно, действительно достаточно, хоть и не всё (точно также, как и эти более громкие чем ты люди со своими мнениями), чтобы выполнить эту работу достаточно хорошо, не идеально, но к идеальному идеалу стремиться и не нужно, мы веб-разработчики, код все равно будет переписан You work with teammates who are human and theyhave human emotions.
Слайд 25: Личный опыт
Личный опыт
Слайд 28: https://mtlynch.io/
https://mtlynch.io/ https://google.github.io/eng-practices/review/reviewer/standard.html https://docs.google.com/spreadsheets/d/10YVPpMR7PtGENlBvSITH_QdXelqAs2rf0fBlMveTQZ0 https://devinterrupted.substack.com/p/the-11-types-of-toxic-pull-requests https://www.cybrosys.com/blog/useful-pycharm-keyboard-shortcuts https://www.codelantis.com/blog/code-review-acronyms-lgtm-nit https://flexberry.github.io/ru/fp_code-review-check-list.html https://purpleschool.ru/blog/code-review-checklist
Другие доклады митапа
- КИскусство ошибаться Карина
- Н
- НЕКак команду мануальных тестеров научить авто-тестированию на Python? Назира Егизбаева
- РТПоднятие retention через push-уведомления Римма Толеугали

























