Впровадження Flutter у Tide: досвід провідної фінтех платформи з Великої Британії [ukr]

Треба все переписати. Це фраза, яку бізнес ніколи не хоче почути, особливо коли ваша фінтех-компанія перетворилася зі стартапу у великий стабільний ентерпрайз-бізнес із великою базою клієнтів, стабільними мобільними додатками та перспективами глобального росту. У цій презентації ми хочемо поділитися своїм досвідом і описати, як і чому ми вирішили провести міграцію мобільних додатків у компанії, яка приділяє особливу увагу Mobile First, на нову технологію.

Під час спілкування з представниками бізнесу, ми розкажемо, як структурували команду та налаштовували процеси. За кілька хвилин ми представимо вам компанію, але перед цим дозвольте нам представитися. Мене звуть Олександр Леощенко, я Google Developer Expert з Flutter та Dart. Я працюю на позиції Senior Staff Engineer в Tide. Досить важко описати мої обов'язки у цій ролі. Я виступаю як технічний експерт, відповідаючи за основний функціонал мобільних додатків та за їх безпеку. Також надаю менторство. Разом із колегами з інших відділень працюю над архітектурним дизайном і тим, що називається Research and Development. Грубо кажучи, будь-яка проблема в Tide – це моя проблема. До цього я протягом кількох років обіймав посаду керівника мобільного департаменту в компанії Seeklum. Ви можете знайти мене на LinkedIn, Twitter, GitHub та YouTube. Олекс Лі – це ім'я мого профілю.

Декілька слів про мене, перш ніж ми продовжимо нашу тему. Я пишу програмне забезпечення з 2012 року і фокусуюся в основному на створенні кросплатформових мобільних додатків. Також я є Google Developer Expert у Dart та Flutter і активно вношу вклад у популяризацію цих технологій та розвиток ком'юніті. Створюю навчальні матеріали, пишу статті і виступаю на технічних конференціях про Flutter. Все це я публікую у вільний доступ у своїх соціальних мережах. Зараз я також обіймаю посаду Senior Staff Engineer в тій самій компанії і зосереджуюсь в основному на технічній експертизі. Разом із Олександром, ми є співавторами та гейткіперами архітектури проєкту. Також я приділяю багато уваги освіті.

Тепер, власне, про саму компанію. Заснована як стартап у 2015 році, вона має за мету революціонізувати, як підприємці управляють фінансами, заощаджуючи їм час і гроші. Це означає перехід від необхідності фізичного відвідування фінансових установ і автоматизацію багатьох бізнес-процесів, таких як оплата податків, відсилання рахунків клієнтам, делегування повноважень у деяких процесах своїм співробітникам і багато іншого. Компанія запустила перший продукт у 2017 році і наразі успішно функціонує у Великій Британії та Індії. Велика Британія становить 10% ринку, обслуговуючи півмільйона малих і середніх підприємств. У Індії ми розпочали діяльність лише на початку цього року, але вже маємо вражаючі результати. Компанія має центри розробки у декількох країнах, включаючи Велику Британію, Індію та Болгарію, і наймає працівників в різних куточках світу, включаючи Україну.

Це і сучасний стан компанії. Наша мета сьогодні – розповісти, що ми робили протягом останніх двох років, зокрема передостаннього року, коли ми вже могли спостерігати наслідки своїх рішень і оцінювати їх ефективність, а також розповісти про можливості, які вони відкрили для нашого бізнесу. Отже, повернемося на два роки назад, коли компанія вже успішно функціонувала в Великій Британії, і вона мала амбіції стати глобальним гравцем у сфері фінансових послуг. Таким чином, компанія Байкставер ставила перед собою амбіційні завдання щодо входу на нові ринки, аби зробити свою платформу доступною для компаній по всьому світу. При цьому компанія розуміла необхідність швидкої адаптації продукту до ринкових умов кожної країни та врахування потреб і очікувань користувачів цих країн. Оскільки в багатьох випадках ринок бізнесів відрізняється від країни до країни, у компанії вбачали необхідність експериментів, щоб ми могли швидко розробляти та тестувати прототипи нового функціоналу, а в разі успіху ще й перевикористовувати ці рішення у фінальному продукті. Ну і зрозуміло, що ми мали мінімізувати витрати на розробку, бо у конкурентному середовищі фінтек ефективність у випуску нових функцій часто може стати ключовим фундаментом.

