Знакомый код проверяется с точки зрения фич, незнакомый с точки зрения стиля

Очень часто ревью кода кардинально различаются в зависимости от степени знакомства с модулем.

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

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

Это очень дорогие комментарии. Перед тем, как оставить его подумай, стоит ли оно времени потраченного на переключения между ветками, фикс, прогон тестов и повторное ревью? Как правило, ответ — нет, не стоит.

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

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

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

Эти и другие вопросы обсуждаем в канале https://t.me/your_soft_skillzz

и твиттере https://twitter.com/soft_skillzz

Подписывайтесь и рассказывайте друзьям.

МS.