Проверка кода — неотъемлемая часть создания высококачественного программного обеспечения.

Одна из вещей, которая меня разочаровала, когда я несколько лет назад просматривал код коллег на работе, — это отношение. При обзоре кода, проводимом с несколькими людьми, если один из них говорит эмоционально, человек, получающий обзор, скорее всего, устанет и расстроится. Как бы не ревизовали код, чтобы сделать софт лучше, но кому понравится, если они услышат садистские слова, когда сделают все, что в их силах?

Итак, я собираюсь обобщить 5 вещей, которые, я думаю, были бы хороши, если бы мы знали друг друга.

1. Избегайте агрессивных вопросов

"Почему ты так написал?"

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

"Как насчет этого?"

Давайте начнем говорить так. Тем не менее, мы должны дать понять, что это не личный вкус, дав надлежащее объяснение или причину.

2. Сначала слушайте, а потом говорите

Если рецензент продолжает делать комментарии, пока он/она объясняет код и намерения, поток будет постоянно прерываться. И устают не только те, кто получает код-ревью, но и те, кто смотрит код-ревью. Делать заметки или запоминать, а не сразу обсуждать улучшения или вопросы по коду, гораздо эффективнее избегать эмоциональных комментариев. Потому что заставляет задуматься.

В этот момент человеку, написавшему код, понадобится хитрость, чтобы правильно его отрезать, чтобы он не занимал слишком много времени, как в случае с файлом класса или подразделением малого бизнеса.

3. Немедленно хвалите и поощряйте

"Я думаю, что этот код очень хорош".

"Глядя на код, который вы написали, вам, должно быть, было нелегко..."

Что еще нужно сказать?

4. Избегайте ненужных аргументов

Нет худшего обзора кода, чем обсуждение «Объявление переменных в нескольких строках по сравнению с объявлением переменных в нескольких строках». Объявление переменных рядом с запятыми». Конечно, это не было главной задачей код-ревью, но давайте уважать чужие вкусы. Тем не менее, если вас это беспокоит, определение соглашений о коде после получения согласия большинства может быть хорошим способом избежать ненужных споров.

5. Укажите направление для хорошего кода, но не форсируйте его

"Вы должны изменить эту строку следующим образом".

Является ли это отраслевым стандартом? Тогда примите это. Это основное правило в вашей команде? Примите и это. Есть ли потенциальная возможность ошибки, если вы не измените его? Исправьте это немедленно.

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

Первоначально опубликовано на https://dev.to 25 января 2022 г.