Я недавно прочитал это в Твиттере :
К сожалению, кажется, что проверка кода — это практика, которая чужда многим студентам, фрилансерам и агентствам. [Перевод]
Очевидно, не всем очевидно, что обзоры кода действительно полезны. Называйте меня наивным, но я действительно думал, что этот процесс используется во всех IT-компаниях. Видимо, я был не прав, и это меня пугает.
В этой статье я хотел бы поделиться своими мыслями об обзорах кода, почему я считаю, что они являются важной частью процесса доставки кода, и как с ними начать. Если вы не делаете обзоры кода, или если вы чувствуете, что могли бы сделать лучше, я надеюсь, что эта статья поможет!
Что такое проверка кода?
Мы живем в эпоху Википедии, поэтому позвольте мне процитировать определение, приведенное в обзоре Кодекса :
Проверка кода — это систематическая проверка (иногда называемая экспертной проверкой) исходного кода компьютера. Он предназначен для выявления ошибок, которые упускаются на начальном этапе разработки, что повышает общее качество программного обеспечения. Обзоры выполняются в различных формах, таких как парное программирование, неофициальные прохождения и формальные проверки.
Проверка кода, как следует из названия, представляет собой процесс проверки некоторого кода, чтобы убедиться, что он работает, и для его улучшения, где это возможно.
Способы сделать обзор кода
Как отмечает определение в Википедии, существуют различные способы проверки кода. Однако в мире, где на GitHub живет так много кода, проверка кода часто идет рука об руку с тем, что мы называем «запросом извлечения».
Запрос на извлечение — это запрос на внесение изменений в репозиторий кода с использованием распределенной системы контроля версий (Git, SVN, Mercurial и т. Д.). Он работает, «вытягивая» исходный код, применяя изменения, а затем отправляя запрос на объединение изменений в.
GitHub сделал этот процесс особенно простым и эффективным благодаря дружественному пользовательскому интерфейсу, абстрагирующему большинство требований к знаниям Git.
Зачем пересматривать кодовые вопросы?
Итак, почему рецензирование кода имеет значение? В конце концов, мы все здесь компетентны. Конечно, мы можем отправить код без того, чтобы кто-то метафорически стоял у нас за плечом, наблюдая за всем, что мы делаем.
В теории да. Но на практике есть много причин, почему помогает установленный процесс проверки кода. Давайте посмотрим на некоторые из них.
Ограничивает риски
Это, наверное, самая важная причина из всех. Наличие у кого-то двойной проверки нашей работы никогда не повредит, и ограничивает риск незамеченных ошибок. Даже хорошие разработчики иногда получают туннельное зрение.
Всегда хорошо убедиться, что ничего не забыто. Например, правильная навигация с помощью клавиатуры, доступность чтения с экрана, гибкость для интернационализации и дружественное поведение, не относящееся к JavaScript, часто забываются в мире интерфейса, и это только четыре.
Это значительно улучшает качество кода
Давайте проясним что-то: речь идет не о стандартах, а о кодировании (по крайней мере, не только). Речь идет о том, чтобы сделать код более эффективным.
В команде, в которой у каждого свой собственный опыт и сильные стороны, просьба об улучшениях (потому что в этом суть) всегда хорошая идея. Кто-то может предложить более разумное решение, более подходящий шаблон проектирования, способ уменьшить сложность или повысить производительность.
Это делает всех лучше
Объединив усилия, каждый может учиться и стать лучше. Податель кода, вероятно, получит отзыв о своей работе, информируя их о возможных проблемах и областях для улучшения. Обозреватели могут хорошо изучать новые вещи, читая код и находя решения, применимые к их собственной работе.
Это помогает быть знакомым с проектом
Когда команда работает над проектом, маловероятно, что каждый разработчик работает над каждой частью приложения. Иногда разработчик будет работать над одной большой частью некоторое время, в то время как другой работает над чем-то другим полностью.
Проверка кода помогает людям ознакомиться с кодом, который они не написали, но могут попросить его сохранить в будущем. Он способствует знанию кодовой базы всей команды и, вероятно, ускорит будущее развитие.
Как сделать это правильно
Опять же, наличие установленного процесса проверки кода является чрезвычайно полезным и важным. Каждая команда, производящая код, должна иметь некоторый обзор кода, так или иначе.
При этом выполнение значимых и полезных проверок кода не всегда так просто, как может показаться. Не беспокойтесь, это не значит, что вас укусят, если все сделано плохо. Это просто не будет полезно, и может показаться пустой тратой времени.
Недавно на моем рабочем месте была проведена ретроспектива процесса проверки кода. Мы знали, что некоторые вещи были не правы, когда поняли, что только 3 из 12 разработчиков занимались обзорами кода.
Чтобы помочь нам изменить это, один из наших Scrum Masters организовал ретроспективу, чтобы определить, где есть место для улучшения, и как мы можем это осуществить.
Планирование наперед
Наиболее частым аргументом в пользу отсутствия участия в проверках кода было то, что на это требуется время — время, которое люди не могут или не хотят брать.
Я должен сказать, что сам не совсем понимаю этот аргумент, потому что представляю его так: если коллега приходит ко мне напрямую и просит меня чем-то помочь, я не собираюсь говорить: «У меня нет времени , не интересно ». Я найду время, чтобы помочь. Может быть, не сейчас, а через час, но я, очевидно, уделю им время. Почему? Так как
- это то, что значит быть частью команды
- если они хотят мое мнение, то это потому, что они так или иначе его ценят, и поэтому имеет смысл только дать им свое мнение.
«Почему бы вам не принять участие в процессе проверки кода?»
«У меня нет времени».
Для меня запрос на извлечение ничем не отличается от запроса сотрудника. Сказать, что у вас нет времени, время от времени прекрасно, но систематически отказываясь помогать, вы активно вытаскиваете себя из команды. Такое поведение не является ни дружелюбным, ни положительным. Потратьте время, чтобы помочь.
Чтобы позволить разработчикам находить время, мы начали с того, что каждый разработчик будет тратить немного времени (возможно, 30 минут) на просмотр кода каждый день. Больше нет ничего удивительного, когда мы тратим полчаса на большой обзор кода: это часть дня.
Мы также попытались значительно сократить объем кода, составляющего запрос на извлечение. Раньше у нас были огромные запросы — тысячи изменений в десятках файлов.
Мы стараемся не делать этого больше. Делая меньшие запросы по запросу, мы облегчаем их анализ, отзывы становятся более актуальными, и разработчики с большей готовностью участвуют в этом процессе. «Корабль маленький и частый».
Предоставление контекста
Вторая самая большая проблема, которую мы обнаружили, заключалась в том, что нам обычно не хватало понимания контекста кода, что необходимо, если вы собираетесь предоставить полезную обратную связь. Когда мы пропускали контекст, мы обычно делали не более чем синтаксический анализ — что, хотя и полезно в некоторой степени, недостаточно. Вы просто становитесь тем, что мы называем «человеческим носителем».
К счастью, решение этой проблемы относительно простое: добавьте описание в запрос на извлечение, чтобы объяснить, какова цель и как ее достичь. Это не обязательно должна быть стена текста; обычно достаточно нескольких строк. Это также помогает добавить ссылку на проблему и / или историю. Лив Мэдсен , одна из наших разработчиков, даже добавляет скриншоты — или скринкасты, когда это уместно — чтобы показать, что она сделала, что удивительно.
На самом деле спрашиваю
Третья проблема, на которую мы указывали, заключалась в том, что мы иногда просто не понимали, что есть что пересмотреть. Посмотрим правде в глаза, мы каждый день наводнены тоннами электронных писем и уведомлений — так много, что может быть трудно отследить. В конце концов, мы всего лишь люди.
Здесь, опять же, решение довольно простое: на самом деле попросите кого-нибудь о пересмотре. Есть много способов сделать это, от гудка в офисе до пинга кого-то в Слэк; каждой команде свое.
Мы создали группы на GitHub на основе нашей деятельности, и при отправке запроса на удаление мы всегда проверяем группу. Члены этой группы получат уведомление и смогут его решить, как только у них будет время. Иногда мы пингуем разработчика (или нескольких) напрямую, когда он более специфичен для чьей-либо работы. Это тоже работает.
Оттуда люди могут проверять код и оставлять комментарии. Мы пытаемся оставить комментарий, даже если нет ничего конкретного для отчета — хотя бы для того, чтобы указать, что код готов к объединению.
Поскольку у нас было несколько запросов на выборку вслепую, независимо от данных комментариев, мы установили строгую политику «отвечай или исправляй все». Получая отзыв, вы либо исправляете его, либо отвечаете, чтобы объяснить, почему это не так. В любом случае вы никогда не оставляете комментарий в ожидании и, конечно же, не объединяете свой запрос на получение с необработанными комментариями.
Завершение дела
Регулярный и эффективный процесс проверки кода важен для поддержания высококачественных стандартов кода, развития команды и обмена знаниями между разработчиками.
Просьба о пересмотре кода не является признаком слабости. Нет ничего смущающего в обращении за помощью, и уж точно не в форме проверки кода. Принимайте все отзывы, предоставленные вам, и предлагайте конструктивные (в идеале положительные) комментарии людям, отправляющим запросы.
Найдите то, что работает для вас. Проверка кода должна быть большой частью процесса доставки кода, поэтому вы должны адаптировать его для своей команды. Сделайте так, как вы хотите, чтобы это было полезно и позитивно для всех.
Приятного просмотра!