Фитнес-функции - всё. Мне посчастливилось в нескольких компаниях успешно запустить их использование, однако концепция не получила развития и ее прижилась. При этом я считаю фитнес-функции крайне перспективными, но их следует переосмыслить. Решаемая задача остается столь же важной, как и ранее - объективно измерить близость решения к поставленной цели. Напомню официальное определение: Архитектурная фитнес-функция - это любой механизм, который обеспечивает объективную оценку целостности некоторой архитектурной характеристики или комбинации характеристик Появились они как ответ на несколько новых вызовов: ▪️Микросервисы - архитектура стала частично эмерджентным свойством динамической распределенной системы ▪️DevOps - частые релизы (сотни в день) стали невозможным ручной контроль ▪️Кризис техдолга - его накопилось слишком много и нужны были средства автоматизированного контроля его не-накопления ▪️Agile - бизнес требовал скорости, нужны были механизмы контроля качества И вроде бы все эти проблемы на уровне архитектуры они решают, но… ▪️Многие арх. характеристики качественные, а тесты требуют количественных оценок (попробуйте измерить модифицируемость числом, - нужны прокси-метрики, а они нередко расходятся с реальностью) ▪️Так и не появились собственные инструменты. Нужна была сборная солянка из archunit, sonarqube, k6, chaos monkey, bash-скриптов… это серьезный такой порог входа и зоопарк ▪️Отложенная ценность, - архитектура работает с будущим, а фичи нужны сегодня, сегодня проблем нет, пилим фичи, а не непонятные тесты на непонятную архитектуру ▪️Плохо написанные тесты становятся хрупкими и падают, когда все в порядке Даже этого уже хватает, чтобы заблокировать широкое распространение хорошей идеи. Зато уже есть концепции, развивающие идеи фитнес-функций на современный лад (и их важность объективно возрастает).