Мобільна платформа. Як не боятися ReactNative

Перший пост блогу ми вирішили присвятити «мобільного» тематики і розповісти про розробку глобального рішення для запуску і створення додатків — «Мобільна платформа ЕФС».

Що це? Це многомодульный продукт, що дозволяє масово створювати мобільні додатки, тиражувати їх і підтримувати під час експлуатації.



Отже, що ми робимо по черзі і по пунктах.
Розробка продукту
Ми розробляємо власний фреймворк, використовуючи бібліотеку React Native. Наш фреймворк включається в мобільні додатки ЕФС для співробітників і є мобільним ядром, що містить нативний код. Мобільні бізнес-додатки тепер розробляються на JavaScript.

Ми виносимо типові фрагменти коду в сутності, які називаємо «компоненти» або «сервіси».

На поточний момент наші компоненти бувають трьох типів:

  • візуальні компоненти (стилізовані кнопки, перемикачі, списки, свитчеры, завантажувачі тощо);
  • не візуальні сервіси (робота з мережею, аутентифікація, логування, дистанційне конфігурування і т. д.);
  • мобільні віджети (end-to-end компоненти, що дозволяють виводити деякі агреговані показники в спеціальному розділі, званим «Dashboard»).
Компоненти мають міст-обгортку в JavaScript (використовується механізм ReactNative), тим самим ми дозволяємо JavaScript-розробникам, використовуючи стек JS/TS, React + Redux, створювати мобільні та frontend клієнти.

За кожним з компонентів ховається нативна імплементація. Ми використовуємо objective-c як основний мову, строго підходимо до архітектури, а також дбаємо про продуктивності і оптимізацію.

Нас не задовольнила організація бібліотеки ReactNative, оскільки вона не виглядала ізольованою, багатошаровою і придатною для масштабування, тому ми винайшли свою архітектуру компонентної бібліотеки — зараз наша архітектура багатошарова і дотримується основних правил VIPER, SOLID і SOA.

Концептуальний ескіз на малюнку нижче:


По суті ми потоваришували ReactNative і VIPER.





Ми майже повністю відмовилися від стандартних компонентів, розроблених Facebook, і реалізуємо заново ті, які потрібні для побудови наших програми. Чому?

  1. Наші компоненти повинні мати єдиний унікальний візуальний стиль ЕФС і бути непридатними для зміни (тільки допустимі налаштування через властивості).

  2. Ми не можемо покрити тестами код ReactNative і відповідати за їх якість, а також коректну поведінку.

  3. Ми не прийнятний fork-бібліотеки та їх подальший розвиток.

  4. Наше розуміння архітектури не поділяється творцями ReactNative і ми не можемо инжектить або переиспользовать певні частини коду, які використовуються в компонентах.

  5. ReactNative — ще в глибокій beta-версії і динамічно змінюється. Між змінами версій не підтримується принцип зворотної сумісності і ми не можемо бути впевнені, що код нашої бібліотеки коректно відбудеться створення після виходу оновлень від Facebook.

  6. Ми хочемо мати «в запасі» нативний код, який потенційно дозволяє використовувати цей компонент в інших проектах і навіть поза концепції ReactNative.
Чому ReactNative?
При створенні ми дотримувалися наступних принципів.

  1. Створити рішення, що дозволяє розробнику з однаковим технічним стеком розробляти як мобільні, так і frontend-програми.

  2. Дозволяти швидко переиспользовать вже розроблену раніше функціональність.

  3. Мінімізувати витрати банку на розробку та підтримку програм.

  4. Забезпечити швидкий time-to-market.

При аналізі і виборі рішення у нас було кілька вихідних параметрів і критеріїв:

  • велика кількість legacy-систем у банку, розроблених для Web;

  • як наслідок цього велика кількість розробників з компетенціями в JavaScript;

  • розвивається перспективний продукт для Web, використовує у своїх принципах JS, React і Redux.
Так як одними з наших вихідних завдань були уніфікація стека розробки і мінімізація витрат, ми приступили до підбору рішення, що дозволяє нам створювати мобільні додаток, використовуючи JavaScript як мова для написання прикладного коду.

Cordova і PhoneGap відпали, т. к. використовуючи їх, на виході ми отримуємо не нативне додаток.

ReactNative ж інтерпретує JS-код в objective-c виклики в Runtime, що дозволяє виконувати нативний код і будувати інтерфейсні форми з UIView-нащадків.

ReactNative — це природне продовження React, що дає нам можливість писати уніфікований код, що виконується на мобільних додатках і frontend-клієнтів на десктопах.
Тестування
Ми завжди тестуємо те, що ми розробляємо, адже одна з обов'язкових якостей платформних бібліотек — це надійність.

