Ревью кода

Я как-то уже записывал видео про ревью кода, как я познакомился с pull запросами и мое отношение к ним. 

Ревью кода необходимо, и не только для того, чтобы увидеть потенциальные проблемы в кода, но и с точки зрения обучения. 

Читая чужой код можно многому научится, а ревью кода это тоже чтение и тут тоже можно научится у других чему-то новому. За всем уследить сложно в нашем мире. 

Сегодня я решил ещё раз вернуться к этой теме, потому что недавно столкнулся с проблемой, которую стоит ещё раз затронуть.

Ревью кода - это не место для выпендрежей. Самое первое и самое главное, о чем нужно помнить, во время ревью кода ни в коем случае не стоит доказывать, что вы умнее других. Свою крутизну и познания можно показывать, когда будете писать свой код. 

Очень важно помогать делать код лучше, а не пытаться унижать других. 

Начинающие нередко делают ошибки, иногда даже просто по незнанию и опускать их жёсткими комментариями на запросах на изменение кода умения вызывает противные чувства. 

Когда я пишу комментарии, то стараюсь избегать любых негативных слов. Даже если есть ошибка или проблема, можно постараться писать отзыв с положительной точки зрения. 

Недавно я видел pull request, в котором изменялись данные в базе и использовалась табличная переменная. Я сразу заподозрил, что запрос будет выполняться долго, я выполнял его в транзакции на большой тестовой базе и оказалось, что он выполнялся 25 минут. При запуске в прод ожидание скрипта 25 минут может оказаться непозволительной роскошью. Простая замена табличной переменной на временную таблицу позволило ускорить скрипт и он уже выполнялся 10 секунд. 

Мой комментарий на скрипт выглядел так:

Я протестировал запрос на тестовой базе и он отработал за 25 минут и корректно обновил данные. Данные после обновления выглядят корректно. Отличная работа. Мы можем ускорить скрипт простой заменой табличной переменной на временную таблицу. 

Очень много текста, написать «это будет работать медленно» на много проще, но при написании комментария не всегда нужно быть кратким, лучше не жалеть слов. 

Это не всё, далее в моем комментарии было даже указано, какие строчки нужно поменять и на что. 

Короткий комментарий написать просто, но лучше потратить немного времени и сделать  максимально положительный отзыв. 

В данном примере есть ещё очень важная составляющая хорошего комментарий на pull request - не просто отзыв, но ещё и конкретная рекомендация, как сделать код лучше. Критикуя нужно обязательно предлагать, как сделать код лучше с конкретным кодом. 

У меня был опыт работы с очень хорошим программистом, который очень часто комментировал чужие запросы и придирался к каждой мелочи и при этом очень редко давал конкретных примеров. Почти всегда были достаточно размытые комментарии типа - «плохое имя переменной». Мало того, что здесь используется негативное слово, но и нет рекомендации, что было бы лучше использовать. Вместо этого можно было бы написать: «код выглядит хорошо, а что если переименовать переменную в IsActive, будет это лучше отражать смысл?». 

Старайтесь писать комментарии так, чтобы они были максимально положительными. 

Перед тем, как сохранять комментарий, прочитайте и подумайте, а вам будет приятно читать такое? Я заметил, что когда программисты пишут негативный комментарий, они думают, что они не получат такого в ответ, потому что сами не пишут говнокод. 

Ещё одна популярная причина для негативных комментариев - мне писали такое и я напишу. Это тоже плохой поход, когда люди проецируют негатив на других. 

Я в своём видео говорил, что я сам иногда утверждаю запросы с небольшими проблемами, особенно синтаксическими. Например, если проблема стиля или имени переменной, то я могу утвердить запрос и написать комментарий. Программист после  этого имеет право завершить запрос и исправить проблему позже. Это нормально, если программисты реально исправляют после этого небольшие недочеты и рекомендации и из моей практики они реально изменяют код ещё до завершения запроса, то есть они сначала исправляют проблему и потом завершают запрос. 

Тот факт, что я утверждаю небольшие проблемы, но даю комментарии - показывают мое доверие. Программисты ощущают, что я им доверяю и не напрягаю, а это также создаёт положительную атмосферу в команде. 

Хорошо ещё общаться вне тикетов, особенно, когда проблема серьезная или непонятная.

Если я не понимаю что-то, то я чаще пишу сообщение напрямую в чате программисту, чтобы он объяснил, почему он что-то сделал. Приватность позволяет программисту раскрепоститься и он не боится, что проблема будет обсуждаться публично. 

То же самое с серьезными проблемами. Если я вижу серьезный косяк, Толя также не буду писать комментарий публично, а напишу человеку напрямую и дам ему шанс самостоятельно отклонить свой запрос и спокойно исправить проблему. 

Общение офлайн очень важно. Хотя тут сложно говорить про офлайн, когда мы работаем удалённо и общаемся только через интернет, но в данном случае имеет мы ввиду не публичное общение. 

Я привёл уже пару примеров комментариев и обратите внимание, что там нет сочетания двух букв ТЫ. Я стараюсь писать комментарии так, чтобы их там не было и использую прямое обращение к человеку только в крайнем случае. Вместо этого я стараюсь использовать буквы МЫ. В первом примере я использовал оборот «мы можем», потому что это указывает, что мы все в одной лодке и делаем одну работу. 

---

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку уже лайкнули 2 человек

---