Публикувано на: 10 август, 2021Да мигрираш архитектура, изградена от десетки разнородни технологии и да я придвижваш към модерна консолидация – това е една от най-сложните, но и най-интересни софтуерни задачи. Момент, в който опитът се среща с въображението, а екипната работа взема връх. Залогът, разбира се, е сериозен – става дума за IT архитектурата на Fourth, едно от най-популярните приложения в световен мащаб, което се използва за оптимизацията на работата в ресторантите и хотелите.
Ето какво ни разказаха Георги Христов, Head of Software Engineering, и Стоян Екупов, Software Architect (Mobile), за тяхната работа по архитектурата на платформата и миграцията към React/React Native; процес, който ще бъде интересен за всеки програмист с желание за предизвикателни и интересни проекти.
Какво представлява платформата на Fourth и как тя подпомага работещите в ресторантския и хотелиерски бизнес?
Георги: Платформата на Fourth представлява богат набор от бизнес приложения, които са на разположение в облачна инфраструктура и могат да бъдат достъпени с лекота от мобилно устройство или компютър, от всеки мениджър или служител на ресторант или хотел, намиращи се във всяка точка по света.
Решенията ни помагат на мениджъра да управлява с лекота и повишена успеваемост гръбнака на такъв тип бизнес – работата на служителите и необходимия на ежедневна база инвентар, така че клиентите им да получат услуга от най-високо ниво. От друга страна, приложенията ни помагат на самите служители в хотел или ресторант да следят и контролират собствената си ангажираност и всички основни дейности и приноси на работното място.
Към момента платформата на Fourth се ползва от 120 000 локации по цял свят. Пояснявам, че в общия случай една ресторантска верига включва около 50-100 локации. Повечето вериги, които обслужваме, са именно от този тип – в тях най-често работят от 3000 до 6000 служители. Работим и с по-големи вериги, имащи по над 500 локации, съответно ангажиращи до 50 000 служители. Можем да твърдим, че крайните клиенти, ползващи Fourth, са над 2 милиона.
Как улеснявате и оптимизирате работата на заетите в ресторантьорския бизнес с вашето приложение? Можем ли да изчислим приноса на Fourth в административно време, часове труд, заплати, организационен ресурс?
Head of Software Engineering
Георги: Приложението помага на мениджърите да постигнат с по 5-10 % по-високи бизнес резултати и им пести много ценно време. Служителите, от своя страна, на практика могат да управляват целия си начин на работа – кандидатстване, onboarding, чек листи, управление на смени и въобще всички процедури, които трябва да се спазват на работното място.
Fourth също помага и за изчислението на заплатата спрямо заработката – успяваме да спомогнем за пресмятането на справедливото заплащане, така че да избегнем грешките, предизвикани от човешкия фактор. Освен това, служителите, които използват приложението, разполагат и със социална мрежа, в която могат да публикуват, споделят снимки и видеа, да се информират взаимно за важни неща и събития. Накратко, ние им помагаме да общуват по-лесно и удобно по теми, свързани с работата им.
Какво представлява текущата ви web и мобилна архитектура на платформата и какви са плановете ви за развитие?
Георги: Текущата ни web и мобилна архитектура се базира на разнородни технологии, които са били най-модерните през изминалите две десетилетия, т.е. откакто предлагаме тази услуга към нашите клиенти. В тях може да срещнете технологии като Classic ASP, .NET Web Forms, ASP.NET, Windows Forms, Cordova, Ionic, Angular.js, Ember.js, Android и Objective C, както и много други.
В архитектурно отношение имаме големи монолитни имплементации на около 10 различни core системи, които представляват милиони редове код – бих казал, че това са доста database комплексни и тежки имплементации на бази данни.
Посоката, в която вървим в последните 5 години, е технологично модернизиране към .NET Core и React, както и използване на архитектура базирана на microservices, така че с времето да се разделим с остарелите технологии и тежките за поддръжка и развитие монолитни системи.
Стоян: Искам да допълня, че архитектурата ни е хибридна, базирана на Cordova, при която web приложенията се изпълняват в web view, в съответното мобилно приложение за Android или iOS, a потребителският интерфейс наподобява естествения такъв за Android или iOS. Тази архитектура е удобна, тъй като дава възможност да се използват едни и същи приложения в desktop и в мобилна среда, което значително улеснява развитието и поддръжката им от техните екипи.
Software Architect (Mobile)
Същевременно, достъпът до стандартните мобилни функции (като камера, push нотификации, файлова система) разчита на Cordova plugin-и, някои от които се налага да модифицираме за нашите нужди. Поддръжката на тези модификации създава допълнителен ангажимент за мобилните разработчици.
Еволюцията се изразява в стандартизиране на React и React Native, като технологии за изграждане на нови приложения; миграция на текущите AngularJS и Ember приложения към React; пренаписване на текущите Android и iOS приложения с React Native.
Стандартизацията към React/React Native ще ни даде възможност да решим проблема със споделяне на код, който имплементира обща бизнес логика, между web и мобилните приложения, като същевременно ще можем да използваме по-пълно стандартните мобилни функции и ще изградим по-естествено потребителско преживяване в web и в мобилна среда.
Loading …
Пловдив
Hybrid
А сега конкретно: как правите миграция от AngularJS и Ember frameworks към архитектура, базирана на React? Какъв е подходът ви и какви са трудностите?
Георги: През последните 2 години взехме решение да консолидираме всички JavaScript frameworks, които използваме към React. Основна причина да се спрем на React е нашата убеденост, че това не е просто поредният JavaScript framework, който би могъл да стане ненужен. Вярваме, че начинът, по който React ни предпоставя да пишем и моделираме код, би ни позволил във времето да надграждаме с лекота, знаейки че сме продуктова софтуерна компания на 20 годишна възраст, с голям мащаб на кода, изграждащ потребителския ни интерфейс. Оценяваме и гъвкавостта му за използване от всякакви устройства.
Стоян: Използването на React като стандарт ще даде възможност на екипите да бъдат независими от конкретен framework и да подберат съпътстващи библиотеки, които най-добре съответстват на нуждите на техните приложения.
Първата миграция, която започнахме, беше на ключовото web приложение в платформата, което служи като стартова “площадка” за останалите приложения, но има и функциите на корпоративна социална мрежа, служебна комуникация, както и портал за служебна документация.
Приложението беше изградено с AngularJS – версия от преди няколко години и вече беше претърпяло неуспешни опити за upgrade. Гъвкавостта на React да се интегрира в други платформи ни даде възможност да планираме поетапна миграция, без това да нарушава графика за разработка на нови функционалности и поддръжката на съществуващите. Подходът за миграция, който избрахме, може да се нарече „отвън-навътре“ – подготвяме React обвивка, в която работи Angular приложението и постепенно заместваме отделни екрани с React версиите им.
Подходът проработи според очакванията ни. Планът за развитие на приложението не се наруши и към момента миграцията е пред завършване. Успоредно с това, работим по подход за миграция на EmberJS приложенията ни.
Ще разкажете ли повече и за начина, по който става миграцията от хибридна архитектура, използваща Cordova, към архитектура, базирана на React Native?
Стоян: Миграцията от хибридна към естествена (native) мобилна архитектура се наложи главно поради проблемите с поддръжката на използваните Cordova plugin-и. Множеството модификации, правени през годините, както и спряната поддръжка и развитие от разработчиците на някои от plugin-ите, направи неефективни опитите за тяхното актуализиране или подмяна.
Тъй като мобилното приложение се използва от стотици хиляди потребители, а web приложението се изпълнява в web-view, ъпгрейдът от Cordova базираната версия към React Native версията за крайните потребители няма да се случи в един момент, а ще има период, в който ще работят и двете версии. Този период може да е продължителен, в зависимост от това кога потребителите ще решат да извършват upgrade. Това наложи при миграцията да се използва Strangler pattern, при който се разработва обща фасада, която обработва и насочва комуникацията от web приложенията към Cordova или React Native, разпознавайки средата, в която работи самото web приложение. Към настоящия момент, миграцията е във финалната си фаза. Предстои вътрешно тестване, a след това beta-тестване с избрани клиенти.
Във Fourth разработвате и собствена компонентна библиотека. Каква е визията ви за нея и как се прилага тя?
Георги: Компонентата библиотека ни трябва по две основни причини. Първата и най-важната е изграждането на консистентен облик и UX, видим пред нашите клиенти по целия свят. Втората причина е улесняването и ускоряването на процеса по изграждане на нов потребителски интерфейс. Към момента библиотеката е базирана на React като технология и съдържа няколко десетки преизползваеми потребителски контроли, но това е само началото. Стремежът ни е мащабът да се разрасне до framework ниво, което да покрие нуждите на всички съществуващи компоненти и продукти на компанията през следващите няколко години.
Стоян: Мога да допълня, че унифицирането на потребителския интерфейс и създаването на по-удобни пътища за навигация между отделните приложения е част от инициативата за редизайн на платформата, водена от UX екипа, в който работя и аз.
На пръв поглед изглежда нетипично в UX екип от UI дизайнери да има технически архитекти, но в нашия случай това улеснява изграждането на визия за бъдещата архитектура на мобилни и web приложения, както и координацията на усилията по прилагането на тази визия. Ежедневната комуникация с UI дизайнерите от моя страна и от страна на колегата ми в САЩ, който е Front-end архитект, ни дава възможност да сме наясно с взетите решения и избраните концепции, както и да дадем мнение по възможностите за техническа реализация.
Проектите ви звучат доста интересно и предизвикателно. Разкажете малко повече за очакванията към кандидатите за работа във Fourth. Какво професионално развитие би им донесла работата при вас?
Георги: Нашите очаквания към кандидатите са да имат желание за постоянно развитие и усъвършенстване на уменията си, допринасяйки към успеха на екипа. Във вече шест годишната си история в България се гордеем с вътрешното израстване на хората в целия диапазон – от стажантски позиции, до централни за компанията високотехнически и нетехнически роли. Това, което е важно за нас, е да подкрепим хората в тяхното развитие и да ги подготвим за всяка една роля в компанията, която те си представят като следващата стъпка в професионалната им кариера. Бих казал, че имаме много успешни истории до момента и продължаваме да ги създаваме.
Всеки софтуерен инженер би получил много ценен опит от работата при нас – заради всички технологии, за които вече разказахме и поради причината, че ги прилагаме на много високо ниво.
Стоян: Изискванията ни към кандидатите за front end developer от технологична страна са стандартни за React позициите: практически опит с React (бонус е опитът в разработка на мобилни приложения с React Native или друго) и познаване на модерните шаблони при писане на код с React; задълбочено познаване на HTML и CSS, JavaScript (с всичките му особености).
Обръщаме голямо внимание на личностните качества, като очакваме да видим желание за придобиване на нови познания; умения за анализ и решаване на проблеми; готовност за работа в среда, изискваща вземане на решения (за избор на библиотеки, архитектури, начин на имплементация) и съгласуване на решенията в екипа; отзивчивост към критични мнения; умение за разбиране на бизнес контекста, в който ще работи.
Когато видим потенциал за развитие в кандидата, можем да пренебрегнем евентуални негови пропуски в техническите познания.
Георги и Стоян споделят, че в момента Fourth търсят опитни React, .Net и Full Stack разработчици. Пълния списък със свободни позиции в компанията можеш да видиш в Job Board-a на DEV.BG.
