За многие годы написания и проверки кода я узнал несколько секретов, позволяющих лучше создавать запросы на включение и более эффективно проверять код.
Все эти секреты я изложил в своей новой книге «Запросы на включение и обзор кода» , но здесь вы найдете предварительный просмотр с этими 13 советами, которые вы уже можете использовать в своей деятельности разработчика.
Можете ли вы придумать еще советы? Поделитесь ими в комментариях 😉
1. Создайте свой PR до того, как код будет готов к проверке.
Пиар-проект поможет вам систематизировать свои идеи и документировать прогресс, пока вы еще работаете над своей функцией.
2. Заставьте людей хотеть пересмотреть ваш пиар
Лучший способ получить быструю и эффективную проверку — сделать ваш PR небольшим и хорошо документированным (со всем необходимым контекстом). Вы также увеличите свои шансы на будущие PR, предоставив отличный код прямо сейчас!
Все эти советы и многое другое, а также больше реальных примеров и практических идей вы найдете в моей бесплатной книге «Запросы на включение и обзор кода: лучшие практики для разработчиков, от младшего до руководителя группы ».
3. Будьте первым рецензентом вашего пиара
Поставьте себя на место своего рецензента, предугадывайте вопросы и комментируйте свой собственный код, если считаете, что это может им помочь.
4. Назначьте подходящих рецензентов для вашего пиара
Не поручайте свой пиар всему миру. Тщательно выбирайте рецензентов, чтобы получить релевантный отзыв, не дожидаясь одобрения слишком долго.
5. Будьте отзывчивы на комментарии
Будьте открыты для обратной связи, просите разъяснений, говорите, если вы не согласны (с уважением), и всегда отвечайте на комментарии.
6. Если вы хотите, чтобы люди просматривали ваши PR, вы должны просматривать их
У каждого есть много PR, которые нужно просмотреть, и мало свободного времени. Если вы просматриваете другие PR, вы увеличиваете шансы на то, что ваш тоже будет рассмотрен.
7. Вы можете просматривать код, даже если вы младший разработчик.
Будучи младшим разработчиком, вы можете сообщить другим, если вы не понимаете часть кода, поскольку он должен быть понятен любому разработчику в команде.
Подробнее об этом в моем посте «Как проводить ревью кода младшему разработчику?» .
8. Проверяйте правильность во время проверки кода
Цель проверки кода — выявить ошибки и крайние случаи, а также бросить вызов реализации. Его не следует использовать ни для придирок к незначительным предпочтениям форматирования или стиля, ни для крупномасштабных архитектурных обсуждений.
9. Используйте правильный тон в комментариях
Используйте «почему бы и нет» вместо «вам следует», будьте открытыми и позитивными и всегда предлагайте альтернативу, когда просите об изменении.
10. Четко определите, требуются ли изменения для утверждения ОР или нет.
Не все комментарии требуют внесения изменений, и не все запрошенные изменения необходимы для утверждения ОР. Уточните в своем комментарии, если изменение не является срочным.
11. Просмотрите свой отзыв перед его отправкой.
Прежде чем опубликовать свой отзыв, перечитайте каждый комментарий: проверьте тон, который вы используете, и убедитесь, что вы предоставили весь контекст, чтобы помочь отправителю PR.
12. Утвердите PR, когда отправитель внес все запрошенные вами изменения.
Вы не хотите, чтобы рецензент ждал вашего одобрения через два дня после внесения всех запрошенных вами изменений. Просматривая его, предполагайте, что вы одобрите его, как только будут внесены все исправления.
13. Некоторые конфликты нельзя решить в комментариях.
Когда ветка комментариев становится дискуссией в вашем PR, вам лучше ее отключить и предложить продолжить обсуждение в другом месте, например, в ветке Slack. При необходимости посвятите этому встречу и/или привлеките третью сторону.
Вот и все! Что вы думаете об этих советах? Можете ли вы придумать один совет, который вы хотели бы дать другим разработчикам?
Поделитесь ими здесь в комментариях 👇
Если вам понравились эти советы и вы хотите узнать больше, прочтите мою книгу «Запросы на включение и обзор кода» , она бесплатна!
Также опубликовано здесь .
