Agaltsov Anton | TeamLead-блог

🔧 RDD — Risk Driven Development: сколько архитектуры достаточно, решает реестр рисков Risk Driven Development — подход Джорджа Фэрбенкса (книга «Just Enough Software Architecture», 2010), при котором объём и глубина архитектурных усилий определяются рисками проекта. Вместо вопроса «какой должна быть архитектура?» RDD ставит операциональный вопрос «сколько архитектуры достаточно?» — и отвечает: ровно столько, сколько нужно, чтобы идентифицированные риски были сняты или снижены до приемлемого уровня. Подход вырос из наблюдения о двух симметричных провалах индустрии. Первый — архитектура «на всякий случай»: полные модели и обобщения, значительная часть которых никогда не понадобится, но требует сопровождения. Второй — «архитектуры нет вообще»: структурные решения принимаются имплицитно и задним числом, а результат получает имя big ball of mud. Риск становится измерителем дозировки проектирования: где вероятность и цена неудачи высоки — проектировать глубоко и проверять, где риска нет — сознательно не тратить усилия. Архитектурные техники — инкапсуляция, слоистость, инверсия зависимостей, паттерны — трактуются как инструменты снижения конкретных рисков и применяются тогда, когда закрывают риск из реестра. «Применять все техники всегда» так же ошибочно, как «не применять никаких». Исторический первоисточник логики — спиральная модель Боэма, где каждым витком разработки управляет список наибольших оставшихся рисков. 💡 Практический минимум, который стоит забрать даже без полного внедрения, — привычка отвечать на вопрос «какой риск закрывает эта архитектура?» до того, как платить за неё временем команды. Не путать с Readme Driven Development — то же сокращение RDD, но движущая сила там документация, а не риски. 🔗 https://agaltsovav.ru/docs/development-managment/rdd-risk-driven-development/

📊 Бенчмарки LLM: как читать цифры, которым все верят «90% на MMLU», «Elo 1350 в Chatbot Arena» — за каждой такой цифрой стоит конкретная процедура прогона. Бенчмарк — это экзамен с фиксированными билетами, метрика на своих данных — способ измерить модель в вашей задаче. Первое даёт ориентацию на рынке и отсев кандидатов, второе — основу для финального выбора. Цифра бенчмарка имеет смысл только в контексте. У MMLU уровень случайного угадывания — 25%, потолок человека — около 90%. Разница между моделями в 1–2 пункта — статистический шум, а не превосходство. А когда фронтальные модели выходят на плато 85–88%, как на SWE-bench Verified, бенчмарк теряет различительную способность. ⚠️ Главные риски — загрязнение обучающих данных (модель не решает задачи, а вспоминает их) и натаскивание под формат: одна и та же модель может показать 40% в zero-shot и 80% в few-shot. Заявленные вендорами цифры — наименее надёжный источник. Больше всего доверия — независимым и слепым площадкам: Stanford HELM, Elo-рейтинг Chatbot Arena. 🔗 https://agaltsovav.ru/docs/ai/llm-benchmarks/

🏗️ Clean Architecture: правило зависимостей сильнее любой диаграммы Clean Architecture Роберта Мартина разделяет систему на концентрические слои: в центре — бизнес-логика (сущности и сценарии использования), на периферии — фреймворки, интерфейс и базы данных, объявлённые «деталями». Единственное жёсткое правило стиля: все зависимости исходного кода направлены строго внутрь, к домену. Это правило превращает архитектуру из набора красивых схем в проверяемое свойство кодовой базы: направление зависимостей измеряется статическим анализом, и нарушение можно ломать сборкой. Внутренние слои не знают имён внешних классов — поэтому домен не меняется вместе со сменой фреймворка, UI или СУБД. 💡 Мартин не претендовал на новизну идеи: гексагональная архитектура Коубёрна, Onion Палермо и BCE Якобсона — вариации одной темы. Вклад Clean Architecture — единый словарь из четырёх колец (Entities → Use Cases → Interface Adapters → Frameworks & Drivers) и связь с принципами SOLID, применёнными не к классу, а к системе целиком. Практическая граница применимости: для чистого CRUD без бизнес-правил интерактор-транзит лишь добавляет слой без содержания. Слои следуют за сложностью, а не наоборот. 🔗 https://agaltsovav.ru/docs/architecture/clean-architecture/