Персональные выводы
Такой способ проверки кода трудозатратен, что значит дороже для бизнеса. Разработчик тратит больше времени на ревью, но при этом команда улучшает качество кода, увеличивается вовлеченность команды, из этого следует, что знания шарятся лучше (а это увеличение bus фактора).
Главная цель - проверка работоспособности бизнес задачи и проверка архитектуры. При этом, важно как можно быстрее доставить функционал. Старайтесь избегать случаев, когда разработчик тратит время на стилистические исправления, а потом удаляет старый код и пишет новый.
В идеале, каждый ревьювер обязан проверить лично, что фича работает корректно. Но настройка окружения и подготовка данных - медленный процесс. Поэтому выгоднее потратить время одного разработчика и сделать скриншоты или видео того, как работает новый код, чем тратить время N ревьюверов на одну и ту же работу.
Сложность ревью пропорциональна количеству кода. Чтобы справляться с этим, разбивайте работу на "атомарные" пулл реквесты, которые не превышают N строк (например - 200 для кода без тестов). Например, в опен сорс проектах, я стал просить людей разбивать работу над задачей на отдельные пулл реквесты
Для последнего шага ревью необходима внимательность, но с этим возникают проблемы у отдельных людей (ADHD напрмиер). При этом, базовые проверки, таких как стиль, грамматика и опечатки автоматизируются с помощью код стайла с rubocop, danger и codeclimate, который показывает, какие части пулл реквеста не покрыты тестами.
Как говорилось, главный минус такого подхода в повышенной энергозатратности для ревьюверов. Отсутствие настроения или желания, авралы и слабость - нормальные явления. Поэтому не стоит огорчаться, если не получается с первого, второго и даже десятого раза. Главное - регулярность и поддержка команды.
Не стоит писать комментарии на каждый из шагов разом. В идеале, если ревью не прошло шаг, стоит остановиться и подождать когда код "пойдет дальше". Не стоит захламлять ПР, разработчик может не понять где проблемы, а где просто мысли или вторичные проблемы, которые опускаются.
# Запомнить
- понимание задачи > выполнение задачи > архитектура > текст
- работающий код > идеальный код
- поймите контекст и важность задачи, перед тем как смотреть код
- цените время разработчика, не просите исправлять то, что изменится
- меньше кода - меньше конгнетивная нагрузка для ревьюверов и быстрее процесс ревью
- автоматизируйте, если это возможно
# Полезное
- 11 советов, как улучшить ревью от IBM
- Еще советы, на этот раз от asana
- И еще советы
- Посмотрите, как Лука пишет описания к ПР-ам в ханами, у него есть чему научиться
Такой способ проверки кода трудозатратен, что значит дороже для бизнеса. Разработчик тратит больше времени на ревью, но при этом команда улучшает качество кода, увеличивается вовлеченность команды, из этого следует, что знания шарятся лучше (а это увеличение bus фактора).
Главная цель - проверка работоспособности бизнес задачи и проверка архитектуры. При этом, важно как можно быстрее доставить функционал. Старайтесь избегать случаев, когда разработчик тратит время на стилистические исправления, а потом удаляет старый код и пишет новый.
В идеале, каждый ревьювер обязан проверить лично, что фича работает корректно. Но настройка окружения и подготовка данных - медленный процесс. Поэтому выгоднее потратить время одного разработчика и сделать скриншоты или видео того, как работает новый код, чем тратить время N ревьюверов на одну и ту же работу.
Сложность ревью пропорциональна количеству кода. Чтобы справляться с этим, разбивайте работу на "атомарные" пулл реквесты, которые не превышают N строк (например - 200 для кода без тестов). Например, в опен сорс проектах, я стал просить людей разбивать работу над задачей на отдельные пулл реквесты
Для последнего шага ревью необходима внимательность, но с этим возникают проблемы у отдельных людей (ADHD напрмиер). При этом, базовые проверки, таких как стиль, грамматика и опечатки автоматизируются с помощью код стайла с rubocop, danger и codeclimate, который показывает, какие части пулл реквеста не покрыты тестами.
Как говорилось, главный минус такого подхода в повышенной энергозатратности для ревьюверов. Отсутствие настроения или желания, авралы и слабость - нормальные явления. Поэтому не стоит огорчаться, если не получается с первого, второго и даже десятого раза. Главное - регулярность и поддержка команды.
Не стоит писать комментарии на каждый из шагов разом. В идеале, если ревью не прошло шаг, стоит остановиться и подождать когда код "пойдет дальше". Не стоит захламлять ПР, разработчик может не понять где проблемы, а где просто мысли или вторичные проблемы, которые опускаются.
# Запомнить
- понимание задачи > выполнение задачи > архитектура > текст
- работающий код > идеальный код
- поймите контекст и важность задачи, перед тем как смотреть код
- цените время разработчика, не просите исправлять то, что изменится
- меньше кода - меньше конгнетивная нагрузка для ревьюверов и быстрее процесс ревью
- автоматизируйте, если это возможно
# Полезное
- 11 советов, как улучшить ревью от IBM
- Еще советы, на этот раз от asana
- И еще советы
- Посмотрите, как Лука пишет описания к ПР-ам в ханами, у него есть чему научиться