Три верных признака того, что пора пилить свой фреймворк

    В жизни практически любой команды разработчиков наступает момент, когда создание собственного фреймворка переходит из статуса «Нафига нам тратить время?» в статус «Классная идея!». У нас такой момент наступил около двух месяцев назад, когда мы начали прикручивать к клиентскому мобильному приложению Промсвязьбанка, 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. И в некоторых сценариях не нужно даже подносить телефон к себе. Например, когда вы за рулем, а телефон закреплен рядом, камера может легко вас опознать.

    Посмотрите вокруг: голосовые помощники начинают активно завоевывать окружающее пространство. Ажиотаж вокруг умной колонки от Яндекса, говорящие и понимающие приказы стиральные машины, пульты от телевизоров, распознающие голос. Чем больше пользователи будут окружены голосовыми интерфейсами, тем больше они будут готовы к тому, чтобы общаться с банковскими приложениями.

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

    Для разработчика такое изменение, в принципе, не страшно. При правильной архитектуре у приложения может быть сколько угодно интерфейсов: визуальный, голосовой, нейро. Главное — использовать подходы, соответствующие текущему уровню зрелости команды.
    Промсвязьбанк
    41,00
    Компания
    Поделиться публикацией

    Комментарии 12

      +6
      Не нашёл ни одного выделенного признака что пора делать свой Фреймворк.
      Более того, из определения фреймворка: «Фреймворк — программная платформа, определяющая структуру программной системы», судя по описание вы сделали библиотеку а не Фреймворк
        +1
        Три ключевые для нас причины: достаточный объем кода, понимание бизнеса и первая стартовая задача. На тему фреймворк или нет можно рассуждать долго. Самый главный аргумент, что мы помимо вынесенных библиотек, вынесли отдельный сетевой слой, который сильно влияет на архитектуру нашего мобильного приложения. Собственно исходя из этого, мы можем говорить о собственном фреймворке.
        0
        Кажется, между пилением своих фреймворков и использованием чужих кажется есть золотая середина, к которой разумно стремиться.
        Есть прикладные задачи, их нужно решать в первую очередь. Стремление к
        повторному использованию кода очень хорошее и правильное, и если в процессе работы формируется некая библиотека более-менее универсального кода, то это хорошо, это как правило повышает качество самого кода. И поэтому нужно стремиться поддерживать этот комфортный для прикладных проектов уровень универсальности.
        Оформлять же это в виде именно фреймворка, то есть повышать уровень универсальности выше, чем реально необходимо для вашего проекта, и делать его таким чтобы код подходил для любых (почти любых) проектов, совершенно не надо (если только не стоит непосредственная задача создания фреймворка).
        В использовании чужих фреймворков минусы тоже всем известны — код который написан кем-то менее прозрачен чем написанный собственноручно; а слишком высокая универсальность зачастую достигается за счет производительности, простоты и компактности.
          +3
          Из-за той боли и страдания, которые обязательно пару раз в месяц приносит ваш банк-клиент для бизнеса, я не могу верить ни одному вашему слову.
            +1
            Напишите, пожалуйста, на почту korolevav@psbank.ru. Коллеги постараются вам помочь.
            +2
            Не совсем понял. Заголовок «Три верных признака, что пора пилить свой фреймворк», а в статье нет ни «трёх», ни «верных признаков», ни «фреймворка». Возможно, стоит убрать в черновики? Статья явно не закончена
              +1
              Спасибо за обратную связь. Возможно, вы не заметили, но мы выделили наши три ключевых признака для создания фреймворка:
              • Мы наработали достаточную базу кода
              • Бизнес начал понимать наши (т.е. и свои) архитектурные нужды
              • Возникла подходящая задача
              0
              Не позорьтесь такими «статьями».
                0
                • Ну, во-первых, так статьи не пишутся, и если в заголовке написано «три верных признака», то отводить этим признакам три строчки в статье это как-то глупо.
                • Во-вторых, ни одни из приведенных тезисов признаком того что вам необходим фреймворк не является. Ну что, например, должна означать наработка достаточной базы кода? А если весь этот код на общеизвестных и массовых технологиях? Зачем в таком случае фреймворк. Ну и так далее.
                • В-третьих, фреймворк вы так и не написали судя по тексту, а ограничились просто набором библиотек.

                  +1
                  • Начнем с того, что каждый вывод подкрепляется историей, как мы этому пришли. Об этом наш материал.
                  • Нет четкого критерия того, что является признаком, что необходим фреймворк, а что — нет. Данная статья — это наш опыт. Для кого-то он может показаться не подходящим, но мы выделили для себя критерии, которые подкрепили необходимость фреймворка. К примеру, при изменении версии API меняются методы, классы моделей. Писать это все ручками не хотелось. Поэтому у нас есть шаблоны автогенерации кода. Модуль отвечающий за правила генерации тоже часть этого слоя. Также в этом слое используются и популярные библиотеки. Вот все это немного навязывает определенную архитектуру. Хотелось бы так же добавить, что наш фреймворк используют другие команды наших разработчиков.
                  • Почему фрейморк, а не просто библиотеки? Мы помимо библиотек вынесли отдельный сетевой слой, который сильно влияет на архитектуру нашего мобильного приложения.
                  0
                  Можете написать 3 признака того, что написали фреймворк?
                  скопирую простейшее определение :библиотека — это готовый к использованию набор кода, который бежит в контексте приложения, и точно так же выполняет свою работу. То есть библиотека становится при подключении частью приложения.

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

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

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

                  из ответа на вопрос (ru.stackoverflow): Разница между фрэймворком, библиотекой и API?
                    0
                    Мы вынесли из приложения немалую часть кода в отдельные компоненты. Часть из получившегося стала обычными библиотеками, а часть — фреймворками. В них мы поместили помимо кода еще и другие ресурсы, также в этих фреймворках у нас хранятся уже готовые модели и алгоритмы работы с ними. Эти фреймворки можно брать и использовать в других проектах. Это также была одной из наших целей.

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

                  Самое читаемое