Fitness-функции архитектуры

Fitness-функции архитектуры (Ford/Parsons/Kua, 'Building Evolutionary Architectures') представляют собой исполняемые тесты, проверяющие архитектурные свойства системы. Они превращают архитектуру из абстрактного 'задокументированного намерения' в 'обеспеченное поведение', подобно тому, как unit-тесты проверяют функциональность кода. Fitness-функции играют важную роль в поддержании целостности архитектуры, особенно при работе нескольких команд над одной кодовой базой.

Как это работает

Для внедрения fitness-функций необходимо сначала идентифицировать архитектурные свойства, которые важны для системы. Обычно это от 5 до 15 инвариантов, таких как правила импорта модулей, ограничения на задержку ответа или требования к структуре UI-компонентов. Каждый из этих инвариантов выражается в виде автоматической проверки, которую можно выполнить с помощью специализированных инструментов и библиотек.

Например, для проверки импорта модулей можно использовать инструменты, такие как ArchUnit для Java, TypeScript с кастомными правилами линтера или Python's import-linter. Проверка задержки ответа может быть реализована через нагрузочные тесты, а проверка структуры UI-компонентов — через анализ графа зависимостей. Эти проверки добавляются в систему непрерывной интеграции (CI), чтобы каждый pull request (PR) проходил через автоматические проверки архитектурных свойств.

Когда применять

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

Типичные ошибки

Нет автоматизации

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

Over-strict правила

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

Позднее добавление

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