Перевод статьи «How to get more comfortable reviewing code».
Одной из моих должностных обязанностей, помимо написания собственного кода, является просмотр чужого. Я стараюсь просматривать побольше кода, но, несмотря на то что это интересно, процедура ревью связана с целым набором сложностей. Я хочу рассказать о своем подходе к этому занятию и о том, что мне помогает делать ревью кода все лучше и лучше.
Это не бином Ньютона, вы тоже можете это делать
Серьезно, это не настолько сложно. Долгое время я считала, что люди, проводящие ревью, знают весь контекст каждого отрывка кода, который они просматривают, так что им, конечно же, все это легко дается. Это редко бывает правдой даже в небольших компаниях, поскольку в каждой системе есть множество изменчивых частей. Никто не знает всего о каждой части системы. Об этом стоит помнить.
Умение делать ревью кода это такой же навык, как и умение писать код: ему можно научиться. Чем больше вы просматриваете чужой код, тем лучше у вас получается это делать. Также просмотр чужого кода помогает вам самому лучше писать код, потому что вы узнаёте, на что надо обращать внимание. Опасения на счет того, что вы далеко не все знаете, не должны вас удерживать от проведения ревью.
Будьте готовы совершать ошибки
Ошибки будут. Всегда будет что-то, что ускользнет от внимания, потому что код пишут люди и проверяют его тоже люди, и все мы можем допускать ошибки. Это нормально. Но то, что вы не можете делать что-то в совершенстве, еще не означает, что вообще не нужно за это браться. Если у вас что-то вызывает сомнения, можно попросить кого-то еще взглянуть на код: это нормальная практика. Одна голова хорошо, а две лучше.
Все это косвенным образом связано с «необвиняющей» культурой в компании, при наличии которой никто не будет вас травить за то, что вы что-то не то сделали в продакшене. Главной целью должно быть выявление и исправление проблемы, а не поиск виновных (написавших код с ошибками или пропустивших эти ошибки при ревью). В подобной культуре есть простор для совершения ошибок и, что важно, для извлечения уроков из них. Мне посчастливилось работать именно в такой компании.
Не забывайте проявлять хорошее отношение и эмпатию
Недопонимание и недостаток эмпатии у каждой из сторон это обычное дело в процессе ревью. Но в основе этого процесса должно лежать сотрудничество. Поэтому, выступая в роли интервьюера, важно помнить, что вы просматриваете код, а не оцениваете человека, написавшего этот код. И наоборот, когда проверяют ваш код, не нужно воспринимать как личную обиду все замечания ревьюера.
Во многом все это зависит от культуры в вашей команде и компании в целом.
Есть очень простой способ снизить вероятность возникновения трений в ходе ревью:
Как джуниору просматривать код старших разработчиков
При проведении ревью не последнюю роль играет разница в положении сеньоров и джуниоров. Если вы находитесь в самом начале своей карьеры, вас может пугать перспектива просматривать код людей, обладающих куда большим опытом и знанием контекста. Тем не менее, это не должно останавливать вас. Помочь вам могут следующие подходы:
- Просмотр ревью существующих пул-реквестов. Таким образом можно узнать, на что обращают внимание другие люди при просмотре кода. Также вы увидите, каким образом ревьюеры высказывают свою точку зрения, и как это воспринимается автором кода (последнее не менее важно, чем первое).
- Работа в паре с другим инженером или автором (при просмотре более сложного кода). Это позволит вам задавать вопросы в режиме реального времени и получать больше контекста.
При необходимости обращайтесь за разъяснениями
Спрашивать о контексте совершенно нормально. Поначалу, когда вы еще новичок в команде и/или в сфере деятельности, вам может быть страшновато, ведь кажется, что все вокруг знают намного больше, чем вы. Но если вы не можете в чем-то разобраться, хотя уже просмотрели все источники, будет вполне естественно попросить объяснить вам этот момент.
Приведу пример. На прошлой неделе меня попросили сделать ревью маленького пул-реквеста для сервиса, которым я никогда не пользовалась и с которым совершенно не была знакома. Моим первым побуждением было попросить кого-то из команды ввести меня в курс дела. Но я решила отнестись к этому как к возможности научиться чему-то новому и попыталась самостоятельно разобраться в предлагаемых изменениях.
После просмотра кода оказалось, что, хотя в целом пул-реквест мне был понятен, кое-что понятным не было. Поэтому я набралась храбрости и, признавшись, что этот сервис мне не знаком, обратилась к автору кода за разъяснениями. И он был более чем счастлив мне помочь! После этого я смогла подтвердить вносимые в код изменения, но были также и другие результаты:
- Приобретя этот позитивный опыт, я стала смелее обращаться за разъяснениями.
- Я лучше разобралась в этом сервисе и теперь мне будет легче делать другие ревью связанного с ним кода.
- Мы определили, как можно улучшить документацию этого функционала, чтобы другим людям было легче во всем этом разобраться.
Сплошная польза, с какой стороны ни глянь!
Когда я стала воспринимать процесс ревью как еще один навык, который можно приобрести и оттачивать со временем, я стала гораздо увереннее просматривать чужой код. Теперь это не так страшно, и я предвкушаю все новые ревью.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]