Отже, ось такі були цілі, а реальність на той момент зовсім їм не сприяла. Ми мали на руках рішення, архітектура якого була зовсім не готова до підтримки ринків за межами Великої Британії. Додаток не підтримував локалізацію, не був готовий до масштабування і кастомізації. Користувацький досвід і вимоги до функціоналу заточені виключно під потреби бізнесів Великої Британії. Це було справедливо як для мобільних додатків, так і для бекенду, що знову ж таки був побудований навколо лише однієї країни. Ну і сервіси, з якими наша компанія співпрацювала, такі як партнерські банки, сервіси верифікації юзерів і подібні, оперували тільки в UK і для інших країн інтеграція потребувала нових рішень. Таким чином, ці обмеження переважно мали технічний характер. Тобто реалізація продукту була виконана в дусі стартапу і не передбачала перспектив масштабування. І це було допустимо для тих завдань, які стояли перед компанією до цього. Але тепер настав час змін.

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

Отже, щодо вибору технологій. Перш за все, нам треба було визначитися із підходом: Greenfield чи Brownfield? Обидва терміни прийшли з сфери фермерства. Greenfield – це поле, яке до цього не було розорене, а Brownfield, відповідно, яке вже було. Ми розуміли, що розпочинати все з нуля має свої переваги, але й ризики. Тож ми схилилися до Greenfield, але провели ревізію кодової бази та визначили, що наш Android-проєкт потребує значних змін. Таким чином, ми вирішили подивитись на різні технології, які могли бути використані для розробки. Наш вибір включав нативну розробку, Flutter (який вже був стабільний), і Kotlin Multiplatform (який був у доволі початковому стані). Чому ми не розглядали React Native? Через відому статтю від Airbnb, яка на той момент саме вийшла. Ми також відкинули Kotlin Multiplatform, обравши інші технології. Він був у бета з неясними перспективами, а ще без UI. І, до речі, кросплатформіний UI для Kotlin Multiplatform на iOS все ще в альфі. Native – безпечний і зрозумілий вибір. Але, як я вже сказав, Android довелось би переписувати. І ми віримо, що головне – це не стільки технологія, скільки команда, яка знає домен і розуміє вимоги перед проєктом.

У кросплатформіної розробці є свої переваги. Feature parity, спільний UI, одна команда. Ми дослідили досвід NewBank, наших конкурентів з Бразилії, які обрали brownfield-підхід з Flutter. Попросили наших девелоперів подивитись. Їм фреймворк дуже сподобався. Hot Reload, який працює, декларативний підхід у всьому. Ну, та й загальна простота розробки. І, отже, команда вирішила ризикнути. Так. Отже, ми зупинились на переписуванні всього проєкту з нуля на Flutter. То як тепер цю ідею продати бізнесу? Адже, яким би правильним не було рішення про міграцію і вибір технології, вирішення технічних викликів – це лише частина успіху. Оскільки компанія мала глобальні амбіції при дуже локальному світогляді, необхідна була міграція як продукту, так і процесу.

