Андрей Казаков

В прошлом посте мы разобрали ловушку оптимизма, в которую попадают при попытке оценки нового проекта. Главная причина — Planning Fallacy: когда наш мозг из раза в раз моделирует идеальный сценарий и игнорирует прошлые провалы.

Как мы выяснили в прошлых постах, срыв сроков у команды — признак систематических проблем в процессах. Теперь разберем главную причину, с которой начинаются большая часть провалов — проблема оценки сроков.

Разработка часто страдает от болезни «почти готово». Это состояние, когда код написан, но функциональность еще не выпущена в продакшен, потому что «еще не дописали тесты», «забыли дополнительное условие» или «дизайнер еще не смотрел».

Итак, мы установили, что даже команды, которые состоят из суперзвезд, могут легко провалить все мыслимые и не мыслимые строки.

Довольно часто возникают такие ситуации:

Иногда приходится интегрироваться с системами, которые работают в асинхронном режиме, но при этом выставляют API с синхронными вызовами.

В предыдущих постах мы разобрали подходы к организации бизнес-логики — Transactional Script, Active Record. Теперь начнем движение в сторону полноценной Domain Model. Но сначала хочется подробнее остановиться на одном из фундаментальных строительных блоков доменной модели — Value Object. Этот паттерн прост по своей сути, но вместе с тем очень часто…

Как часто вы сталкиваетесь с неприятным кейсом - запускаем миграцию liquibase на стенде, а она падает с ошибкой или данные становятся неконсистентны? При этом на машине разработчика все проходит успешно...

В прошлом посте мы разобрали проблему full-scale старта. В этом разберем самый главный вопрос: А с чего же начать?

В прошлом посте мы разобрали классический вариант реализации Active Record. Обсудили, когда стоит переходить от Transactional Script к Active Record.

В прошлом посте мы разбирали Transactional Script - отличный инструмент для старта. Но любой проект развивается. Со временем вы начинаете замечать, что Transactional Script становится сильно усложненным. В них добавляются простые бизнес-инварианты, дополнительные проверки и сами структуры данных становятся довольно сложными.