Как бы вы провели код-ревью чужого кода в React Native?

Процесс код-ревью в React Native-проекте требует системного и многослойного подхода. Он не ограничивается только синтаксисом или логикой компонента — важно учитывать производительность, архитектуру, безопасность, нативные особенности платформ и будущее масштабирование. Приведу детальное описание того, как я бы проводил код-ревью чужого кода в React Native.

1. Общее понимание задачи и контекста

Перед тем как просматривать код, сначала читаю:

  • заголовок и описание PR;

  • связанные задачи (ticket, issue, user story);

  • комментарии, если они есть.

Это позволяет понять, что конкретно должно быть реализовано и какие требования были у задачи (UI, функциональность, производительность, ограничения платформ и т.д.). Без этого сложно оценивать, насколько код решает проблему.

2. Структура проекта и размещение файлов

Проверяю:

  • правильно ли размещены компоненты, хуки, утилиты;

  • не нарушена ли модульная структура (например, components, hooks, services, screens);

  • используются ли общие слои: api, ui, features, entities, shared.

Неправильное размещение кода ведёт к путанице, плохой читаемости и проблемам масштабирования.

3. Архитектура компонентов

  • Компонент решает только одну задачу или делает слишком много?

  • Есть ли разделение на Presentational и Container компоненты?

  • Логика вынесена в хуки или useEffect перегружен?

  • Компонент слишком большой (более 200 строк) — нужно делить.

Также проверяю, не нарушены ли принципы SOLID, особенно Single Responsibility.

4. UI и работа с базовыми компонентами

Проверяю:

  • Использование стандартных компонентов (View, Text, Image, TouchableOpacity) или UI-библиотек.

  • Применение StyleSheet.create (а не inline стилей).

  • Адаптивность: применяется ли Dimensions, useWindowDimensions, flex, percentage?

  • Учет платформенных особенностей (Platform.OS, StatusBar, SafeAreaView).

Наличие хардкода (например, фиксированные height: 800) — сигнал тревоги.

5. Навигация и роутинг

  • Используется ли React Navigation правильно?

  • Навигация реализована декларативно?

  • Передаются ли параметры через route.params, а не через глобальные переменные?

  • Отслеживается ли focus экрана, если требуется?

Также смотрю, не происходят ли лишние ререндеры из-за navigation в props.

6. Состояние и управление данными

  • Правильно ли используется useState, useReducer, useContext или Zustand/Redux?

  • Есть ли избыточное или дублирующее состояние?

  • Не происходит ли утечка данных между экранами?

  • Состояние компонента — локальное или лучше вынести в глобальное?

Неправильное управление состоянием может привести к багам и сложной отладке.

7. Работа с API

Если в PR есть сетевые вызовы:

  • Используется ли fetch, axios, react-query, swr?

  • Разделены ли UI и бизнес-логика API?

  • Есть ли обработка ошибок, loading/success/error состояния?

  • Учитывается ли отмена запросов при размонтировании?

Также проверяю, есть ли повторное использование API-методов или всё пишется в компонентах.

8. Производительность

  • Компоненты мемоизированы (React.memo, useMemo, useCallback)?

  • Избегаются ли лишние ререндеры?

  • FlatList/ScrollView используются по назначению?

  • Применяются ли оптимизации: getItemLayout, initialNumToRender, windowSize?

Производительность особенно важна в списках, видеофидах, анимациях.

9. Типизация

  • Используется ли TypeScript?

  • Типы корректно указаны (вместо any, unknown)?

  • Используются ли интерфейсы и типы компонентов/props?

  • Повторяющиеся типы вынесены в types.ts?

Плохо типизированный код сильно снижает надёжность и усложняет работу в команде.

10. Масштабируемость и переиспользуемость

  • Присутствует ли дублирование компонентов/стилей/логики?

  • Можно ли компонент переиспользовать в других частях приложения?

  • Созданы ли переиспользуемые UI-атомы (например, Button, Card, Input)?

  • Не "захардкожены" ли строки, которые потом будут локализоваться?

Код должен быть гибким для адаптации, локализации и кастомизации.

11. Тестируемость и покрытие

  • Есть ли юнит-тесты на хуки, утилиты?

  • Компоненты покрываются e2e-тестами (detox, Appium)?

  • Если нет — написан ли код так, чтобы его легко было протестировать?

  • Применяются ли моки для API?

Даже если тестов в PR нет, оцениваю тестируемость архитектуры.

12. Читаемость, стиль и форматирование

  • Поддерживается ли единый стиль (eslint, prettier)?

  • Структурированы ли импорты: внешние → внутренние → относительные?

  • Используются ли понятные имена переменных и функций?

  • Разделены ли логические блоки пустыми строками?

Плохая читаемость усложняет ревью и работу в команде.

13. Работа с платформенными модулями

Если код содержит вызовы PermissionsAndroid, Linking, Vibration, Camera, Geolocation:

  • Проверяю правильность использования нативных API

  • Учитываются ли разрешения, ошибки, прерывания

  • Код не крашится при отклонении пользователем разрешения

Также проверяю, не привязаны ли вызовы к платформе, если они не обёрнуты в Platform.OS.

14. Безопасность и уязвимости

  • Используются ли безопасные вызовы (например, _.get для вложенных объектов)?

  • Учитывается ли защита от XSS/инъекций в WebView?

  • Есть ли логика обработки ошибок и fallback UI?

Проверяю также, нет ли утечки токенов, паролей, логов в консоль.

15. Комментарии и документация

  • Присутствуют ли комментарии к сложной логике?

  • Переиспользуемые утилиты или хуки задокументированы?

  • Понятны ли пропсы компонентов, если они сложные?

Избыточные комментарии не нужны, но хорошо написанный JSDoc облегчает чтение кода.

Код-ревью в React Native — это не просто проверка на баги. Это способ совместного улучшения архитектуры, UX и устойчивости всего приложения. Важно давать конструктивную обратную связь, предлагать улучшения и объяснять, почему тот или иной подход лучше.

08-08-2025
Hard 12 просмотров