Тож, з чого ми почали переконання і залучення бізнесу? Почали з проактивної комунікації з менеджментом компанії. Зрозуміло, що насправді всі співвіддники компанії зацікавлені в її успіху. Проте, успіх можна розуміти по-різному. Менеджери середньої ланки, наприклад, бачили його у випуску нових фічей, що для нашої команди інженерів навпаки було б блокером, бо ми тоді б не змогли зосередитись на міграції. Тож, ми мали вирівняти всю компанію, принаймні на наступний рік. Ну, і зрозуміло, що не всі з ентузіазмом поставились до ідеї зупинити розробку нових фічей заради переписування вже добре працюючого функціоналу на новий технологічний стек. Тож, що ми робили далі? Залучали союзників цієї ідеї з числа топ-менеджменту. При цьому не обов'язково одразу цілитись на переконання всіх стейкхолерів. Напевно, навіть наприкінці цього року, в цій міграції в компанії все одно були люди, які вважали цю ініціативу недоречною, але ж це не завадило нам її завершити. Важливо сконцентрувати свої зусилля на окремих людях, що займають ключові позиції. Наприклад, наш СТО і сам був євангелістом ідеї міграції на Flutter, бо він вже мав досвід подібної успішної трансформації в інших компаніях. Справи також сильно пришвидшились, коли наш СІО оголосив, що міграція на Flutter є високим змістом, а не окером компанії. А отже, пріоритетом №1 на наступний рік. Зрозуміло, що подібного роду міграція – це справа не одного місяця, і ми реально потребували підтримки і терпіння від усіх співробітників, яких ця міграція обмежувала.

Отже, було дуже важливо вирівнятися в очікуваннях у короткостроковій і у довгостроковій перспективі, аби не призвести до відчуття відсутності результатів і зростаючого невдоволення. Ми розуміли, що для цього необхідно будувати саме реалістичні очікування і не приховувати ризики, пов'язані з міграцією. Тож, ми побудували доволі високорівневу дорожню карту міграції, і ми усвідомлювали, що попереду ще багато невідомого, і нам потрібна гнучкість, щоб ефективно реагувати на не очікувані обставини. Тож, ми були прозорими щодо того, наголошуючи, що ця дорожня карта була нашим орієнтиром, а не конкретним планом, який може нас обмежувати. Загалом, ми систематично займались евангелізмом, міграцією за межами технічної команди, розповідали про переваги, можливості, які нам надасть нове рішення, і усіляко створювали хайп по всій компанії. Такий легкий градієнт на цьому слайді символізує, що інтенсивність певної активності з часом знижувалась, і її необхідність поступово відпадала. Тобто, комунікацію щодо необхідності і наслідків міграції, із рівною інтенсивністю доводилось проводити по всій компанії аж до самого кінця міграції.

Так, у нас були дві відносно великі команди нативних розробників. Як з ними працювати? Як зробити так, щоб вони не розбіглися? Бо поточні інженери важливі, вони мають доменні знання, але не мають знань у технології. Для першої кросплатформіної команди ми обрали не стільки найкращих iOS чи Android інженерів, скільки технічно сильних спеціалістів з доменними знаннями. Для них це був чудовий шанс проявити себе, і для нас дуже важливим було створити відчуття принадженості. Ми створили Flutter Community of Practice. Це місце, де ті, хто вже має досвід із технологією, може поділитися знаннями, а ті, хто тільки починає перехід на новий фреймворк, може ставити запитання і отримувати відповіді.

Ну, і отримати відповіді, звичайно ж. Загалом, згодом ми створили Академію. Вона була підґрунтям для міграції команди. Академія була одночасно і мобільним додатком, і серією статей та посилань. В основі Академії ось ця roadmap. Я її створив ще до того, як приєднався до компанії. Можете користуватись, вона перевірена. У цій roadmap вже інформація відфільтрована, але її усе одно багато. Потрібен був експерт у технології, який прискорив би навчання. Ще до того, як ми з Анною приєдналися до TIDE, компанія найняла зовнішнього консультанта-експерта. Головна проблема з експертом виявилася у тому, що він розповідав, як можна зробити, а не як треба зробити. Тобто, коли команда питала, а як зробити щось? Він розповідав, як це щось робиться. Тому команда дивилася на різні підходи, оцінювала, експериментувала. І деякі експерименти були довжиною у кілька місяців. Справи пішли тільки, коли компанія найняла експертів у штат. Нас. Ми були зацікавлені у тому, щоб зробити онбордінг команди у технологію якнайшвидше. Але головне, ми сказали всім, що робити. І створили жорсткі рамки. Експерименти скінчилися. Почалась робота.

