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

Нецелевые проверки кода

Я начну с того, что не является обзором кода.

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

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

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

Повысьте уровень проверки кода

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

Уровень 0 - Полностью автоматизированный обзор.

Проверка кода уровня 0 - это скорее метод ограничения, так как в процессе проверки не участвуют люди.

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

Изучите, какие инструменты можно запускать автоматически для ваших языков, и настройте их. Практически всегда стоит потратить время на настройку этих проверок, поскольку выгода является мультипликативной (количество разработчиков) и складывается. Я также рекомендовал бы найти время, чтобы настроить способ запуска этих проверок локально, чтобы каждый разработчик мог проверить, соответствует ли его изменение кода, прежде чем даже отправлять его на проверку кода. Если вы используете git, обратите внимание на структуру pre-commit как на отправную точку.

Рецензент: автоматизация

Цели: скорость, уменьшение трения за счет объединения

Стоимость: ничтожно мала.

Уровень 0.5 - Автоматическая проверка на основе человеческого суждения

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

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

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

Цели: скорость, более эффективное использование экспертов в предметной области

Стоимость: ничтожно мала.

Уровень 1 - Проверка читабельности

Если вы хотите сделать упрощенную версию обзора кода, то это то, что вам нужно. Чистый обзор удобочитаемости дает ответ на простой вопрос. Код читается? Я имею в виду конкретное свойство: очевидно ли, что делает код? Вот два фрагмента кода, которые можно спутать с противоположным.

Вот пример нечитаемого кода:

int Update(vector<User>& users) {
    int sum = 0;
    for (auto &user : users) {
        sum += Calculate(user);
    }
    return sum;
}

Этот фрагмент невозможно прочитать, потому что неясно, что здесь происходит. Что именно мы рассчитываем? Почему функция называется Update, она что-то обновляет? Возможно ,Calculate видоизменяет состояние user?

Вот пример читаемого кода:

float sin_taylor(float x) {
    // Taylor series approximation for sinus function:
    // https://en.wikipedia.org/wiki/Taylor_series#Approximation_error_and_convergence
    assert(x > -1 && x < 1); // only precise for (-1,1)
    return x - (x*x*x)/(3*2) + (x*x*x*x*x)/(5*4*3*2*1) - (x*x*x*x*x*x*x)/(7*6*5*4*3*2);
}

Понятно, что здесь происходит. Дополнительная информация о формуле приведена по ссылке, а код представляет собой просто расширение математической формулы, указанной в Википедии.

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

Рецензент: младшие члены команды.

Цели: скорость, обмен знаниями

Стоимость: небольшая

Уровень 1.5 - Проверка читабельности языка

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

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

Этот обзор должен быть сосредоточен исключительно на правильном использовании языка (или библиотеки и т. Д.) И должен основываться на утвержденных рекомендациях (а не на субъективных предпочтениях).

Рецензент: знаток языка / библиотеки, основанный на установленных правилах.

Цели: уменьшить трение за счет объединения, поделиться знаниями

Стоимость: значительная

Уровень 2 - проверка прав собственности

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

Типичные области внимания в этом обзоре:

  • местные стилистические соображения
  • местные экспертные знания (например, правильное использование внутренних библиотек)
  • бремя обслуживания

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

Рецензент: сопровождающий проекта / библиотеки или старший разработчик.

Цели: скорость, более эффективное использование экспертов в предметной области

Стоимость: значительная

Что выбрать

Представленные уровни построены друг на друге. Так, например, нет смысла проводить проверку уровня 1, если проверка уровня 0 является неполной. Однако необязательно использовать все уровни.

Вот несколько рекомендаций, основанных на вашем проекте:

  • Небольшой проект с открытым исходным кодом: уровень 0 + уровень 2
  • Проект с открытым исходным кодом среднего размера: уровень 0 + уровень 1 + уровень 2
  • Большой проект с открытым исходным кодом: уровень 0 + уровень 0,5 + уровень 1 + уровень 2
  • Командная компания: уровень 0 (+ уровень 0,5) + уровень 1
  • Многокомандная компания: уровень 0 + уровень 0,5 + уровень 1 + уровень 1,5 + уровень 2

Спасибо за чтение

Спасибо, что прочитали эту статью. Вам понравилось?

Также публикую видео на YouTube. у вас есть вопросы? Напишите мне в Twitter или LinkedIn.