День 2172. #ЗаметкиНаПолях
Функции Пригодности в Архитектуре ПО
Нефункциональные требования важны, но мы часто забываем их проверять. Вы можете измерить их, настроив функции пригодности. Достаточно ли быстра ваша система? Проходит ли она все проверки безопасности? А как насчёт тестируемости, ремонтопригодности и других качеств?

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

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

Будучи связанными с конкретными и измеримыми метриками, функции пригодности предоставляют способ оценки качества и производительности архитектуры, снижая зависимость от субъективных мнений с помощью объективных измерений. Метрика может быть простым числом (например, «максимальное количество запросов в секунду»), процентным значением (например, «процент кода, покрытого тестами») или другими измеримыми значениями.

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

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

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

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

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

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

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

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

Источник: https://www.code4it.dev/architecture-notes/fitness-functions/