Оффлайн
- Регистрация
- 12.04.17
- Сообщения
- 19.095
- Реакции
- 107
- Репутация
- 0
Неграмотно поставленные код-ревью серьёзно замедляют рабочий процесс. Когда большое количество изменений застревает на несколько дней (или недель!), то выход продукта на рынок придётся отложить. Вот несколько причин, почему такое происходит:
Отсутствует стандарт оформления кода
Каждая команда должна принять стандарт оформления кода (стандарт программирования, руководство по стилю), с которыми все согласны. В него входят соглашения об именовании, структуре папок, форматировании кода и список лучших практик, таких как модульное тестирование, валидация и т. д.
Отсутствие чёткого стандарта и соглашений заставляет каждого разработчика писать код так, как ему нравится, что приводит к спорам на код-ревью. Если вы видите много комментариев по поводу форматирования, соглашений об именовании и прочее, то пришло время поговорить об общем стандарте.
Ваша команда может либо разработать собственный набор рекомендаций, либо начать с известных рекомендаций от других компаний. Вот
Не используются автоматизированные проверки
После принятия стандартов оформления кода изучите инструменты для проверки соответствия этим стандартам. Почти для всех языков есть инструменты для форматирования кода, линтеры и другие утилиты, которые вы можете поставить в хуки перед коммитом и прописать в системах CI/CD.
Эти инструменты проверяют код на соответствие стандартам оформления и уведомляют автора о нарушениях. Автор получает возможность исправить проблемы перед отправкой пул-реквеста, что значительно снижает шум. Чем больше проверок проходит автоматически, тем больше времени остаётся у рецензента, чтобы сосредоточиться на более серьёзных проблемах, таких как огрехи архитектуры, пробелы в реализации и т. д.
Программисты не выполняют самостоятельный анализ своего кода
Прежде чем обращаться к коллегам за код-ревью, автор должен сам просмотреть собственные изменения. Это как проверка текста письма на опечатки и ошибки перед отправкой адресату.
На практике проверка собственного кода является сложной задачей, поскольку вы склонны подсознательно пропускать недостатки. Вот несколько способов улучшить качество самостоятельного анализа:
Огромные пул-реквесты
Количество комментариев к пул-реквесту обратно пропорционально количеству содержащихся в нем изменений. То есть большой PR → мало комментариев, маленький PR → много комментариев.
Дело в том, что рецензенты не внимательно изучают большой пул-реквест, а вместо этого склонны пролистать его, чтобы быстрее завершить работу. Это противоречит цели код-ревью. Иногда происходит обратное, когда автор много дней не получает никаких комментариев, потому что рецензент боится начать обзор слишком большого PR.
Разбейте пул-реквест на более мелкие куски, которые имеют смысл отдельно друг от друга. Так вы поможете рассмотреть их должным образом и быстро.
Расплывчатые пул-реквесты
Часто вам предлагают пул-реквест с расплывчатым описанием или вообще без оного. Рецензент должен понять смысл изменений, пытаясь вспомнить задачу, которую обсуждали где-то на собрании или в баг-трекере. Поэтому PR лучше снабжать сопроводительной информацией:
Эта информация обеспечит лучший контекст для рецензента и тем самым ускорит код-ревью.
Отсутствуют дедлайны для код-ревью
Один из способов растянуть код-ревью навечно — не поставить никаких дедлайнов для рецензента. Определите разумные сроки, например:
Спасибо за чтение!
- Отсутствует стандарт оформления кода
- Не используются автоматизированные проверки
- Программисты не выполняют самостоятельный анализ своего кода
- Огромные пул-реквесты
- Расплывчатые пул-реквесты
- Отсутствуют дедлайны для код-ревью
Отсутствует стандарт оформления кода
Каждая команда должна принять стандарт оформления кода (стандарт программирования, руководство по стилю), с которыми все согласны. В него входят соглашения об именовании, структуре папок, форматировании кода и список лучших практик, таких как модульное тестирование, валидация и т. д.
Отсутствие чёткого стандарта и соглашений заставляет каждого разработчика писать код так, как ему нравится, что приводит к спорам на код-ревью. Если вы видите много комментариев по поводу форматирования, соглашений об именовании и прочее, то пришло время поговорить об общем стандарте.
Ваша команда может либо разработать собственный набор рекомендаций, либо начать с известных рекомендаций от других компаний. Вот
You must be registered for see links
.Не используются автоматизированные проверки
После принятия стандартов оформления кода изучите инструменты для проверки соответствия этим стандартам. Почти для всех языков есть инструменты для форматирования кода, линтеры и другие утилиты, которые вы можете поставить в хуки перед коммитом и прописать в системах CI/CD.
Эти инструменты проверяют код на соответствие стандартам оформления и уведомляют автора о нарушениях. Автор получает возможность исправить проблемы перед отправкой пул-реквеста, что значительно снижает шум. Чем больше проверок проходит автоматически, тем больше времени остаётся у рецензента, чтобы сосредоточиться на более серьёзных проблемах, таких как огрехи архитектуры, пробелы в реализации и т. д.
Программисты не выполняют самостоятельный анализ своего кода
Прежде чем обращаться к коллегам за код-ревью, автор должен сам просмотреть собственные изменения. Это как проверка текста письма на опечатки и ошибки перед отправкой адресату.
На практике проверка собственного кода является сложной задачей, поскольку вы склонны подсознательно пропускать недостатки. Вот несколько способов улучшить качество самостоятельного анализа:
- Оформить пул-реквест без назначения рецензентов и вернуться к нему через пару часов, чтобы свежим взглядом взгянуть на свои правки.
- Подавлять свою естественную склонность пролистывать изменения, а вместо этого намеренно просматривать их строчку за строчкой.
- Следовать контрольному списку вопросов: соответствует ли код стандарту оформления? удовлетворяются ли все бизнес-требования? есть ли тесты для всех возможных вариантов использования? и т. д.
Огромные пул-реквесты
Количество комментариев к пул-реквесту обратно пропорционально количеству содержащихся в нем изменений. То есть большой PR → мало комментариев, маленький PR → много комментариев.
Дело в том, что рецензенты не внимательно изучают большой пул-реквест, а вместо этого склонны пролистать его, чтобы быстрее завершить работу. Это противоречит цели код-ревью. Иногда происходит обратное, когда автор много дней не получает никаких комментариев, потому что рецензент боится начать обзор слишком большого PR.
Разбейте пул-реквест на более мелкие куски, которые имеют смысл отдельно друг от друга. Так вы поможете рассмотреть их должным образом и быстро.
Расплывчатые пул-реквесты
Часто вам предлагают пул-реквест с расплывчатым описанием или вообще без оного. Рецензент должен понять смысл изменений, пытаясь вспомнить задачу, которую обсуждали где-то на собрании или в баг-трекере. Поэтому PR лучше снабжать сопроводительной информацией:
- Какие изменения в нём содержатся
- С каких файлов начать
- Ссылка на задачу в баг-трекере
- Скриншоты, если это какое-то визуальное изменение
Эта информация обеспечит лучший контекст для рецензента и тем самым ускорит код-ревью.
Отсутствуют дедлайны для код-ревью
Один из способов растянуть код-ревью навечно — не поставить никаких дедлайнов для рецензента. Определите разумные сроки, например:
- Код-ревью должен быть закончен за 48 часов с момента отправки пул-реквеста.
- Для хотфиксов срок 30 минут.
Спасибо за чтение!