Что нужно Junior, чтобы хорошенько отревьюить Senior? Стыдно признаться, но никогда не делал code review. Это не больно? Давайте разберемся со всеми этими вопросами и поймем что нужно, чтобы стать хорошим ревьюером и сабмитером.
Многие боятся делать ревью чужого кода, потому что считают, что не такие опытные для этого, что не смогут ничего дельного сказать, что не разберутся в чужом коде и отдают эту функцию более опытным коллегам. Но начинать проводить код ревью нужно чем раньше, тем лучше, потому что это в первую очередь полезно. Не важно кто вы — Junior или Senior! Начинайте ревьюить уже сегодня! Из явных личных плюсов: лучше начинаешь разбираться в проекте, видишь как другие мыслят, подсматриваешь примеры как человек справился с такой ситуацией, да и собственный уровень начинает расти. Даже если не можешь предложить ничего дельного, то просто просмотр чужого кода и чтение комментариев коллег к нему дает свои плоды, начинаешь понимать как можно делать, а где есть более хорошее решение. Итак, давайте, наконец, поймем как же проводить код ревью и какие скилы для этого нужны, а так же посмотрим какими навыками нужно обладать тем, кто будет создавать этот Pull Request.

Пока я собирал свои мысли на эту тему и делал пометки, кто-то уже все сделал и даже выступил на конференции EuroPython. К сожалению, я на самой конференции не был, но зато доступны слайды, которые хорошо сделаны так, что их можно смотреть без рассказчика. В этих 108 слайдах данный вопрос рассмотрен со всех сторон. Не поленитесь, полистайте на досуге:

Некоторые мысли очень близки мне, потому что я с данными проблемами сталкивался на практике. Самая главная мысль, на которую я хотел бы обратить внимание: Не будьте перфекционистами! От этого одни проблемы! Иначе Pull Request будет висеть месяц и в конце концов превратится в технический долг, а когда код зарастет конфликтами, то все меньше и меньше захочется к нему прикасаться.
Если Pull Request на 90% хорош, то это значит, что его уже можно мержить.
Итак, что же нужно, чтобы хорошо проводить Code Review?
  • Не доверяйте никому, просматривайте все сами: глаз замылен, поленился добавить проверку в надежде, что ревьюер заметит и укажет на это, не стал проверять все ли привел в порядок перед пушем — все это может быть пропущено из-за доверия. Не будьте клерком, который ставит штампы на документы не читая их.
  • Не будьте умными! Код должен быть хорошо читаем. Не зря есть такая фраза: «Хороший код как хорошая шутка — не требует объяснений».
  • Имейте терпение!
  • Будьте объективными. Используйте конструкцию «В этом методе пропущен комментарий» вместо «Ты забыл здесь поставить комментарий»
  • Задавайте вопросы, а не оставляйте ответы: «Что ты думаешь о….?», «Будет ли иметь смысл, если….?», делайте предложения: «Возможно было бы проще …..»
  • Оставляйте понятные комментарии: придерживайтесь только своего мнения, рассказывайте «как и почему», прикрепляйте ссылки на документацию, статьи, примеры. «Эта строчка кода заставляет меня грустить» — это непонятный комментарий.
  • Поощряйте хорошие идеи и решения.
  • Не будьте перфекционистами, приоритезируйте то, что действительно важно для вас. На 90% все хорошо — это уже достаточно.
  • Вначале делайте самые критичные замечания по архитектуре, дизайну, а только потом уже по слабым названиям переменных и грамматическим ошибкам.
  • Старайтесь провести review за 24-48 часов после создания.
Что нужно, чтобы быть хорошим сабмитером?

А если серьезно, то…..

  • Вы — главный ревьюер. Ревьюйте свой код также тщательно, как если бы вы делали ревью чужого кода. Старайтесь предвидеть проблемные места.
  • Проверяйте и тестируйте свой код прежде, чем сделать Pull Request, не заставляйте остальных отлавливать ваши ошибки. (помню был на работе один программист, который не запускал свой код. Объяснял он это тем, что ему платят за написание кода, а не за проверку работоспособности. Как вы понимаете, славы у коллег он не сыскал)
  • Сделайте себе чек-лист перед тем как создать Pull Request. Все ли пункты вы проверили из него и ничего ли не забыли. Достаточно мелких проверок вроде «а удалил ли я все строки закомментированного ненужного кода?» или «а проверил ли я есть ли неиспользуемые импорты и переменные?». Очень хорошая вещь. Пользовался сам — рекомендую.
  • Сделайте чек-лист с более глобальными проверками: «а будет ли мой код удобно поддерживать?», «устойчив ли мой код к сбоям?», «нет ли в моем коде проблем с безопасностью?» (да-да, до сих пор есть те, кто передают пароли в открытом виде get-запросом)
  • Не трогайте слишком сильно свой Pull Request во время процесса review
  • Если у вас большая фича и вы хотите, чтобы остальные видели процесс, откройте Pull Request, когда код будет написан за 30-50%. Не бойтесь того, что код еще незакончен. Ваши коллеги могут вам подсказать проблемы архитектуры, предложить нужные шаблоны проектирования.
  • Старайтесь делать небольшие Pull Request, чтобы было удобно проводить код ревью.
  • Проверяйте код с помощью автоматических инструментов.
  • Используйте pre-commit хуки.
  • Пишите юнит-тесты. Всегда. Не ленитесь. Они показывают, что код жив-здоров и могут указать на проблемы незамедлительно.
  • Всегда отвечайте на комментарии в Pull Request. Даже если это будут комментарии «fixed». Если вы не можете что-то исправить, или исправление не требуется, напиши это и объясните почему. Если вы что-то решил с коллегой за обедом, напишите это решение в Pull Request, чтобы остальные тоже видели.
  • Если вы что-то запушили — дайте знать коллегам.
  • Если вы считаете, что ваше решение лучше, чем предложенное, боритесь за это!
  • Не принимайте комментарии на свой счет. Воспринимайте это как ключ к собственному росту.
В заключение:

Код ревью — это очень важная часть жизни команды. Невозможно преуменьшить значение этого процесса. Это делает команду сильнее, код лучше и чище, дает рост не только новичкам, но и тем, кто уже опытный. Человек, который может хорошо провести код ревью ценится на вес золота. И всегда помните, что когда-то никто из нас не ревьюил код и не создавал Pull Request, поэтому имейте терпение к тем, кто этого еще не делал, и мир станет чуточку лучше. Всем добра!

Please follow and like us:
error

Оставить комментарий

avatar