Agaltsov Anton | TeamLead-блог

🧪 TDD: тесты пишутся раньше кода — и управляют дизайном Test Driven Development — методология Кента Бека, в которой для каждой единицы функциональности сначала пишется тест, и лишь затем код, делающий этот тест зелёным. Тест здесь не артефакт постфактум, а первичный драйвер дизайна: формулируя проверку до реализации, разработчик вынужден думать о том, как новый код будет вызываться, — а значит, о его интерфейсе и тестируемости. Сердце метода — цикл Red → Green → Refactor. Сначала тест, который обязательно падает. Затем минимально достаточный код, чтобы он прошёл. Затем рефакторинг при сохранении зелёного состояния — фаза, ради которой цикл и существует: именно здесь рождается чистый дизайн, и именно здесь это безопасно, потому что тесты страхуют. 💡 TDD — инвестиция в долгосрочную изменяемость кодовой базы, а не способ писать код быстрее здесь и сейчас. Эффект — меньше дефектов, дешевле рефакторинг, выше скорость онбординга — проявляется на горизонте месяцев, а не одного спринта. ⚠️ Границы применимости: долгоживущая кодовая база со сложной логикой и команда, готовая к инженерной дисциплине. Для одноразовых прототипов и разработки в панике дедлайнов метод не окупается. 🔗 https://agaltsovav.ru/docs/development-managment/tdd-test-driven-development/ ENDOFPOST && ssh agaltsovav@100.64.0.4 wc -c /tmp/tg-post.txt

🏗️ Domain-Driven Design (DDD): проектирование от предметной области DDD — подход Эрика Эванса (2003), в котором первичным источником проектных решений выступает не технология, а предметная область: бизнес, ради автоматизации которого существует система. Главный принцип: код должен говорить на языке домена. Если эксперт называет процедуру «приостановкой обслуживания», в коде должен быть метод suspendService, а не updateStatus(flag=3). Подход делится на два уровня. Стратегическое проектирование отвечает на вопрос, из каких частей состоит система: единый язык, ограниченные контексты, карта контекстов, поддомены. Тактическое — как моделировать внутри одного контекста: сущности, объекты-значения, агрегаты, репозитории, доменные события. Распространённая ошибка — начинать с тактики без стратегической работы: тактика без стратегии почти бесполезна, а стратегия без тактики уже приносит значительную часть пользы. Деление поддоменов на core / supporting / generic работает как инвестиционная карта проекта: в ядро — лучшие разработчики и глубокое моделирование, поддерживающие домены — достаточное качество, стандартные для отрасли вещи (аутентификация, email, биллинг) — покупаются готовыми. 💡 DDD окупается при трёх условиях одновременно: сложный домен с правилами и инвариантами, долгоживущая система и постоянный доступ к экспертам. Не выполнено хотя бы одно — выгоднее более лёгкий подход: для CRUD и короткоживущих MVP тактический DDD становится структурой без содержания. 🔗 https://agaltsovav.ru/docs/architecture/ddd/

🤖 AI-Driven Development: код пишет AI, человек отвечает за спецификации AIDD — методология разработки, в которой основную ответственность за генерацию кода, тестов и документации несёт AI-модель. Человек смещается на уровень выше: пишет спецификации, принимает архитектурные решения и валидирует результат. AI при этом — не надстройка над привычным процессом, а самостоятельный производитель кода. Отправная точка — разведение трёх режимов работы с AI. AIAD (AI-Assisted): за код отвечает человек, AI лишь помогает подсказками. AIDD (AI-Driven): код генерирует AI, а человек организует контекст и проверяет вывод. Vibe Coding: код создаётся «на вайбе», без спецификаций и тестов — именно этот режим порождает проблемы, которые AIDD призвана решить. Ключевой принцип: вокруг AI выстраивается та же инженерная дисциплина, что и вокруг любого другого источника кода — спецификации, тесты, ревью, контроль версий и фиксация архитектурных решений. ⚠️ Цена вопроса высока: без дисциплины GitClear фиксирует восьмикратный рост дублирования кода, а DORA — плюс 9% дефектов. AIDD ускоряет разработку и повышает качество, только если команда готова нести накладные расходы на методологию. 🔗 https://agaltsovav.ru/docs/ai/aidd/

📦 Lean Canvas и Business Model Canvas: бизнес-модель на одном листе Канва — одностраничный шаблон из пронумерованных блоков, в которых команда фиксирует ключевые предположения о продукте: кого обслуживаем, какую проблему решаем, какую ценность предлагаем, через какие каналы доходим до клиента и как зарабатываем. Принцип «одна страница — одна модель» заставляет отсекать второстепенное: если модель не помещается на лист, она либо не продумана, либо слишком сложна для первой проверки. У инструмента два происхождения. Business Model Canvas Остервальдера описывает модель девятью блоками и адресован зрелым компаниям. Lean Canvas Эша Морийи — адаптация для стартапов: блоки про инфраструктуру (партнёры, ресурсы) заменены блоками про риск (проблема, решение, метрики, несправедливое преимущество). 💡 Ценность канвы не в том, что она «правильная», а в том, что она делает предположения видимыми и проверяемыми. Это черновик стратегии, а не сама стратегия: красиво записанная гипотеза остаётся гипотезой до проверки через Discovery. Главный риск — выбор канвы не по стадии: Lean Canvas теряет партнёрства и ресурсы зрелого бизнеса, а BMC маскирует главные риски раннего стартапа за инфраструктурными блоками. 🔗 https://agaltsovav.ru/docs/product-managment/lean-canvas/