Эта статья посвящена рекомендациям по проверке кода. Он объясняет проверку кода с точки зрения здравого смысла. Если вы не хотите читать всю статью, взгляните на оглавление и резюме для быстрого обзора.

Что такое процесс проверки кода?

Проверка кода существует для предотвращения появления ошибок в вашем продукте. Но это гораздо больше. Это включает в себя технические аспекты, технологии, опыт, изменение знаний и чувства.

Если вы являетесь объектом проверки, вы хотите знать, что вы можете сделать, чтобы сделать ваш код более понятным. С другой стороны, если вы рецензент, вы хотите оказать положительное влияние на рецензируемый код.

Код-ревью по сути

Это процесс, целью которого является обеспечение качества доставки. В данном конкретном случае команда проверяет качество кода. Это достигается одним или несколькими разработчиками, изучающими код, написанный их коллегами.

Качество проверки кода трудно измерить. Тем не менее, хороший обзор кода должен быть в состоянии выполнить несколько задач.

  • Найдите потенциальные проблемы/ошибки в коде и предложите способы их решения.
  • Если возможно, улучшите структуру кода (используйте правильные шаблоны проектирования программного обеспечения, рефакторинг и лучшую сегментацию и т. д.)
  • Проверьте, работает ли эта функция на самом деле, пытаясь найти дополнительные тесты (и пограничные случаи), чтобы проверить, будет ли код работать в конкретных ситуациях.

Что такое хороший код-ревью?

Во-первых, хороший обзор кода должен быть дружелюбным, вежливым и направлен на то, чтобы помочь улучшить код и продукт или функции, реализованные в этом коде. Во-вторых, это процесс обмена знаниями и опытом. Именно здесь разработчики получают специальное время для общения, обсуждения проблем, консультаций и попыток обнаружить проблемы до того, как они возникнут.

Хороший обзор кода — это мероприятие, на котором разработчики:

  • проверить качество кода и убедиться, что оно соответствует стандартам компании
  • поделиться своим опытом и опасениями, задать вопросы о возможных последствиях новых изменений кода
  • решать проблемы, сравнивать подходы к кодированию и, самое главное, делиться знаниями
  • строить команду, доверять и уважать друг друга
  • учиться на своих ошибках и получать благонамеренные советы о том, как стать лучше

Что еще более важно, хороший обзор кода не является или, по крайней мере, не должен быть местом, где кто-либо пытается продемонстрировать какое-либо доминирование или совершает какие-либо злонамеренные действия. Это консультация, неписаное соглашение между разработчиками помогать друг другу путем перепроверки того, что было сделано.

Правила здравого смысла и проверки код-ревью

Прежде чем приступить к обзору кода, мы должны принять во внимание несколько важных неприглядных истин.

Планирование обзоров важно при описании задач

Планирование билетов должно включать время, необходимое для надлежащего рассмотрения. Команда должна знать о том, что называется определением готовности. Это список вещей, которые должны быть выполнены, прежде чем билет будет считаться завершенным.

Задачи проверки должны быть частью DOD, и время проверки должно добавляться к этой заявке. Команда должна рассчитать совокупное ожидаемое время для этой заявки. Если 3 разработчика тратят 2 часа, это фактически 6 часов на проверку кода, что составляет 1 человеко-день спринта.

Выбор правильного рецензента или нескольких из них

Первоначальные разработчики должны протестировать проверенный код, прежде чем приглашать других для его проверки. Это важно, потому что это сэкономит всем время. Разработчики всегда будут делать ошибки. Вопрос только в том, когда команда обнаружит эти ошибки.

Код-ревью и менеджмент

Менеджеры не всегда будут иметь представление о времени, необходимом для проведения надлежащей проверки. Разработчики и рецензенты должны сообщить об этом должным образом. Другие члены команды не всегда будут понимать длинные или сложные обзоры.

Люди совершают ошибки, и это совершенно нормально. Ошибки могут появляться в коде даже после тщательной проверки.

Кроме того, мы понимаем, что разные отзывы могут иметь разный вес. Например, некоторые обзоры будут легкими, а некоторые — сложными.

Давайте попробуем сгруппировать эти проверки кода по категориям, чтобы мы могли установить лучшие практики проверки кода.

Стоит ли проверять код?

Да, они.

Действительно, не сомневайтесь, они есть.

Да, проверка кода того стоит. Я на мизинце клянусь.

Хорошо, теперь, когда мы это установили, давайте уточним, почему проверки кода того стоят.

