Вопросы замены эквайринга и смс авторизации на живом проекте

Сегодня я хочу рассказать о смене эквайринга и смс-авторизации на примере уже разработанных нами проектов, а так же смоделировать ситуации, при которых смена команды разработки даже в простых задачах вызовет проблемы

Первый пример: СМС-авторизация

Работа SMS-шлюза одного из разработанных нами приложений проходила через Firebase Authentication и их собственный СМС-шлюз, но в связи с известными событиями последнего времени до некоторых операторов сообщения больше не доходили. Например, на МТС приходит, а Билайн и Теле2 не получает смски. Чтобы проект продолжил существование, нужно было изменить шлюз.

По мнению клиента, проблема решалась легко: нужно поменять шлюз, подключив вместо классического шлюза Firebase новый Stream Telecom – то есть просто поменять URL запроса SMS. Но когда мы стали глубже вникать в реализацию СМС-шлюза Firebase, оказалось, что в нём всё так сильно переплетено с самим модулем авторизации, что простой переброской шлюза не обойтись – оба работают как единое целое, и требуются более серьёзные изменения.

В итоге мы пришли к тому, что кроме внедрения SMS-шлюза нужно переработать ещё и авторизацию. На всё про всё ушло 18 часов разработчика и 3 часа технического директора (при простом перебросе вполне можно было бы уложиться в 3-4 часа с тестами и отладкой).

Вывод № 1: когда приходит время обновления или замены поставщика данных (в нашем случае – поставщика СМС для авторизации), нужно быть готовым, что потребуются значительно большие усилия, чем кажется на первый взгляд. Например, не просто менять модуль, а ещё и вносить изменения в сам проект, потому что разные модули может вписываться в инфраструктуру IT-продукта по-разному.

Второй пример: интеграция эквайринга

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

Нам удалось решить проблему и перекинуть эквайринг всего за 6 часов, причём из них 1,5 часа ушло на изучение документации и час на двухфакторную аутентификацию в его ЛК, потому что нам никак не удавалось поймать момент, когда и программист свободен, и клиент на связи. Так что, в принципе, целиком эквайринг безо всяких изменений вполне реально поменять за 4 часа. В данном примере всё решилось просто, и никаких плясок с бубном и переделки самого проекта не требовалось.

Задачи, в которых нужно что-то поменять или добавить, поступают довольно часто. Для их решения обязательно наличие всех доступов и исходников проекта, но в ряде случаев ещё и его рефакторинг – если процесс предполагает более глубокую интеграцию, чем обмен данными по шлюзам.

Вывод № 2: проще и быстрее всего вносить изменения с текущим разработчиком – тем, который уже работал над вашим проектом. Так вы сэкономите деньги, которые пришлось бы выплатить сторонней команде за изучение чужого кода.

Что делать при смене разработки

Но часто бывает так, что смена разработчика неизбежна. Многие наслышаны об историях:

  • Заболела бабушка / попал в больницу или аварию и тд. Когда разработчик навертел в проекте так, что даже за деньги не готов его развивать
  • Стоимость доработок развивается в геометрической прогрессии и клиента просто «доят»
  • Студия просто закрывается по произвольным причинам или меняет направление деятельности

Часто к нам в Bright Mobile клиенты предоставляют исходники и запрашивают самые разные изменения, вплоть до переделки функционала приложения или замены/переподключения сервиса. Кроме того, чтобы дать оценку на непосредственно саму работу над проектом, нам нужно время, чтобы сделать кодревью и вникнуть в архитектуру.

По итогу изучения, особенно, если объём переработок большой, то дешевле бывает собрать проект с нуля (основателю это больно слышать, но экономически это часто именно так), либо, если идея близка к маркетплейсу услуг, запустить на готовом решении.

Вывод № 3: Даже если есть недовольство в работе с разработчиком, решать вопрос нужно с холодной головой, учитывая все экономические последствия.

Вполне возможно, сторонние программисты выставят вам чек в три-четыре раза больше текущего не из жадности, а потому, что им придётся погружаться в чужой код, что тоже требует времени. Сохраняйте хорошие отношения, даже если прерываете сотрудничество: пусть он и не станет ничего делать руками, по крайней мере он сможет вас проконсультировать, а это несомненный плюс.

Поднятие версий

Недавно вышел тринадцатый Андроид, который признал устаревшими и перестал поддерживать часть функций фреймворка для кроссплатформенной разработки Cordova. Клиентам, которые делали приложения 4-5 лет назад, пришлось обращаться за поднятием версий: часть функционала их сервисов прекратила работу, и это нужно было обновлять.

В среднем, вышло по 4-6 часов на проект.

Вывод № 4: изменения могут происходить не только по вашей инициативе, а ввиду устаревания технологий, на которых вы делали свой продукт.

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

Надеюсь, что эти заметки на полях будут полезны основателям, которые делают свой первый проект. Если у Вас сейчас есть проблемная ситуация, опишите мне её в вотсап +79178232748 — разберу в следующих статьях.

0
9 комментариев
Написать комментарий...
Max
опишите мне её в вотсап +79178232748

Чзх, человек связанный с IT и Whatsapp?

Ответить
Развернуть ветку
Nikolay S

Пишите мне в Одноклассниках.

Ответить
Развернуть ветку
Bright Mobile
Автор

в ок не сижу. ФБ и инста, к слову, тоже раз в мес до СВО пользовался, т.к. говно редкостное в плане удобства интерфейса.

Но это сейчас не модная точка зрения

Ответить
Развернуть ветку
Bright Mobile
Автор

Если бы кадры искал, дал бы телегу. А 85% клиентов и основателей стартапов пишут мне в вотсап. Потому и дал.

А, вообще, ни разу не видел человека, который бы не имел на телефоне 3-4 месенджера.

Или у вас вопрос чисто религиозный?

Ответить
Развернуть ветку
Max

1. Странные люди
2. Я тоже не видел
3. Да, чисто религиозный

Ответить
Развернуть ветку
Bright Mobile
Автор

1. Стартаперы все странные. Были бы нормальными, не выделывались бы и пользовались тем что уже есть
3. Мне тоже телега больше нравится, но се ля ви

Ответить
Развернуть ветку
Dmitry Baychapanov

Вывод № 1: когда приходит время обновления или замены поставщика данных (в нашем случае – поставщика СМС для авторизации), нужно быть готовым, что потребуются значительно большие усилия, чем кажется на первый взгляд.

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

Ответить
Развернуть ветку
Bright Mobile
Автор

мы не являемся разработчиками Firebase Authentication, мы являемся его пользователями

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
6 комментариев
Раскрывать всегда