Когда продукт растёт, в нём появляются зависимости, которые легко пропустить.

Например, в нашем приложении в настоящее время можно залогиниться только при помощи "Sign in with Google." Код, который отвечает за удаление пользовательского аккаунта, зависит от того, что аккаунт создан при помощи гугла, но в ближайшее время мы добавим вход при помощи Apple (эппловское требование для приложений, которые используют OAuth) и через емейл.

Если мы забудем добавить код для удаления аккаунтов, созданных через эппл или емейл, то приложение выдаст ошибку, пользователи не смогут удалить свои данные и мы можем нарушить европейский закон GDPR, который предписывает, что данные должны быть удалены в течение 30 дней после запроса пользователей.

В отличие от технических зависимостей, компиляция приложения не сломается, если мы забудем обновить код удаления аккаунтов. Функция сломается в продакшене.

Поэтому такие зависимости нужно отлавливать другими способами:

1. (Идеально было бы иметь) автоматическое тестирование, которое само прогоняет тесты для всего, что связано с управлением аккаунтом. Тогда при добавлении входа через Эппл, тест на удаление аккаунта сломается и мы это заметим на этапе разработки. Но автоматические тесты для нас сейчас непозволительная роскошь.
2. Ручное тестирование может помочь, а может и нет. Мы создали чеклисты для ручного тестирования, но с ростом приложения и релизами раз в неделю или даже чаще, мы тестируем только критический функционал. Удаление аккаунтов не так критично...
3. Мониторинг продакшена позволит нам обнаружить проблему быстро и пофиксить её. Если у пользователя не получится удалить аккаунт, приложение выкинет exception и мы получим уведомление в Slack. Мы сможем всё бросить и быстренько допилить недостающий код. Правда, пользователи, на которых функция сломалась, не смогут удалить акк. С ними придётся связываться после обновления приложения. Это работает только на небольшом масштабе.
4. Добавить комментарий в блок кода, отвечающий за Sign-in, что нужно не забыть обновить удаление аккаунта. Кустарно, но в теории должно помочь.
5. Сделать код удаления аккаунтов достаточно гибким, чтобы он сам определял, как пользователь создал аккаунт и подстраивался без необходимости менять код каждый раз при добавлении новых методов входа в приложение. Возможно, мы это сделаем в следующей итерации. Прямо сейчас, это будет перебор, так как мы не сможем протестировать, работает ли такой код (прямо сейчас мы поддерживаем только один метод).
6. Для начала мы пошли супер простым, самым кустарным путём. В таске на добавление входа через эппл и емейл, я добавил требование, что такие аккаунты должны удаляться. Сделав это требование частью acceptance criteria, мы точно не забудем про него в следующей итерации, но можем забыть в после-следующей (например, если добавим вход при помощи номера телефона).

В идеале, конечно, хотелось бы, чтобы такие зависимости работали так же как технические зависимости от библиотек. Чтобы приложение тупо не компилировалось и выкидывало ошибку в build time. С этим поможет автоматическое тестирование, а пока рассчитываем на ручные механизмы и людскую память (мухаха). Не исключено, что через итерацию этот функционал сломается и будем деплоить хот-фикс 🤷‍♂️