💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. В каждом задании верен только один вариант. Фрагменты относятся к Scala 3; внешняя библиотека названа прямо в коде или условии.
Вопрос 4 из 30
В контракте темы «Форматы» локальный пример стал частью более крупной системы. Какая трактовка контракта остаётся полной?
reader_{new}(writer_{old})
Формат определяет типы, порядок полей, бинарное представление и возможность неизвестных значений. Пограничный сценарий: удаление обязательного поля или повторное использование его номера ломает сохранённые данные.
Версионирование сообщения должно описывать семантику, а не только номер релиза сервиса. Пограничный сценарий: хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей.
Формат определяет типы, порядок полей, бинарное представление и возможность неизвестных значений. Пограничный сценарий: совпадение результата на одном наборе данных подтверждает все обещания публичного API.
Формат определяет типы, порядок полей, бинарное представление и возможность неизвестных значений. Пограничный сценарий: Java serialization привязывает данные к классам и небезопасна для недоверенного входа.
Безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов. Пограничный сценарий: Java serialization привязывает данные к классам и небезопасна для недоверенного входа.
Вопрос 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"))))
Удаление обязательного поля или повторное использование его номера ломает сохранённые данные.
Хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей.
Удаление optional-поля опаснее удаления обязательного поля, потому что старые данные его не содержат.
Неизвестное поле всегда ломает старый декодер, поэтому расширение схемы невозможно без одновременного обновления всех сервисов.
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"))))
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.
Добавляйте необязательные поля и значения полей по умолчанию, резервируйте удалённые номера и проверяйте пары версий writer/reader.
Проверяйте предметные инварианты и сохраняйте причину отклонения вместе с исходным id сообщения.
Перед подписью или хешированием применяйте канонизацию и тестируйте эталонные файлы на нескольких версиях runtime.
Хранить одну универсальную функцию миграции, которая молча подставляет значения при любой неизвестной версии.
Переиспользовать номера удалённых protobuf-полей, чтобы схема не разрасталась зарезервированными значениями.
Вопрос 14 из 30
В контракте темы «Версионирование» какое решение не превращает частный успешный случай в общее обещание?
Эволюция схемы безопасна, когда старый reader понимает новые сообщения в допустимых пределах, а новый reader — старые. Учитывать границу: одна строка `version=2` без мигратора не объясняет, как читать старые события и что делать с неизвестной версией.
Версионирование сообщения должно описывать семантику, а не только номер релиза сервиса. Учитывать границу: одна строка `version=2` без мигратора не объясняет, как читать старые события и что делать с неизвестной версией.
Формат определяет типы, порядок полей, бинарное представление и возможность неизвестных значений. Учитывать границу: удаление обязательного поля или повторное использование его номера ломает сохранённые данные.
Версионирование сообщения должно описывать семантику, а не только номер релиза сервиса. Учитывать границу: даже валидный JSON может вызвать чрезмерную память через огромный массив или глубокую вложенность.
Версионирование сообщения должно описывать семантику, а не только номер релиза сервиса. Учитывать границу: достаточно проверить путь без ошибки, поскольку остальные ветви следуют той же семантике.
Вопрос 19 из 30
В контракте темы «Безопасное чтение» после изменения окружения команда пересматривает контракт. Какой вариант корректен?
Безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов. Пограничный сценарий: хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей.
Эволюция схемы безопасна, когда старый reader понимает новые сообщения в допустимых пределах, а новый reader — старые. Пограничный сценарий: удаление обязательного поля или повторное использование его номера ломает сохранённые данные.
Формат определяет типы, порядок полей, бинарное представление и возможность неизвестных значений. Пограничный сценарий: даже валидный JSON может вызвать чрезмерную память через огромный массив или глубокую вложенность.
Безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов. Пограничный сценарий: даже валидный JSON может вызвать чрезмерную память через огромный массив или глубокую вложенность.
Безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов. Пограничный сценарий: одна зелёная проверка заменяет отдельные тесты на отмену, повтор и освобождение ресурса.
Вопрос 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)
Проверка границы должна учитывать, что синтаксически корректное сообщение с неверной единицей или временем тихо портит агрегаты.
Проверка границы должна учитывать, что синтаксически корректное число не может испортить агрегат независимо от единицы и диапазона.
Проверка границы должна учитывать, что хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей.
Проверка границы должна учитывать, что Java serialization привязывает данные к классам и небезопасна для недоверенного входа.
Проверка границы должна учитывать, что хэш эквивалентных объектов совпадёт при любом порядке полей и любом формате десятичного числа.
Вопрос 24 из 30
В контракте темы «Качество данных» какая формулировка учитывает и семантику конструкции, и реальный риск?
Оставить в контракте правило «эволюция схемы безопасна, когда старый reader понимает новые сообщения в допустимых пределах, а новый reader — старые»; проверяемое ограничение — «Java serialization привязывает данные к классам и небезопасна для недоверенного входа».
Оставить в контракте правило «безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов»; проверяемое ограничение — «синтаксически корректное сообщение с неверной единицей или временем тихо портит агрегаты».
Оставить в контракте правило «качество данных включает обязательность, диапазоны, единицы, часовой пояс, кодировку и уникальность ключа события»; проверяемое ограничение — «хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей».
Оставить в контракте правило «качество данных включает обязательность, диапазоны, единицы, часовой пояс, кодировку и уникальность ключа события»; проверяемое ограничение — «синтаксически корректное сообщение с неверной единицей или временем тихо портит агрегаты».
Оставить в контракте правило «качество данных включает обязательность, диапазоны, единицы, часовой пояс, кодировку и уникальность ключа события»; проверяемое ограничение — «если код компилируется, дополнительные проверки вывода типов и поиска `given` не нужны».
Вопрос 29 из 30
В контракте темы «Воспроизводимость результата» новый сценарий не отменяет основное правило, но делает заметной его границу. Какой ответ это отражает?
Эволюция схемы безопасна, когда старый reader понимает новые сообщения в допустимых пределах, а новый reader — старые; хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей.
Воспроизводимость результата требует канонического формата, стабильного порядка и зафиксированных версий схемы/библиотеки; хэш JSON меняется при эквивалентных данных, если сериализатор не фиксирует порядок полей.
Воспроизводимость результата требует канонического формата, стабильного порядка и зафиксированных версий схемы/библиотеки; даже валидный JSON может вызвать чрезмерную память через огромный массив или глубокую вложенность.
Безопасное чтение ограничивает размер, глубину, допустимые типы и время декодирования до создания доменных объектов; синтаксически корректное сообщение с неверной единицей или временем тихо портит агрегаты.
Воспроизводимость результата требует канонического формата, стабильного порядка и зафиксированных версий схемы/библиотеки; штатный пример доказывает корректность порядка событий при любой нагрузке.