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