И что самое обидное - это был старый рефакторинг. Как оказалось из логов, моя система онбординга имела одну ахиллесову пяту, которая ждала своего часа. И дождалась :D
Краш в приложении - это не просто красный экран. Это слетевшие сохранения. Товары в корзине, которых больше нет. Пользователь, который может не вернуться.
У нас в разработке чёрным по белому документация всегда говорит:"Краш для пользователей - это самый негативный опыт. Не допускайте этого".
Спасибо этой ситуации, для себя я урок вынес - тесты на этот функционал написал за 10 минут. Больше краша не будет.
Можно улучшать разработческий процесс и чтобы самому не забыть - прописать за правило для работяжки покрывать тестами.
Хотел бы поделиться опытом, как минимизировать краши:
• Тесты - не паранойя, а гигиена. Можно не гонять всё подряд. Попроси Claude сделать умную систему: перед пушем - только задетый функционал, по ночам - полный прогон. Экономит время, ловит баги.
• Критичные фичи - на отдельной ветке. Пока не убедился, что всё ок - юзеры этого не видят.
• Большой функционал раскатывай постепенно. Выкатил - смотришь метрики. Всё чисто - катишь дальше.
——
Если для вас критично отсутствие критичных багов и крашей - лучше пишите тесты, гоняйте их - чтобы не терять пользователей :)