При выпуске патчей иногда нужно чуть переписать тест, а при минорных версиях — всегда написать новые. Перед стартом ревьюер должен оценить объем MR и определить, сможет ли его проверить на «одном дыхании» — не теряя концентрации. Если объем MR слишком большой, советуем разбить его на части поменьше. Чем объемнее решение, тем ниже эффективность проверки. Некоторые данные, такие как сгенерированный код или гигантская структура данных, можно читать по диагонали, но никогда не пролистывайте просто так код, написанный человеком. Конечно, что-то должно быть изучено пристальнее — вы должны сами провести для себя грань что именно и насколько глубоко.
Ревью — это процесс проверки текста, кода или другого артефакта. Цель проверки — выявить ошибки или неточности и указать на них автору. Обычно ревью проводят в несколько этапов, так как рецензентами https://deveducation.com/ должны быть люди разных направлений. В случае с «Фантазией» первым проверяющим может выступить наш коллега. Его задача примерить на себя роль читателя, для которого был написан документ.
Как происходит
Проверка кода — это акт сознательной проверки фрагментов кода на наличие ошибок и багов. Когда разработчик-человек проводит проверку кода, важно, чтобы человек, который проверяет и тестирует код, не был тем же человеком, который изначально написал код. Поэтому вас, как разработчика, могут попросить просмотреть коды, написанные вашими коллегами. Вот почему важно, чтобы вы знали, как работает процесс проверки кода. Процесс проверки кода — это возможность роста как для автора кода, так и для человека, которого попросили его проверить.
На практике, как правило, таких дедлайнов нет, поэтому пул-реквесты могут висеть неделями. Ещё мы заранее примерно знаем, сколько кода напишет студент и какие файлы в нём будут использованы. На практике ревьюеру может прилететь как сто строк кода, так и тысяча. В Яндексе нет заказной разработки, но часто приходится объяснять такие вещи менеджерам. И не только про код-ревью, но и, например, про автотесты.
На что обращать внимание в ревью
При обзоре чужого решения велик соблазн давать мелкие советы. Это называется эффектом велосипедного сарая (bikeshedding). Он создаётся, потому что для обсуждения сложных, глубоких вопросов нужно сильно погружаться в контекст внесённых изменений, а это трудно. Намного проще написать десяток комментариев о забытых точках с запятой и спокойно продолжить заниматься своей задачей. Код-ревью — это область, где особенно ярко проявляются софт-скиллы инженеров.
- Контрольный список проверки кода также поможет вам в этом.
- Когда вы проверяете удобочитаемость кода, вы анализируете, является ли код ясным и лаконичным, а также соблюдаются ли все языковые и проектные соглашения.
- Он создаётся, потому что для обсуждения сложных, глубоких вопросов нужно сильно погружаться в контекст внесённых изменений, а это трудно.
- С другой стороны, когда у вас есть обзор кода от коллеги, вы можете получить ценные отзывы и советы по улучшению.
- Из книги неясно, о какого рода инспекциях идёт речь.
- Каждый оставленный комментарий — это обмен опытом между людьми.
Поэтому на этапе код-ревью разработчики делают так, чтобы им же позднее было проще поддерживать код и ничего не ломалось. Способствует диалогу между автором кода и ревьюером, дает возможность прокачать навыки и узнать что-то новое. Обычный случай, в результате чего код получается слишком сложным, это когда разработчики пишут слишком общий код или добавляют функционал, который сейчас не нужен в системе. Будущие проблемы должны решаться по мере поступления, в тот момент когда они принимают конкретные черты и получают ясные требования.
Некоторые предположения об отсутствии разнообразия в видах ревью
Мы примерно знаем, какой код они будут отсылать, и знаем, какие типичные ошибки могут допустить. Эти ошибки проходят обработку, и на их основе собираются код-сниппеты. Ревьюеры могут брать эти комментарии, использовать их при проверке и адаптировать под себя. Самый распространённый вариант — короткие текстовые комментарии внутри кода. Но на практике это не всегда удобно, поэтому для сложных вещей лучше проводить рабочие встречи. Кроме того, постоянный просмотр кода друг друга увеличивает важную характеристику в разработке — коллективное владение кодом.
Как по мне, это название не совсем удачное, и лучше использовать слово «разбор». Ведь мы не просто код собрались на код посмотреть, а основательно в нём разобраться. В совсем классических источниках вообще используется словосочетание «инспекция кода». Во-вторых, рецензирование это это возможность дополнительного заработка и обмен опытом с разработчиками внутри сообщества. Во-первых, это обучение качественному код-ревью и принципам бережной и развивающей обратной связи. Мы учим правильно структурировать комментарии и излагать свои мысли.
4. Тесты
Если первая попытка приготовления завершится неудачей, то доставку новых ингредиентов придется ждать несколько дней. И пекарю нужно будет заплатить за отработанные часы. Часто код, который решает еще не возникшие проблемы, не пригождается и становится лишним. → Если на проекте пишутся автотесты, решение должно ими покрываться. Если автор решения выходит за рамки принятых стайл гайдов или отклоняется от них, стоит указать ему на это.
Провести хорошее код-ревью сложнее, чем написать хороший код. Откуда вообще пошла эта история с инспекциями кода? Дядюшка Боб Мартин любезно предоставил мне ссылку на то, что можно считать первым документальным свидетельством существования инспекций кода. Майкл Фэган (Michael Fagan) задокументировал информацию о них в своей статье 1976-го года Design and code inspections to reduce errors in program development. В русскоязычной литературе ревью иногда называется «обзором кода».