Agaltsov Anton | TeamLead-блог

📋 Управление рисками проекта: превратить неопределённость в план Риск в проектном управлении — это событие × вероятность × влияние. Уже случившееся событие — проблема, а событие с нулевым влиянием — шум. Риск при этом не только угроза, но и возможность: с PMBOK 6 неопределённость официально разделена на угрозы и возможности, и зрелый риск-менеджмент работает с обоими хвостами распределения. Инструментальный минимум — реестр рисков и матрица «вероятность × влияние». Реестр ценен не как список страхов, а как план действий: у каждого риска есть владелец, триггер и стратегия реагирования. Для угроз — избегать, смягчать, передавать или принимать; для возможностей — использовать, разделять, усиливать. 💡 Управление рисками — непрерывный цикл, а не упражнение на старте: риски рождаются и закрываются, реестр живёт вместе с проектом. 🔗 https://agaltsovav.ru/docs/project-managment/project-risk-management/ ENDOFPOST && ssh agaltsovav@100.64.0.4 wc -c /tmp/tg-post.txt

🧪 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/