Перед любой командой разработки возникали такие задачи, как необходимость запуска микропроектов. Это мог быть и микросервис или проверка какой-либо гипотезы.
В моем понимании микропроекты — это проекты с очень коротким жизненным циклом: они разрабатываются, запускаются, какое-то время работают и закрываются.
Спецпроекты бывают простые в разработке и сложные, чаще всего это определяется сложностью бэкенда. И в спецпроектах любого типа и уровня сложности мы иногда косячим. Бывает, что успеваем поправить, и никто не замечает, а бывает и так, что приходится идти к клиенту и извиняться за свой промах. Из своего опыта я выделил несколько правил, которые, я надеюсь, помогут вам избежать некоторых проблем.
1. Не браться за проект, если времени не хватает, а дедлайн несдвигаемый. Иначе может быть так, что вы будете запускаться с серьёзными багами — отменить запуск невозможно, а ответственность слишком большая.
2. Полностью логгировать все присылаемые пользователем данные — регистрационные, ответы, клики, в общем всё, что можно потом использовать в случае, если данные в основном хранилище пропадут или будут испорчены. Однажды мы очистили хранилище на продакшене после запуска коммерческого спецпроекта, даже просто лог всех POST-запросов нас бы спас.
3. Не лениться прописывать все исключения и логгировать все ошибки и исключительные ситуации. Да, это одноразовый код. Нет, не надо экономить время на этом.
4. При запуске спецпроекта обязательно в рабочем режиме должен быть кто-то из разработчиков — следить за логами, ошибками и багрепортами. Однажды мы запустились в выходной без дежурного разработчика, считая, что всё достаточно протестировано. Это был тяжёлый опыт.
5. Прописывание универсальных чек-листов для запуска и окончания спецпроекта: очистить тестовые данные, проверить шериг в соцсети, прекратить приём заявок и так далее — ведь нельзя ничего пропустить.
6. У каждого проекта должен быть только один ответственный, но не для того, чтобы повесить всех собак на него в случае промаха, а для того, чтобы не было ситуаций типа «я думал, что ты это проконтролируешь».
7. Да, это маленькие проекты и темпы их разработки сильно отличаются («в такие дни я деплою на продакшн по 50 раз в сутки»), но это не значит, что можно ограничиться мессенджером для фиксирования задач — нужно вести список в Jira, Trello или хотя бы в гугл доке — чтобы ничего не потерялось, потому что каждый запуск нового минипроекта — это жара.