Code review чеклисты

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

Ключевые пункты проверки:

  • Наличие CLDR-данных для всех поддерживаемых локалей

    • Проверяется, что подключены supplemental данные (likelySubtags, numberingSystems)
    • Присутствуют main данные для каждой используемой локали (en, ru, kk и т.д.)
    • Отсутствуют «тихие» падения на fallback-локаль из-за недостающих сегментов CLDR

  • Единая точка инициализации Globalize

    • Инициализация не размазана по коду
    • Нет повторной загрузки CLDR при переходах между модулями
    • Гарантированно выполняется до первого вызова форматтеров

  • Контроль глобального состояния

    • Отсутствие гонок при асинхронной загрузке CLDR
    • Проверка, что локаль устанавливается предсказуемо, без зависимости от порядка импортов

Типовая ошибка, выявляемая на ревью: использование форматирования до завершения загрузки CLDR, что приводит к падению или возврату «сырого» значения.

Проверки работы с числами и валютами

Форматирование чисел — одна из наиболее чувствительных зон, где Globalize часто используется неправильно.

Контрольный список:

  • Явное указание формата числа

    • Не допускается неявное форматирование через дефолтные настройки
    • Разделители тысяч и десятичные знаки должны соответствовать локали

  • Проверка валютных форматов

    • Используется единый слой форматирования валют
    • Отсутствует ручная конкатенация символов валюты ("1000 ₽")
    • Применяется корректный currency code (ISO 4217)

  • Стабильность округления

    • Проверяется, что округление не зависит от локали
    • Отсутствуют расхождения между UI и бизнес-логикой

  • Граничные случаи

    • Очень большие числа
    • Малые дробные значения
    • Отрицательные значения в финансовых модулях

Частая ошибка: форматирование числа вне Globalize с последующей локализацией только символа валюты, что ломает региональные правила отображения.

Проверки дат и времени

Работа с датами в Globalize требует строгого соответствия локали и формату отображения.

Пункты ревью:

  • Использование единых шаблонов

    • Запрещены ручные Date.toString() или кастомные форматтеры
    • Все отображения проходят через Globalize date formatter

  • Согласованность временных зон

    • Проверяется, что UI и сервер используют согласованные timezone-правила
    • Отсутствуют скрытые преобразования без явного указания зоны

  • Форматы дат

    • Короткие и длинные форматы соответствуют локали
    • Проверяется корректность порядка: день/месяц/год

  • Временные интервалы

    • Проверяется корректность отображения длительности (например, «2 часа 15 минут»)
    • Нет «ручной» конкатенации строк

  • Граничные даты

    • Переходы через сутки
    • Переходы через месяц/год
    • Корректность при epoch-boundary значениях

Типовая проблема: использование new Date() без нормализации в сочетании с локализованным форматированием, что даёт разные результаты на клиенте и сервере.

Проверки локализованных сообщений и plural rules

Globalize активно используется для работы с pluralization rules и message formatting.

Контрольный список:

  • Корректное использование CLDR plural rules

    • Нет хардкода условий вида count === 1 ? ... : ...
    • Используются правила локали, а не английская логика

  • Полнота форм сообщений

    • Все формы plural (one, few, many, other) присутствуют там, где требуется
    • Отсутствуют «заглушки» на уровне UI

  • Согласованность ключей сообщений

    • Нет дублирования ключей между модулями
    • Проверяется единая структура message bundles

  • Fallback поведение

    • Определено, что происходит при отсутствии перевода
    • Нет скрытых возвратов на английский без логирования

  • Интерполяция значений

    • Проверяется экранирование переменных
    • Нет прямой вставки пользовательских данных без обработки

Частая ошибка: смешивание plural-логики Globalize с ручной интерполяцией строк, что приводит к некорректным формам в славянских языках.

Проверки архитектуры локализации

Код-ревью должно выявлять архитектурные нарушения, которые усложняют поддержку интернационализации.

Ключевые моменты:

  • Разделение ответственности

    • Форматирование не смешивается с бизнес-логикой
    • Локализация вынесена в отдельный слой

  • Отсутствие дублирования форматтеров

    • Один источник truth для чисел, дат и сообщений
    • Нет локальных «самодельных» wrapper-ов вокруг Globalize

  • Модульность загрузки локалей

    • Lazy-loading языковых пакетов
    • Отсутствие монолитной загрузки всех локалей сразу

  • Предсказуемость API

    • Единый интерфейс для форматирования
    • Нет расхождений между разными частями приложения

Проверки производительности

При использовании Globalize важно учитывать стоимость операций форматирования.

Чеклист:

  • Кэширование форматтеров

    • Форматтеры чисел/дат не создаются на каждый рендер
    • Используется переиспользование экземпляров

  • Отсутствие лишних пересборок CLDR

    • CLDR не загружается повторно при смене компонента
    • Нет динамического импорта в горячих путях UI

  • Минимизация операций в render path

    • Форматирование вынесено за пределы render при возможности
    • Нет форматирования внутри циклов без необходимости

  • Профилирование тяжелых страниц

    • Проверяется влияние локализации на FPS
    • Выявляются «узкие места» при массовом форматировании списков

Типовая ошибка: создание нового formatter-а внутри React/Vue render-функции, что приводит к деградации производительности.

Проверки согласованности между клиентом и сервером

Локализация часто ломается на границе frontend/backend.

Контроль:

  • Единые правила форматирования

    • Сервер и клиент используют одинаковые CLDR версии
    • Нет расхождений в форматах чисел и дат

  • Сериализация данных

    • Числа не приходят уже «отформатированными» с сервера
    • Передаются только raw значения

  • Детерминированность вывода

    • Одинаковый input → одинаковый output на всех средах
    • Нет зависимости от системной локали сервера

  • Тестирование контрактов

    • Проверяются API-ответы с разными локалями
    • Валидация edge-case значений

Проверки качества переводов и ключей

Хотя Globalize не занимается переводами напрямую, он часто используется совместно с message bundles.

Чеклист:

  • Отсутствие «битых» ключей

    • Все ключи присутствуют во всех локалях
    • Нет орфографических расхождений в ключах

  • Контроль длины строк

    • UI не ломается при увеличении длины текста
    • Проверяются расширенные формы (немецкий, финский и т.д.)

  • Семантическая корректность

    • Переводы соответствуют контексту, а не буквальному значению
    • Нет смешения формального/неформального стиля в одной локали

Проверки устойчивости к расширению локалей

Система должна выдерживать добавление новых языков без переписывания логики.

Проверяется:

  • Отсутствие хардкода локалей в бизнес-логике
  • Использование динамического выбора locale
  • Поддержка языков с нестандартными правилами pluralization
  • Корректная обработка RTL-языков (если применимо)

Типовой анти-паттерн: if (locale === 'ru') { ... } else { ... }, который блокирует масштабирование.

Проверки тестируемости локализации

Код-ревью должно выявлять возможность автоматического тестирования локализационных сценариев.

Пункты:

  • Возможность подмены CLDR в тестах
  • Детектирование отсутствующих ключей на CI
  • Snapshot-тестирование форматированных значений
  • Изоляция локализационного слоя от UI-компонентов

Критичная проблема: невозможность воспроизвести одинаковый результат форматирования в тестовой среде из-за неполной загрузки CLDR.

Оглавление