Командное правило может мне не нравиться
Мне не обязательно полюбить общий стиль кода, чтобы его соблюдать. Когда одинаковые вещи написаны одинаково, меньше времени уходит на выяснение, есть ли за различием смысл. Эта польза остаётся, даже если для собственного проекта я выбрал бы другой способ писать код.
У каждого разработчика остаются свои предпочтения. Если по очереди переделывать общий код под них, одно и то же решение придётся обсуждать на каждом ревью. Правила помогают закончить этот спор и вернуться к задаче.
Для меня здесь есть разница между «мне привычнее иначе» и «это мешает работать». В первом случае я могу продолжать писать по принятому правилу. Во втором стоит показать, где оно мешает. Эта разница не всегда видна сразу, особенно когда приходишь в новый проект со своим удачным опытом.
Допустим, по принятому в проекте правилу функцию чтения публикации назвали getPost. Мне привычнее find, и я хочу её переименовать. Прежде чем это делать, посмотрю на остальные функции. Возможно, здесь get означает получение одной записи, а find используется для поиска нескольких. Тогда переименование сотрёт различие, которого я пока не заметил. А возможно, из двух слов когда-то просто выбрали одно и с тех пор используют его последовательно.
Если оба варианта понятны, переход на мой потребует правок, но может ничего не улучшить. Здесь я готов остаться при своём вкусе и писать по общему правилу. Эту готовность соблюдать договорённость мы с Лизой Пак обсуждали в эфире про ревью кода.
Другой случай: по одному названию невозможно понять, возвращает функция запись или список, и это уже приводит к ошибкам. Тогда есть что показать: вот места, где мы неверно поняли результат, а вот названия, которые помогут их различать. Такое предложение можно проверить на коде, не споря о том, какое слово красивее.
Разговор об общем правиле я бы отделил от принятия текущей задачи. Пока правило действует, замечание на ревью вполне может на него опираться. Если решим его поменять, придётся договориться и о переходе: исправляем старый код сразу или меняем при следующей работе с ним. Иначе один уже пишет по-новому, другой ещё проверяет по-старому, и оба уверены, что соблюдают договорённость.
Конечно, обнаруженную ошибку не нужно откладывать до обсуждения правил. Если следование им приводит к неверному или небезопасному поведению, это повод остановиться и разобраться сейчас.
После разговора достаточно короткой записи: как мы теперь пишем и почему изменили прежний подход. Она пригодится и тому, кто не участвовал в обсуждении. Возможно, ему новое правило тоже не понравится. Но ему не придётся угадывать, о чём мы договорились.