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» был легко находим без похода к сеньору каждый раз.