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

  • Обзор домена
  • Обзор стиля
  • Обзор производительности

Вы заметите, что это отражает менталитет программирования «заставьте это работать, сделайте это красиво, сделайте это быстро», и это имеет смысл; процесс рецензирования должен отражать процесс кодирования.

Обзор домена

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

  • «Похоже, это не то же самое, что требует документ с требованиями»
  • «Возможно, вам не хватает теста для этого пограничного случая, и я не вижу, чтобы он обрабатывался в коде»
  • «Эта часть по-прежнему обратно совместима с Feature X?»
  • «Эта формула выглядит подозрительно, я думаю, вы могли применить неправильную!»

Обзор стиля

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

  • «Вы не рассматривали возможность использования этого паттерна здесь вместо этого?»
  • «Эта часть должна быть извлечена в отдельный метод»
  • «У нас уже есть абстракция, которая делает все это за вас! Обратитесь к FooClass”
  • «Пожалуйста, дайте более осмысленное имя этому свойству»
  • «Интервалы и разрывы строк отключены!»
  • «Кажется, этот раздел написан в стиле языка А, на языке Б идиоматический способ сделать это примерно так»

Если вы заинтересованы, я также написал больше о написании беглого кода, что также может помочь с обзором стиля!

Обзор производительности

Как следует из названия, мы увеличим производительность в этом разделе. Мы будем анализировать масштабируемость и сложность кода, поведение в стрессовых условиях, задержку и влияние на показатели сервера/устройства (например, использование памяти, загрузку ЦП). Подобные комментарии относятся к этому разделу:

  • «Похоже, эта карта будет увеличиваться в размере, через некоторое время у нас могут возникнуть проблемы с памятью»
  • «Вы не рассматривали возможность выполнения этих операций асинхронно?»
  • «Это О(н!)!!!»

Пример

Допустим, у нас есть это гипотетическое требование и этот код отправлен на проверку:

Учитывая массив int и int k, найдите количество пар, сумма которых равна k.

int count(
   int[] arr, 
   float k
) { 
    int count = 0;
    for (int i = 0; i < arr.length; i++) 
        for (int j = i + 1; j < arr.length; i++) 
            if ((arr[i] + arr[j]) == k) 
                count++; 
    return count;
}

Вот комментарии, которые мы могли бы дать во время каждого прохода обзора:

Шаг 1: проверка домена

  • «В требовании указано, что k является int, но здесь использовалось float»
  • «Вложенный цикл должен увеличивать j вместо i»
  • «Добавьте модульные тесты!»

Шаг 2: Обзор стиля

  • «Имя функции count не имеет особого смысла, возможно, назовите его countPairsSummingToK»
  • «Соглашение здесь состоит в том, чтобы всегда добавлять фигурные скобки {} к for и if»

Шаг 3: Обзор производительности

Почему хлопот?

Большинство из нас проходят через комбинацию всех трех типов одновременно при чтении представленного кода, но если мы разобьем его и проверим за 3 прохода, мы получим следующие преимущества:

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

использованная литература

Я также пишу о комнатах TryHackMe (Pen Testing)!

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

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