💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. В каждом задании верен только один вариант. Фрагменты относятся к Scala 3; внешняя библиотека названа прямо в коде или условии.
Вопрос 4 из 30
В контракте темы «Форматы» локальный пример стал частью более крупной системы. Какая трактовка контракта остаётся полной?
reader_{new}(writer_{old})
Формат определяет типы, порядок полей, бинарное представление и возможность неизвестных значений. Пограничный сценарий: совпадение результата на одном наборе данных подтверждает все обещания публичного API.
Формат определяет типы, порядок полей, бинарное представление и возможность неизвестных значений. Пограничный сценарий: Java serialization привязывает данные к классам и небезопасна для недоверенного входа.
Безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов. Пограничный сценарий: Java serialization привязывает данные к классам и небезопасна для недоверенного входа.
Версионирование сообщения должно описывать семантику, а не только номер релиза сервиса. Пограничный сценарий: хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей.
Формат определяет типы, порядок полей, бинарное представление и возможность неизвестных значений. Пограничный сценарий: удаление обязательного поля или повторное использование его номера ломает сохранённые данные.
Вопрос 6 из 30
В теме «Эволюция схем» код компилируется и запускается. Какое утверждение о его контракте остаётся верным?
Scala Эволюция схем: чтение фрагмента Копировать
case class OrderV1(id: String, legacyNote: Option[String])
case class OrderV2(id: String, note: Option[String], source: Option[String])
def migrate(old: OrderV1): OrderV2 =
OrderV2(old.id, old.legacyNote, None)
println(migrate(OrderV1("o-1", Some("gift"))))
Добавление обязательного поля безопасно для старых сообщений: декодер возьмёт значение типа по умолчанию без настройки.
Эволюция схемы безопасна, когда старый reader понимает новые сообщения в допустимых пределах, а новый reader — старые.
Номер версии сообщения полностью описывает миграцию и делает отдельные декодеры старых форматов ненужными.
Воспроизводимость результата требует канонического формата, стабильного порядка и зафиксированных версий схемы/библиотеки.
Версионирование сообщения должно описывать семантику, а не только номер релиза сервиса.
Вопрос 7 из 30
Для темы «Эволюция схем» какой пограничный случай относится к контракту, а не только к стилю записи?
Scala Эволюция схем: изменившийся контекст Копировать
// Дополнительный контекст: Новую версию сообщения прочитал старый потребитель, а доставку повторили после сбоя.
case class OrderV1(id: String, legacyNote: Option[String])
case class OrderV2(id: String, note: Option[String], source: Option[String])
def migrate(old: OrderV1): OrderV2 =
OrderV2(old.id, old.legacyNote, None)
println(migrate(OrderV1("o-1", Some("gift"))))
Неизвестное поле всегда ломает старый декодер, поэтому расширение схемы невозможно без одновременного обновления всех сервисов.
Удаление optional-поля опаснее удаления обязательного поля, потому что старые данные его не содержат.
Хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей.
Java serialization привязывает данные к классам и небезопасна для недоверенного входа.
Удаление обязательного поля или повторное использование его номера ломает сохранённые данные.
Вопрос 8 из 30
При исправлении темы «Эволюция схем» что здесь лучше исправить до объединения изменений?
Scala Эволюция схем: решение на ревью Копировать
case class OrderV1(id: String, legacyNote: Option[String])
case class OrderV2(id: String, note: Option[String], source: Option[String])
def migrate(old: OrderV1): OrderV2 =
OrderV2(old.id, old.legacyNote, None)
println(migrate(OrderV1("o-1", Some("gift"))))
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.
Перед подписью или хешированием применяйте канонизацию и тестируйте эталонные файлы на нескольких версиях runtime.
Добавляйте необязательные поля и значения полей по умолчанию, резервируйте удалённые номера и проверяйте пары версий writer/reader.
Переиспользовать номера удалённых protobuf-полей, чтобы схема не разрасталась зарезервированными значениями.
Хранить одну универсальную функцию миграции, которая молча подставляет значения при любой неизвестной версии.
Проверяйте предметные инварианты и сохраняйте причину отклонения вместе с исходным id сообщения.
Вопрос 14 из 30
В контракте темы «Версионирование» какое решение не превращает частный успешный случай в общее обещание?
Версионирование сообщения должно описывать семантику, а не только номер релиза сервиса. Учитывать границу: даже валидный JSON может вызвать чрезмерную память через огромный массив или глубокую вложенность.
Версионирование сообщения должно описывать семантику, а не только номер релиза сервиса. Учитывать границу: достаточно проверить путь без ошибки, поскольку остальные ветви следуют той же семантике.
Эволюция схемы безопасна, когда старый reader понимает новые сообщения в допустимых пределах, а новый reader — старые. Учитывать границу: одна строка `version=2` без мигратора не объясняет, как читать старые события и что делать с неизвестной версией.
Формат определяет типы, порядок полей, бинарное представление и возможность неизвестных значений. Учитывать границу: удаление обязательного поля или повторное использование его номера ломает сохранённые данные.
Версионирование сообщения должно описывать семантику, а не только номер релиза сервиса. Учитывать границу: одна строка `version=2` без мигратора не объясняет, как читать старые события и что делать с неизвестной версией.
Вопрос 19 из 30
В контракте темы «Безопасное чтение» после изменения окружения команда пересматривает контракт. Какой вариант корректен?
Безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов. Пограничный сценарий: даже валидный JSON может вызвать чрезмерную память через огромный массив или глубокую вложенность.
Безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов. Пограничный сценарий: одна зелёная проверка заменяет отдельные тесты на отмену, повтор и освобождение ресурса.
Безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов. Пограничный сценарий: хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей.
Формат определяет типы, порядок полей, бинарное представление и возможность неизвестных значений. Пограничный сценарий: даже валидный JSON может вызвать чрезмерную память через огромный массив или глубокую вложенность.
Эволюция схемы безопасна, когда старый reader понимает новые сообщения в допустимых пределах, а новый reader — старые. Пограничный сценарий: удаление обязательного поля или повторное использование его номера ломает сохранённые данные.
Вопрос 21 из 30
В теме «Качество данных» проследите типы и порядок вычисления. Какой вывод выдерживает такую проверку?
Scala Качество данных: чтение фрагмента Копировать
case class Temperature(value: BigDecimal, unit: String)
val msg = Temperature(BigDecimal("21.5"), "C")
require(Set("C", "F").contains(msg.unit))
println(msg)
Качество данных включает обязательность, диапазоны, единицы, часовой пояс, кодировку и уникальность ключа события.
Эволюция схемы безопасна, когда старый reader понимает новые сообщения в допустимых пределах, а новый reader — старые.
Номер версии сообщения полностью описывает миграцию и делает отдельные декодеры старых форматов ненужными.
Добавление обязательного поля безопасно для старых сообщений: декодер возьмёт значение типа по умолчанию без настройки.
Безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов.
Вопрос 22 из 30
Какая проблема относится к семантике «Качество данных», а не к стилю кода?
Scala Качество данных: изменившийся контекст Копировать
// Дополнительный контекст: Новую версию сообщения прочитал старый потребитель, а доставку повторили после сбоя.
case class Temperature(value: BigDecimal, unit: String)
val msg = Temperature(BigDecimal("21.5"), "C")
require(Set("C", "F").contains(msg.unit))
println(msg)
Проверка границы должна учитывать, что хэш эквивалентных объектов совпадёт при любом порядке полей и любом формате десятичного числа.
Проверка границы должна учитывать, что синтаксически корректное число не может испортить агрегат независимо от единицы и диапазона.
Проверка границы должна учитывать, что синтаксически корректное сообщение с неверной единицей или временем тихо портит агрегаты.
Проверка границы должна учитывать, что Java serialization привязывает данные к классам и небезопасна для недоверенного входа.
Проверка границы должна учитывать, что хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей.
Вопрос 24 из 30
В контракте темы «Качество данных» какая формулировка учитывает и семантику конструкции, и реальный риск?
Оставить в контракте правило «качество данных включает обязательность, диапазоны, единицы, часовой пояс, кодировку и уникальность ключа события»; проверяемое ограничение — «хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей».
Оставить в контракте правило «качество данных включает обязательность, диапазоны, единицы, часовой пояс, кодировку и уникальность ключа события»; проверяемое ограничение — «если код компилируется, дополнительные проверки вывода типов и поиска `given` не нужны».
Оставить в контракте правило «эволюция схемы безопасна, когда старый reader понимает новые сообщения в допустимых пределах, а новый reader — старые»; проверяемое ограничение — «Java serialization привязывает данные к классам и небезопасна для недоверенного входа».
Оставить в контракте правило «качество данных включает обязательность, диапазоны, единицы, часовой пояс, кодировку и уникальность ключа события»; проверяемое ограничение — «синтаксически корректное сообщение с неверной единицей или временем тихо портит агрегаты».
Оставить в контракте правило «безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов»; проверяемое ограничение — «синтаксически корректное сообщение с неверной единицей или временем тихо портит агрегаты».
Вопрос 29 из 30
В контракте темы «Воспроизводимость результата» новый сценарий не отменяет основное правило, но делает заметной его границу. Какой ответ это отражает?
Безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов; синтаксически корректное сообщение с неверной единицей или временем тихо портит агрегаты.
Воспроизводимость результата требует канонического формата, стабильного порядка и зафиксированных версий схемы/библиотеки; даже валидный JSON может вызвать чрезмерную память через огромный массив или глубокую вложенность.
Эволюция схемы безопасна, когда старый reader понимает новые сообщения в допустимых пределах, а новый reader — старые; хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей.
Воспроизводимость результата требует канонического формата, стабильного порядка и зафиксированных версий схемы/библиотеки; хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей.
Воспроизводимость результата требует канонического формата, стабильного порядка и зафиксированных версий схемы/библиотеки; штатный пример доказывает корректность порядка событий при любой нагрузке.