Качество кода

Качество кода

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

Цикломатическая сложность

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

def charge(user):
  subscription = user.subscriptions.last()
  bank = Bank(user)
  if bank.charge(subscription.cost):
    subscription.prolong()

Внутри функции charge() всего два пути: если получилось снять деньги с пользователя, то подписка продляется, если не получилось — ничего не происходит.

Наверняка во время продления подписки мы уведомляем пользователя и менеджера об успешной операции, автоматически создаём новую подписку в случае, если её ещё нет, обновляем дату следующего продления. В примере выше всё это попрятано по отдельным местам — в методе подписки prolong() или вообще вне функции charge(). Смотрите, что будет, если это не прятать:

def charge(user):
  if user.subscriptions.count():
    subscription = user.subscriptions.last()
    order = Order.objects.create(user=user, subscription=subscription, created=datetime.now())

    response = requests.post('https://bank.api/init', dict(
      amount=subscription.cost * 100,
      order_id=order.id,
    ))
    if response['OK'] is True:
      payment_id = response['payment_id']
      new_response = requests.post('https://bank,api/charge', dict(payment_id=payment_id))

      if new_response['OK'] is False:
        requests.post('htps://api.slack.com', {
          'to': '#money',
          'message': f'Не удалось оплатить подписку пользователя {user}',
        })

      else:
        subscription.due_date = datetime.now() + timedelta(month=1)
        subscription.save()

  else:
    Subscription.objects.create(user=user)
    charge(user)

В этом примере 6 возможных путей. Это уже многовато — алгоритм воспринимается с трудом, если возможных путей в нём больше 4.

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

Процент покрытия тестами

CI (Continous Integration) — процесс непрерывной сборки и проверки программы. Рассмотрим его подробно в следующем совете

Вторая важная метрика — это процент кода, покрытого тестами. Скажем, если ваша программа покрыта на 90% — значит, в процессе прогона тестов в CI вы задействуете 90% из всего написанного кода. Скорее всего, это означает, что 90% вашего кода работает так, как задумал программист. 90% — неплохой уровень покрытия, 80% и ниже — сигнал, что что‑то идёт не так.

CI (Continous Integration) — процесс непрерывной сборки и проверки программы. Рассмотрим его подробно в следующем совете

Сервис Codecov подсвечивает непротестированную строчку

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

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

Время ответа и частота ошибок

Эти метрики показывают не совсем качество кода, а скорее качество работы программного обеспечения в продакшене. Обычно частота ошибок и время ответа растут очень медленно, по мере усложнения программы. Если у вас резко выросла одна из этих метрик — это сигнализирует, что только что в вашу кодовую базу привнесли серьёзное ухудшение.

Экран мониторинга производительности в Datadog: видны графики времени ответа и ошибок

Для снятия этих метрик подходит множество инструментов. Мы в «Гдематериале» используем Datadog в связке с Sentry. Datadog измеряет частоту ошибок и время ответа, а Sentry помогает с расследованием, показывая состояние приложения во время ошибок.

Добавьте свою метрику

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

P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.

Управление проектомВеб‑разработка
Отправить
Поделиться
Запинить

Рекомендуем другие советы