Отже, в той момент, як команда вже частково опанувала Flutter, ми почали активну роботу над власне самою міграцією. І решта інженерів поступово підтягувалась. Цей процес охоплював багато аспектів і зайняв майже рік. Отже, зараз ми детально розкажемо, які виклики ми мали і що з ними робили. Аби дати вам більше розуміння, що з цим відбувається. Щодо масштабу нашого проєкту. Наприкінці міграції ми мали півтора мільйона рядків Dart коду. І вже на початку усвідомлювали ці перспективи, оскільки мали перед очима приклад нативних додатків.

Ми вирішили мати єдиний монолітний проєкт в одному репозиторії, передбачаючи в альтернативних підходах більше проблем, ніж переваг. Ми також бачали суттєве зростання команди, яка наразі складає більш ніж 50 інженерів. Отже, ми одразу розділили ці додатки. Ми розділилися на 7 підкоманд, кожна з яких спеціалізувалась на своєму домені. Наприклад, інвойси до ведення бухгалтерії, все, що пов'язане з оплатами, кредити і так далі. Я хотів би додати, що 50 мобільних інженерів. Звичайно, у нас інженерів у командах значно більше. Так. І ось всі ці інженери мали розробляти усі свої фічі в єдиному проєкті. Це потребувало від нас дисципліни і культури відповідальності, а також деякої формалізації. Ми створили Building Blocks каталог, де були перелічені усі великі шмати додатку і команда, що за них відповідає. Таким чином, мобільні інженери і члени інших команд завжди знали, куди звернутись в разі виникнення питань відносно якогось функціоналу або для пропозиції змін. Також ми мали окрему Core команду, що несе відповідальність за побудову і підтримку архітектури проєкту. Щоб інженери могли легко переходити між підкомандами і залишатись ефективними, ми максимально підтримували принцип консистентності підходів.

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

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

На початкових етапах ми заборонили інженерам витрачати час на Pixel Perfect Design. Ми доводили UI до юзабельного бета-стану і йшли реалізувати інші фічі. Ми створили обширну дизайн-систему та декілька десятків шаблонів екранів, що вже дозволило нам покрити більшість додатку. Таким чином, нам варто було лише відшліфувати ці шаблони і додати деякі унікальні екрани, щоб привести додаток у стан готовий для кінцевих споживачів. Ми віримо у Test First підхід, особливо у BDD. У TIDE ми використовуємо цей підхід для кожної фічі. Тести є обов'язковими. Ми не писали нового функціоналу, але через те, що backend був імплементований тільки під одну країну, зміни API були неминучі. Backend не робили міграцію.

А отже, імплементація частини API не завжди була у пріоритеті. Щоб не блокувати нашу міграцію, ми узгодили контракти із заздалегідь створеними request-response моделями. З цих моделей та опису API в додатку ми створили mocked backend, який використовувався у BDD тестах та іноді при розробці нового функціоналу. У нас також виникала необхідність докинути зміни в поточний інтерфейс з боку менеджерів та дизайнерів. Як вже говорила Анна, у нас був MVP UI. Для UX все було трошки складніше. Ми заборонили зміни в UX. Втративши інтерес до нашої міграції, дизайнери сфокусувались на новому баченні продукту. У них був час його продумати. Таким чином, коли ми завершили міграцію додатків, ми вже мали беклог та скріни для подальшого розвитку. Важливо відзначити, що під час міграції наші нативні додатки ще були у маркетах. Іноді хтось мав бажання дописати до них невелику фічу. Таким чином, нам довелося це заборонити, і ми займалися виключно виправленням помилок.

Незважаючи на те, що фактично ми не вносили жодних змін у проєкт, було критично важливим вирівнювати підходи між командами. Чи дійсно зараз ми робимо MVP? Чи правильно ми розуміємо, який флоу зараз важливіший? Чи точно наш додаток працює так, як хочуть юзери? Нам був потрібен фідбек, тому всі тестували все. Щоб уникнути питань про те, коли, що і де з'явиться, ми відразу формалізували процес релізу. Це зекономило нам багато часу на комунікацію. Ми вирішили використовувати ring-based підхід. Ring 0 – це додаток. Девелопери та QA, тобто ті, хто шукає баги та помилки. Ring 1 – це менеджери, дизайнери та група, яку зазвичай називають "друзі та сім'я".