Недостатки код-ревью

Проверка кода требует времени, иногда очень много времени. Многие разработчики читают код, тратят на него время и сосредотачиваются на нем. Менеджмент иногда не понимает, почему эти инвестиции важны.

Иногда проверки кода могут блокировать разработку. Типичный пример — когда одна функция не завершена, потому что во время проверки кода обнаружено что-то сложное. Это блокирует другие функции и т. д. Однако это может указывать на то, что планирование было выполнено ненадлежащим образом.

Разные люди проводят код-ревью с разной мотивацией, настроением и качеством. Мы не все равны и не должны быть такими. Способный менеджер или руководитель группы должен знать, как использовать свою команду и построить процесс проверки кода, чтобы сосредоточиться на сильных сторонах команды, а не на слабых сторонах.

Плюсы код-ревью

Обзоры кода улучшают качество кода, сокращают будущий технический долг и улучшают общее качество программного обеспечения. Кроме того, они как бы строят команду, люди общаются, делятся мнениями, опасениями, страхами, советами и верой.

Без проверки кода было бы меньше качества, структуры и командной работы. Даже экономии времени не будет, потому что время, сэкономленное на проверке кода, уже потеряно и зарезервировано для исправления проблем и сортировки наших упущенных проблем.

Проверка кода может занять некоторое время

Обзоры не будут происходить за минуту, нужно время, чтобы сделать это правильно. Команда должна планировать надлежащее время в зависимости от сложности проверки.

Категории обзоров кода

Раннее определение типа отзыва чрезвычайно важно, потому что это дает нам информацию о том, как с ним обращаться. Кроме того, мы должны иметь возможность сравнить наши возможности, чтобы правильно изучить предоставленный код.

Наконец, если обзор слишком сложен, мы можем решить пригласить другого рецензента или даже попросить нас получить дополнительное образование по техническим темам из этого обзора.

Проверка кода также называется запросом на вытягивание. В этой статье я использую оба термина в зависимости от источников, на которые ссылаюсь.

Классификация по срочности

Бен Балтер, старший менеджер по управлению продуктами в GitHub, написал фантастический пост о Шести типах запросов на вытягивание, которые вы видите на GitHub. Этот пост классифицирует запросы на вытягивание как:

  • Просто голова вверх
  • Санитарная проверка
  • Незавершенное производство (НЗП)
  • Ранняя обратная связь
  • Построчный обзор
  • Пулл-реквест на пулл-реквест

Кроме того, Бен описал, как работает каждый из этих типов и когда его использовать. Например, «просто на заметку» — это простой (однострочный) запрос на включение, автору которого не требуется проверка.

С другой стороны, построчный — это запрос на вытягивание, который используется, когда продукт готов к отправке.

Нельзя отрицать, что сопряжение — это весьма ощутимые издержки для руководства: «Два разработчика на одной рабочей станции? Ни за что! Мы уже платим им целое состояние!» — Пол Блэр,
Незамеченные затраты на проверку кода с помощью запроса на вытягивание

Классификация по размеру и узнаваемости

Во-первых, когда мы исследуем новый запрос на включение, нам нужно проверить количество измененных строк.

Если в запросе на вытягивание более 500 строк, автору этого запроса следует рассмотреть возможность разделения его на несколько частей или найти способ принять участие в процессе проверки кода.

Кроме того, рецензенты должны проверять, выполняются ли тесты для больших запросов на вытягивание.

В противном случае рецензент может найти критическую проблему в середине обзора, и тогда все вернется к началу.

Классификация по воздействию

Есть два способа оценить влияние запроса на извлечение:

  • Какие позитивные и фантастические вещи произойдут, когда мы запустим эту новую классную функцию?
  • Что за хрень поразит фанатов, если и когда что-то пойдет не так с этой классной новой функцией?

Второй — важный.

При измерении влияния запроса на включение команда должна учитывать несколько моментов:

  1. Может ли быть какое-либо повреждение данных?
  2. Сможем ли мы исправить проблемы, если они возникнут?
  3. Сколько пользователей может быть затронуто этим?
  4. Какие политики могут быть скомпрометированы этим? (Общий регламент ЕС по защите данных, т.е.)
  5. Связана ли эта функция с SLA (соглашением об уровне обслуживания)?

Кого должна волновать сложность кода?

Но подождите, должен ли разработчик или рецензент действительно беспокоиться об этих элементах во время проверки кода?

No.

Потому что эти вещи должны были быть определены при создании и планировании заявки. Например, на этапе планирования спринта или даже раньше, во время встреч между владельцем продукта и руководством.

