Три верных признака того, что пора пилить свой фреймворк
В жизни практически любой команды разработчиков наступает момент, когда создание собственного фреймворка переходит из статуса «Нафига нам тратить время?» в статус «Классная идея!». У нас такой момент наступил около двух месяцев назад, когда мы начали прикручивать к клиентскому мобильному приложению Промсвязьбанка, PSB Mobile, функцию голосового управления переводами с помощью Siri. Мы проанализировали свой опыт и на его основе расскажем, как понять, что время фреймворков все-таки настало.
«Какой фреймворк, вы о чем вообще?»
Раньше iOS-клиент банка для физлиц разрабатывался на аутсорсинге. Потом было решено переписать все самостоятельно с нуля. Выстроили процесс по SCRUM с двухнедельными спринтами, работа закипела — активно искали и добавляли новые функции, фишки. На этом этапе активных поисков было сложно предугадать, что приживется, что нет. Планировать все на 40 шагов вперед нет смысла. Никто не думал об изысках вроде универсальности — создавать свой фреймворк, выделять части кода в отдельные библиотеки для повторного использования. Вероятность того, что в этом не будет смысла, была слишком велика.
WWDC нас связала
Чем хорош SCRUM — мы часто контактируем с бизнесом как с заказчиком. При этом начали происходить важные перемены. Мы стали лучше понимать продукт, бизнес-задачи, бизнес-процессы банка, в которых участвует приложение. А главное, бизнес со своей стороны начал рассматривать развитие приложения как процесс, стал лучше понимать, как мы работаем, начал соглашаться с нами в том, что есть важные задачи, решение которых не дает заметный сиюминутный эффект.
Помогла нам сойтись с бизнесом… конференция WWDC. Наши бизнес-заказчики как-то посмотрели анонсы новых яблочных возможностей и в любопытстве залезли на Apple Developer. На удивление, там все оказалось гораздо понятней, чем ожидалось. С тех пор не только мы вовлекаемся в бизнес-задачи, но и бизнес уже не боится технологий: стараются сами читать спеки, проникать в суть проблем, помогать с аналитикой и врубаться в проблематику разработки. Они стали понимать, что бесполезно ждать четкого прироста продукта каждые две недели — ведь есть и сервисные спринты, от которых конкретного роста нет. Взаимопонимание дошло до того, что мы договорились 20% времени спринта отдавать рефакторингу.
Эволюция велосипедов
С ростом отдела разработки, наполнением приложения все новыми фичами, появлением нескольких команд, параллельно работающих над разными задачами, начали появляться новые нюансы. Некоторые подзадачи у команд могли быть схожими, и сразу же возникло желание не изобретать велосипед, а первым делом уточнить, нет ли у кого-нибудь уже готового кода.
К коду от наших разработчиков претензий обычно нет, так что его вполне можно задействовать повторно — причем не только в рамках обычной методологии code reuse. Наверное, уже на этом этапе у нас в головах зародилась идея выделить некоторые вещи в отдельные библиотеки для всеобщей пользы. Но в рамках существующих задач найти время на эти процессы не было возможности. Требовался какой-то повод, и вскоре бизнес его нам подкинул.
Спусковой экстеншен
Появилась задача сделать поддержку голосового интерфейса — чтобы можно было через Siri делать платежи другим клиентам банка по номеру телефона. Он говорит: «Переведи такому-то человеку столько-то денег». И если этот человек является клиентом Промсвязьбанка, то на экране возникает карточка человека, сумма перевода, вопрос «отправить деньги?» и кнопка «Отправить». Похожая функция уже есть в некоторых банковских приложениях, нам же захотелось сделать так, чтобы, с одной стороны, было безопасно, а с другой — клиенту не нужно было заходить в приложение банка.
Работа с Siri подразумевает написание отдельного экстеншена, и когда мы стали его планировать, то поняли, что настало время разработать свои фреймворки. У нас в проекте приложения был реализован сетевой слой, и возник выбор (на самом деле нет): писать этот слой заново или же вынести его в отдельный контейнер, доступный как в основном приложении, так и в отдельном экстеншене.
В процессе работы возникла архитектурная подзадача вынести часть кода в отдельные фреймворки. Всего их получилось четыре:
- Сетевой (средний) слой — тут вся работа с сетью, классы модели, сервисы API. Этот слой полностью автоматически генерируется.
- Авторизация
- Утилиты — служебные утилиты и хелперы
- Хранилище — защищенное хранилище
Понятно, что это не наше ноу-хау. Так принято делать в подобных ситуациях, это best practice всех уважающих себя разработчиков. Но важно, как мы к этому пришли. Именно в этот момент сошлись три ключевых условия для создания фреймворка: мы наработали достаточную базу кода, бизнес начал понимать наши (т.е. и свои) архитектурные нужды и возникла подходящая задача.
Новые горизонты
После осознания все оказалось несложно. На очередном собрании разработчиков мы обсудили детали, выбрали жертву ответственного, кто будет заниматься основным рефакторингом, выделили ему время — фултайм на эту задачу. Остальных разрабов это практически не коснулось. Зато когда мы начали выносить в фреймворк сетевой слой, сразу появились идеи, какие еще часто используемые части кода стоит вынести в библиотеку. Наши архитектурные возможности вдруг расширились. Мы начали жизнь с дополнительной степенью свободы.
Но пользуемся ей без фанатизма. Чтобы решить, выносить код в отдельный модуль или нет, мы смотрим бэклоги, определяем, будет ли этот модуль использоваться повторно, в нескольких местах. Если нет — то не стоит и заморачиваться.
Видим ли мы плюсы от использования своих фреймворков? Определенно да. Теперь мы видим, какие части требуемого в рамках новой задачи кода уже есть в репозитории. Разработка новых сервисов идет быстрее, ошибок при программировании меньше, качество итоговых сервисов выше.
Если потребуются новые экстеншены под iOS, у нас уже есть необходимые фреймворки, можно сразу экспериментировать. Что касается уже реализованного сервиса с Siri, то он больше месяца доступен пользователям банка — сейчас мы собираем отзывы в том числе и для того, чтобы понять, как и для чего еще использовать голосовой интерфейс.
Немного футурологии
История с Siri заставила нас задуматься не только о фреймворках, но и об интерфейсах в целом. Человечество пока не научилось измерять концентрацию внимания, только как-то косвенно. Например, чем хуже UX и UI, тем больше траты внимания, тем сильнее сужается воронка конверсии с каждым шагом. Обычный денежный перевод через приложение банка требует от пользователя кучи действий: открыть приложение, авторизоваться, поискать в одном списке, во втором, ввести адресата. С Siri это разблокировка плюс голосовая команда. Авторизация происходит в foreground через Face ID. И в некоторых сценариях не нужно даже подносить телефон к себе. Например, когда вы за рулем, а телефон закреплен рядом, камера может легко вас опознать.
Посмотрите вокруг: голосовые помощники начинают активно завоевывать окружающее пространство. Ажиотаж вокруг умной колонки от Яндекса, говорящие и понимающие приказы стиральные машины, пульты от телевизоров, распознающие голос. Чем больше пользователи будут окружены голосовыми интерфейсами, тем больше они будут готовы к тому, чтобы общаться с банковскими приложениями.
Графические интерфейсы при таком раскладе потеряют свою монополию, из основного средства общения превратятся просто в визуальное подтверждение действия, в способ сигнализировать, что компьютер правильно тебя понял.
Для разработчика такое изменение, в принципе, не страшно. При правильной архитектуре у приложения может быть сколько угодно интерфейсов: визуальный, голосовой, нейро. Главное — использовать подходы, соответствующие текущему уровню зрелости команды.