Ring 2 – це всі користувачі. Намагаючись впровадити новий додаток якнайшвидше, ми часто зіткнулися з затримками. Частина функціоналу, яка була написана для нативних додатків, але не запущена, стала все більш пріоритетною для бізнесу. Від нас вимагали релізу. Ми вирішили взяти цей функціонал, який ми вже написали, протестували, і віддати його користувачам у вигляді міні-додатків. Це дозволило компанії рости, а користувачам отримати щось новеньке. З технічного погляду це, звісно ж, було складним рішенням. Ми і досі займаємося підтримкою і поступовою депрекацією цих додатків.

Так. Розуміючи, що всі очі команди і компанії були спрямовані на нашу команду, ми повинні були бути максимально ефективними, щоб якнайшвидше показати результат. Тому ми намагались автоматизувати все, що було можливо. Раніше я сказала, що наш проект має півтора мільйона рядків коду. З них один мільйон є згенерованим. Тобто, ми пишемо, наприклад, клас з 20 рядків спеціального коду з анотаціями, запускаємо команду кодогенерації, і отримуємо функціонал ще на 80 рядків шаблонного Dart коду, який інакше довелося б писати вручну. Ось кілька посилань на мої доповіді, де можна ознайомитися з технічними деталями. Ми також створили шаблони для типових частин проекту, з яких за одну команду в консолі генеруємо цілий скелет для нової фічі.

На додачу максимально автоматизували перевірки якості коду. Ми маємо політику нульової толерантності до ворнінгів аналізатора, і налаштували на це відповідні перевірки. Тож девелопери просто не можуть відправити реквест із зауваженнями. Маємо також перевірки на наявність коду або залежностей, які не використовуються, та деякі кастомні правила. Також ми приділили увагу автоматизації рутинних завдань, таких як оновлення критичних залежностей, перевірка ліцензій передодавання нових залежностей, видалення занедбаних бранчів та реквестів. І, зрозуміло, маємо автоматичний запуск тестів, автоматизовану збірку та розповсюдження білдів. Тож, одного довгоочікуваного дня настав реліз. Ми випустили новий додаток прямо поверх нативних додатків. Тобто, одного дня користувачі відкрили додаток і продовжили свої звичні справи, не підозрюючи, що додаток в середині змінився повністю.

Звісно, ми не випустили додаток одразу для всіх. Ми розпочали з однієї платформи для 1% користувачів і почали моніторити, як живе додаток. Під час розробки, коли проєкт був відносно малий, ми використовували Firebase, Аналітику та Crashlytics. Але, звісно, це не підходило для релізу. Тож, ми запустились з Datadog, де налаштували дашборди з ключовими метриками. Ну, і ще з кількома платформами для аналітики. Але для розробників у пріоритеті був Datadog. Кожен наш день починався з огляду того, що відбувається у додатку. У нашій команді всі несуть відповідальність за якість, що віддзеркалює позитивну частину корпоративної культури, що передалася проекту. Таким чином, ми проводили треш-мітинги спочатку кожен день, потім через день, а наразі вони не є обов'язковими. На цих зустрічах обов'язково брали участь всі ліди, інші розробники також приходили, бажаючи бути в курсі. Якщо ми виявляли проблему, створювали робочу групу, ідеальною кількістю учасників якої було не більше двох.

Щодо майбутнього після релізу, нам вдалося запустити його цього року та розширити базу користувачів в Індії. Тепер наша команда налічує понад 5-10 інженерів із серйозною експертизою Flutter. Проект готовий до нових викликів, а ми розглядаємо можливості розширення в інші країни, де необхідно реалізувати свій власний процес реєстрації бізнесу відповідно до місцевого законодавства. Останнім пунктом є найм, де спочатку ми наймали нативних інженерів, але тепер виключно інженерів із високою експертизою у Flutter. У ретроспективі задоволеність інженерів, менеджерів та клієнтів підтверджується. Дякуємо за увагу та готові відповісти на ваші питання.