Тем не менее, разработчики не должны закрывать глаза, если заметят какую-либо из упомянутых проблем.

Каковы лучшие практики проверки кода?

Контрольный список рекомендаций по обзору кода:

  • Будьте дружелюбны и вежливы
  • Создайте тестовые примеры для всех вновь введенных или измененных частей кода.
  • Сделать проверку синтаксических ошибок
  • Следите за последними практиками кодирования
  • Обратите внимание на шаблоны проектирования программного обеспечения
  • Учитывайте устаревший код и влияние на устаревшие функции

Будьте дружелюбны и вежливы

Я не могу подчеркнуть это достаточно.

Важно быть дружелюбным, профессиональным и вежливым в процессе проверки кода. Чем крупнее компания, тем важнее профессиональное общение.

Неважно, являетесь ли вы человеком, который рецензирует, или тем, кого рецензируют. Сохраняйте непредвзятость, принимайте любые комментарии с достоинством и изяществом. Всегда думайте о том, что вы можете улучшить и что может принести пользу другим.

Не пытайтесь быть ироничным или злым. Если какой-то комментарий важен, четко укажите это. С другой стороны, если что-то является только вашим мнением и оно не содержит объективных улучшений, укажите и это.

Тестовые случаи

Выполните все доступные тесты для функции, которую вы просматриваете.

Подумайте о ручных (быстрых тестах), которые можно выполнить. Например, если функция изменяет функцию подключения к базе данных, просто попробуйте подключиться к базе данных. Если ваша функция изменяет компонент BasicController для API, просто попробуйте выполнить пару разных вызовов API.

Я уже писал о правилах чистого кода и о том, как улучшить качество вашего кода. Благодаря улучшению качества вашего кода в целом ваши навыки улучшатся и как рецензента, и как рецензента.

Синтаксические ошибки

Разные разработчики используют разные редакторы кода. В некоторых компаниях есть политика на этот счет, а в некоторых нет.

Поэтому ожидается, что некоторые синтаксические ошибки могут перейти в запрос на вытягивание.

Что это значит?

Не проверяйте пул-реквесты только через интерфейс пулл-реквестов (т. е. Bitbucket или gitlabs). Вы также можете проверить эти ветки и изучить их в своем доверенном редакторе.

Практики кодирования

У большинства компаний есть документ со стандартами кодирования или лучшими практиками.

Если такой документ существует, запрос на вытягивание должен включать сравнение последнего кода с этими рекомендациями.

Если такого документа нет, вот несколько быстрых вещей, которые нужно проверить:

  • согласованность в именах переменных
  • правильные блоки комментариев к новым функциям
  • разделение интересов
  • код не должен содержать никаких конфиденциальных данных (т.е. токенов доступа)
  • ваш код не должен содержать никаких демо-данных (кроме как внутри тестов или там, где это действительно необходимо)
  • код должен быть чистым

Шаблоны проектирования программного обеспечения

В зависимости от запроса на вытягивание и типа изменения могут применяться некоторые шаблоны проектирования программного обеспечения.

Кроме того, если некоторые шаблоны проектирования уже присутствуют в архитектуре кода, их следует применить.

Например, добавление новой функции во все унаследованные классы абстрактного класса не имеет смысла. Кроме того, наличие готового шаблона стратегии и отсутствие создания новой стратегии для какой-либо конфигурации также является неправильным использованием этого шаблона проектирования.

Унаследованные аспекты

Ваше программное обеспечение всегда будет иметь устаревшее программное обеспечение.
Это означает, что ваши запросы на вытягивание каким-то образом повлияют на это программное обеспечение.
Поэтому вам нужно справиться с этим. 🙂

Я уже писал о правилах чистого кода и о том, как улучшить качество вашего кода. Благодаря улучшению качества вашего кода в целом ваши навыки улучшатся и как рецензента, и как рецензента.

Резюме

Обзор кода — чрезвычайно важная часть всего процесса разработки программного обеспечения. Поэтому вся команда должна приложить достаточно усилий, чтобы правильно спланировать необходимое для этого время.

Запросы на вытягивание различаются от случая к случаю, но команды всегда должны знать о последствиях и потенциальных проблемах.

Ошибки случаются с теми, кто работает. Обзор кода — это, по сути, управление рисками, поэтому к нему следует относиться соответствующим образом.

Хороший обзор кода улучшит общее качество кода, но также снизит риск, связанный с новой функцией.