Senior React Native Developer — Питання на співбесіді React Native

Поясніть Fabric і TurboModules як систему, а не просто визначення.

Fabric — новий рендерер: він переносить layout і керування view на спільне для платформ C++-ядро, тож JS описує дерево через JSI прямо в це ядро замість асинхронних викликів UIManager через міст, і це вмикає синхронне вимірювання layout, якого стара архітектура не могла робити без round trip. TurboModules — еквівалент для нативних модулів: вони ліниво завантажуються (модуль не створюється, поки не знадобиться вперше, що знижує час старту) і викликаються через прямі C++-байндинги JSI замість циклу серіалізація-черга-десеріалізація мосту. Разом вони прибирають міст як єдине вузьке місце серіалізації, що й було стелею старої архітектури і за часом старту, і за пропускною здатністю UI-потоку.

Як спланувати міграцію зі старої архітектури на New Architecture в продакшн-застосунку?

Почати з аудиту кожного нативного модуля й сторонньої залежності — головний ризик не у вашому коді, а в тому, чи підтримують використовувані бібліотеки New Architecture, бо покинутий нативний модуль може заблокувати всю міграцію. Увімкнути interop-режим там, де фреймворк дозволяє запускати модулі старої архітектури під Fabric/TurboModules, мігрувати поступово, екран за екраном чи фіча за фічею, а не перемикати глобальний прапорець одразу, і закласти реальний час на QA, бо тонкі відмінності в поведінці (тайминг layout, порядок подій) проявляються лише під навантаженням, а не на швидкому smoke-тесті. Ставитися до цього як до інфраструктурного проєкту на кілька спринтів зі своїм планом відкату, а не як до оновлення версії.

Як профілювати проблему продуктивності, яку не видно з боку JS?

Спершу ізолювати, де проблема — у JS-потоці, в нативному UI-потоці чи в реальній нативній роботі (декодування зображень, виклики нативних модулів), — JS-профайлер у Flipper показує лише перше з цього. Нативні інструменти (Time Profiler в Xcode Instruments на iOS, профайлер Android Studio на Android) показують, де нативний потік справді витрачає час, і саме там спливають надмірна глибина ієрархії view, неоптимізоване декодування зображень чи балакучий нативний модуль. JS-потік і UI-потік працюють незалежно, але блокують одне одного в таких точках, як layout і анімація, тому «JS швидкий» і «застосунок плавний» — два різні твердження, які треба перевіряти окремо.

Ви відповідаєте за реліз і розкатку в зростаючій мобільній команді — що це реально включає?

CI/CD-пайплайн (Fastlane, EAS Build чи Bitrise), що видає підписані, версіоновані збірки без людини, яка вручну запускає Xcode чи Android Studio, feature flags, щоб зламану фічу можна було вимкнути без екстреного релізу в стор, і поетапну розкатку (відсоткову на Play Store, групи TestFlight на iOS), щоб погана збірка спершу дійшла до 5% користувачів, а не до 100%. Це також означає володіння політикою OTA-проти-нативного-релізу — рішення, що безпечно випустити миттєво, а що потребує повного циклу ревʼю, — і забезпечення того, щоб crash-репортинг (Sentry, Bugsnag) був привʼязаний до точного коміту й версії бандла, щоб сплеск можна було відстежити до конкретного релізу.

Як масштабувати кодову базу React Native і зростаючу команду в ній одночасно?

Розбити застосунок на модулі чи монорепозиторій із чіткими межами пакетів (Nx, Turborepo чи кастомний workspace), щоб команди володіли вертикальним зрізом, а не всі правили ті самі екрани, і закріпити це lint-правилами чи перевірками графа залежностей, а не лише домовленістю. Стандартизувати заздалегідь те, що на практиці спричиняє найбільше міжкомандне тертя — структуру навігації, вибір керування станом, володіння нативними модулями, компоненти дизайн-системи, — бо впроваджувати стандарт після того, як пʼять команд уже розійшлися по-своєму, коштує набагато дорожче, ніж встановити його одразу. Менторство тут менше про код-ревʼю і більше про те, щоб відповідь «як у нас прийнято робити X» була легко знаходжуваною без походу до сеньйора щоразу.