День 1093. #CodeReview 10 Советов по Написанию Эффективных Обзоров Кода. Окончание Начало 5. Следуйте рекомендациям Если ваша команда достаточно большая, у вас наверняка есть некоторые рекомендации по написанию кода проекта: общие подходы к организации кода, соглашения об именах и т.п. Если вы активно пишете код и просматриваете код других, вы, вероятно, привыкли к ним. Однако полезно возвращаться к рекомендациям и пробегать их глазами каждые пару недель или каждый месяц. Вы будете удивлены, увидев, сколько моментов вы забыли или на которые не обращали внимания в обзорах. Если у вашей команды нет этих правил, было бы неплохо написать их во время очередной проверки кода. Такой список будет служить единственным источником правды в вашей команде, гарантируя, что у всех авторов кода и рецензентов есть ресурс, на который можно обратить внимание при написании/обновлении/чтении кода. 6. Хвалите хороший код Проверка кода не всегда связана с криткой. Иногда вы будете натыкаться на код, который заставит вас отдать должное автору. Кусок логики, очень эффективная оптимизация запросов или блестящий UX. Сообщите об этом. Можно оставить простой комментарий, типа, «неплохо!» или более длинный с рассказом, что вам в нём понравилось. В любом случае, человек почувствует, что его ценят, и это определенно улучшит командную работу. А если остальная часть кода не так хороша, автору будет не так обидно. Кроме того, подтверждение качества куска кода побудит автора пытаться создавать больше подобного кода в будущем или выполнять аналогичные действия для других проблем. 7. Будьте скромны и позитивны Неинформативные и грубые комментарии (если у вас не задался день) просто оскорбительны, обескураживают и не несут никакой ценности. Полезно быть дружелюбным в комментариях, уважать время и труд другого человека и предполагать, что он старался изо всех сил при написании кода. Нет абсолютно никакой пользы в хвастовстве, унижении или гневе в код-ревью. 8. Ссылайтесь на ресурсы Если есть известный вам ресурс, который поможет автору кода решить проблему, дайте ссылку на него в своём комментарии. Чаще всего автор оценит комментарий, и может даже станет регулярно использовать этот ресурс в своей работе. Возможно, ещё более важно указать на ресурс из вашей кодовой базы: подобная логика или компонент, который уже был реализован кем-то другим в прошлом, может стать отличным руководством для автора, а он может не знать об этом конкретном разделе кодовой базы, если не работал с ним раньше. 9. Это не вы, это они При чтении кода важно, чтобы вы могли легко его понимать. Если какая-то часть кода кажется непонятной, это не значит, что вы невнимательно прочитали код. Это означает, что код недостаточно ясен. Если у вас есть проблемы с пониманием того, что делает этот фрагмент, другим разработчикам, вероятно, будет трудно понять его в будущем, когда им понадобится изменить эту часть кода. Когда вы обнаружите такой код, не стесняйтесь сообщить об этом. И не просто просите автора объяснить его, попросите переписать его. Если нельзя написать более понятно, хотя бы попросите автора добавить комментарии. 10. Ваше мнение не всегда правильно Обычно существует более одного способа добиться цели. Читая фрагмент кода, вы, вероятно, представите другие способы сделать это и почувствуете желание предложить это в комментарии как лучшее решение. Иногда нужно спросить себя: действительно ли оно лучше или способ автора тоже хорош? Если нет явного преимущества в сложности или удобочитаемости кода, подумайте дважды, прежде чем предлагать переписать его. Перечитайте код и убедитесь, что он соответствует принятым в вашей команде соглашениям, хорошо выполняет свою работу, и сравните его с альтернативным вариантом, чтобы увидеть, как это повлияет на качество кода. Если способ автора приемлем, но вы по-прежнему считаете, что ваш вариант лучше, напишите его как предложение, а не как обязательное изменение. Источник: betterprogramming.pub/10-tips…25aa22c5