Код-ревью - важнейший этап разработки. Правильное ревью улучшает качество кода, выявляет баги на ранней стадии и повышает уровень команды и конечно качество продукта. Но если делать его плохо, это приведет к недовольству, снижению мотивации и тому, что вас могут начать хейтить.
узнай больше на курсе
Python программист с нуля
Стань разработчиком на одном из самых популярных языков программирования - Python
Когда цель понятна, тон общения становится естественно конструктивным. Ставьте цели, зачем вы вообще это делаете? Явно не чтобы показать как вы круты (а кто-то нет).
1. Задавайте вопросы, а не утверждайте
Вместо «Это неверно» используйте: «Интересно - почему условия инвертированы? Может, проще будет поменять?» Это помогает понять логику автора кода и не уничтожить его хрупкую сущность
2. Не придирайтесь к стилю
Линтер и форматтер - за это отвечают. Вы сосредоточьтесь на:
Логике и ошибках
Именованиях
Архитектуре
Неочевидных паттернах
3. Ясность важнее «красивого» кода
Перед тем как предложить «крутую» замену, задумайтесь: улучшит ли это понимание кода? Например:
«Может, reduce упростит, но если не уверен - оставьте текущий вариант»
4. Отмечайте хорошее
Не ограничивайтесь критикой. Горячее похвала - мотивирует:
«Отличная проверка на null - спасёт от ошибок»
«Именование супер - сразу ясно, что происходит»
«Отличная стрижка, только височки могли сделать чуть лучше»
5. Смотрите на идею, не только на строки
Задайте вопросы типа:
«Сделает ли PR то, что обещано?»
«Есть ли более простой способ?»
«Нужно ли вынести часть логики на сервер?»
6. Что обязательно, а что опционально
Отделяйте важные правки от рекомендаций:
«Не блокирующий, но рекомендую так-то так-то»
«Блокирующий: сломается на пустых массивах, надо переделать»
«Можно изменить по вкусу, без критичности»
7. Быстро или не беритесь
Задержка в ревью - демотивирует. Если заняты, просто скажите.
Отвечайте в течение 24 часов - человек (особенно джун) испытает катастрофу, если вы не отвечаете
Когда добрались до ответа, отвечайте детально
8. Поощряйте вопросы в PR
Создавайте атмосферу, где разработчик не боится обсуждать: «Не уверен с кешированием - посмотрите?»
9. Не делайте огромных PR
Разделяйте на мелкие - до 600 строк. Добавляйте TL;DR к крупным.
10. Завершайте на позитивной ноте
Даже после критики важно поддержать:
«Отличная работа, почти готово»
«Спасибо за рефактор - теперь всё понятнее»
Почему всё это важно
Правильное код-ревью:
Улучшает качество кода - а это меньше багов
Создаёт доверие внутри команды - вам всем еще в бар ходить
Ускоряет рост джунов
Обнаруживает архитектурные ошибки
Снимает напряжённость
Дает прохладу, свежесть и возможно силу земли
Плохое:
Убивает мотивацию
Замедляет релизы
Порождает хейт, молчаливую дисгармонию и демотивацию
Код-ревью показывает зрелость и культуру команды. Вы строите продукт, развиваете людей, а не только пишите код. И помните: самое главное, просто не будьте му***ом - и всё будет в порядке
Java 21 имеет ряд улучшений в производительности и синтаксисе, однако есть подводные камни. В статье расскажем все о рисках и как сделать миграцию безболезненной
SQL или NoSQL, вот в чём вопрос! И как раз с этим вопросом мы поможем сегодня разобраться. Что использовать в каких случаях, где есть какие преимущества и как возможно использовать их все вместе.
