Что я хочу узнать на ревью своего кода
На ревью я хочу проверить решения, к которым уже привык и в которых сам перестал замечать спорные места. Для этого нужно понять, что затруднило другого разработчика. Предложенная им правка может оказаться неудачной, но это ещё не повод отмахнуться от самого замечания.
У другого разработчика свой опыт и свои основания для совета. Пока я их не выяснил, легко начать защищать код от претензии, которой мне никто не предъявлял.
Допустим, на ревью предлагают разделить функцию, которая готовит публикацию для блога. Она проверяет поля, собирает текст и сохраняет результат. Можно сразу возразить, что новые функции будут вызываться только в одном месте, а переходить между ними неудобно. Возможно, это хороший аргумент. Но пока он отвечает на моё предположение о причине замечания. Саму причину я ещё не выяснил.
Может мешать название: по нему непонятно, почему функция ещё и сохраняет запись. А может, чтобы проверить подготовку текста, приходится заодно обращаться к базе. В первом случае, возможно, достаточно более точного имени. Во втором смена названия ничего не исправит: подготовка текста и сохранение всё ещё связаны, хотя проверить хотелось только подготовку.
Мне полезнее попросить показать место, которое трудно прочитать или изменить. На каких данных поведение окажется неправильным? Что придётся сделать, если добавится ещё один способ публикации? Для этих вопросов не нужно заранее соглашаться с правкой. Они помогают понять, какую проблему мы пытаемся решить.
После объяснения может выясниться, что при проверке не учли ограничение задачи. Например, часть поведения задаёт внешний протокол и поменять её вместе с функцией не получится. Такое ограничение стоит описать рядом с кодом, иначе следующий читатель задаст тот же вопрос. Бывает и обратное: я перенёс ограничение из похожей задачи, хотя здесь его нет. Ради такого открытия и имеет смысл задержаться в разговоре.
Сам совет тоже можно проверить. Уверенный тон не доказывает, что предложенный вариант лучше. Утверждение о работе языка можно сверить со спецификацией или проверить на небольшом примере. Если речь о читаемости, полезно посмотреть оба варианта целиком. Мне нужно понимать основание правки: завтра похожее решение придётся принять самому, уже без этого замечания.
В разговоре с Лизой Пак о ревью кода я говорил о том, что ревью помогает узнать другие точки зрения. Опыт помогает замечать чужие ошибки, но от собственной невнимательности не защищает. Особенно когда долго работаешь с одним участком кода.
Мне подходит ревью, после которого я могу объяснить, почему изменил решение или почему мы оставили его прежним. Замечание может не привести к правке, но помочь проверить сомнение и записать важное ограничение. Для меня это тоже полезный результат.