Зараз у нас є автоматичні Unit-тести, які запускаються при кожному PR і билде фреймворка.

Ми вважаємо за необхідне тестувати окремі компоненти та код демо-проекту руками.

В найближчому майбутньому до них приєднаються автоматизовані інтеграційні тести між модулями, UI-тести і Performance-тести для впровадження в бізнес-проекти.

Також у стратегічних планах стоять: розробка свого фреймворку для написання крос-кодових тестів (JavaScript <-> objc-C) і статичних аналізаторів для аналізу коду бізнес-проектів.
Автоматизація процесів
Ми автоматизуємо те, що ми робимо. Зараз у нас є CI і CD для окремих модулів платформи. У нас є окрема фізична білд-машина, під'єднана до корпоративного Jenkins.

Запуск тестів, code coverage report, оновлення показниківdashing.io, зборка версії і публікація в nexus — лише маленький перелік всіх процесів, які автоматизовані у нас на поточний момент.

Ми розвиваємо DevOps і плануємо інтегрувати CI/CD з усіма прикладними проектами, а також автоматизувати роботу зі службою підтримки, розбір інцидентів і багато іншого.
Масштабування
Зараз ми працюємо над глобальною архітектурою та принципами побудови всіх мобільних додатків в рамках ЕФС, що використовують платформу.

Для можливості перевикористання між проектами, ми опрацьовуємо систему поділу прикладного коду та оформлення у вигляді незалежних JS Bundle. JS Bundle поширюються у вигляді npm-пакетів і підключаються в додаток на етапі компіляції.

Такий підхід дозволить створювати статичні програми та їх оновлення через збірку. Це не вирішує проблеми: бізнес хоче бачити різні «набори» з JS Bundle в додатках в залежності від ролі користувача (продавцям один функціонал, начальникам інший).Таку проблему можна вирішити або створенням великої кількості маленьких додатків ролі, або включенням всіх JS Bundle в один бінарники.

На жаль, в такому разі ми порушуємо наша вимога до time-to-market, тому що чим більше додаток, тим довше регрес-тести, спрямовані на виявлення дефектів певної версії.

Була запропонована концепція динамічного завантаження JS Bundle в мобільний додаток. Так, звучить дуже кльово і інноваційно! Але це нова система, що вимагає розробки, прототипування і пілотування. На сьогоднішній день у світі таких систем одиниці (особливо для рідних додатків).

Опрацювання даної концепції ми почнемо з R&D. Відмінна можливість приєднатися до команди, якщо вам цікава така амбітна історія :-)
Як ми працюємо?
Наші команди розробки Мобільної платформи ЕФС працюють за Agile-методологій, використовуючи Scrum-підхід.

У нас двотижневий delivery-цикл, а також усі обов'язкові Scrum-артефакти: planning, stand-up, grooming, demo, retro.

Stand-up допомагають нам актуалізувати проблеми кожен день, а також ділитися реалізованим між усіма членами команди. Важливо: ми не витрачаємо більше 15 хвилин в день на stand-up і проводимо їх тільки стоячи.

Ми регулярно переоцінюємо наш бэклог і деталізуємо наші завдання — це допомагає нам витрачати менше часу на планування. А ретро і демо проходять у нас весело й ініціативно (участь в конкурсах та номінаціях, організованих нашим скрам-майстром).

Крім процесів ми суворо стежимо за технічною стороною нашого продукту: пишемо документацію, гайди, проводимо консультації та допомагаємо іншим проектам.

Ми документуємо свої процеси і підходи, щоб не забувати їх і мінімізувати активні дискусії в наступний раз.

Новачки не відчувають себе втраченими, тому що ми сидимо поруч, завжди виділяємо наставника і маємо внутрішні інструкції-шпаргалки.
Як дізнатися більше і приєднатися?
Цікаво дізнатися більше? Давайте поспілкуємося з творцями платформи прямо в коментарях до публікації, кому цікава ця тема, будемо раді живого діалогу.

Ще ви можете подивитися наші виступи



А якщо відчуваєте в собі сили і бажання, ми запрошуємо в команду талановитих та амбітних фахівців:

  • iOS-розробників (obj-c, ReactNative, VIPER, JS, SOA, Typhoon).
  • frontend-розробників (TypeScript, JavaScript, React, Redux).
  • дизайнерів і проектувальників інтерфейсів.
  • автоматизаторів і мобільних тестувальників.
Пишіть на пошту Євгену Ртищеву ESRtishev.SBT@sberbank.ru або Островської Анастасії ASOstrovskaya.SBT@sberbank.ru

Початок покладено, далі ми будемо публікувати багато цікавого і корисного контенту за темами розробки та процесного управління, проектування і дизайну.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.