​​Как мы SDK для системы платежей обновляли
— Ну что, готово?
— Нет.
— А когда будет?
— Через неделю.
— А можно как-то быстрее? И помнишь, мы еще другую функцию просили запилить, там уже есть какие-то сроки?

Вы Project-manager, к которому через день приходят из разных отделов и вопрошают: «Ну что, готово?».
Понять их можно – чем быстрее пользователи мобильного приложения получат обновления, тем вероятнее компания получит прибыль. Понять можно и команду разработки, потому что 50% задач срочные и важные, а по слову «вжух» релизы не выпускаются.
Как решить? Ускорить выход релизов, например, с помощью мобильного SDK, как сделал наш клиент.

SDK – это набор готовых решений, в котором может содержаться несколько API, фрагменты кода, библиотеки, документацию и другие инструменты. А еще SDK упрощает работу команды и в результате все счастливы:
• разработчик тратит гораздо меньше времени на создание кода;
• маркетинг быстрее получает новые функции и проверяет окупаемость новых гипотез;
• компания меньше тратит на разработку.
У нашего клиента SDK уже был, но ему потребовалось его обновить, в связи с запуском нового бизнес-направления.

Нам предстояло исправить несколько ключевых ошибок, которые влияют на проведение платежей, а также «научить» SDK настраивать вид приложения при подключении новых партнёров. Для этого нужно было разработать новый функционал, обновить цветовую палитру и добавить новые UI-элементы.
Как обычно, не всё так просто, как кажется на первый взгляд – в работе мы столкнулись с несколькими трудностями:
▪️ сильно связанный код текущего SDK, отсутствие единой архитектуры;
▪️ старый стек технологий, отсутствие автоматизации кода;
▪️ 90% кода было написано на Java, что замедляло темпы разработки нового функционала из-за специфики языка;
▪️ отсутствие единого подхода к вёрстке;
▪️ множественное дублирование кода (отсутствие корректной иерархии наследования классов).

О том, как мы всё решили и что в итоге получилось – рассказываем здесь 😏