💡 Инструкция: Выберите один ответ из пяти. В тесте 30 вопросов, на работу отведено 85 минут. В каждом задании верен только один вариант. Часть фрагментов намеренно содержит ошибку: определяйте её по коду, а не по внешнему виду ответа. После завершения откроются общий результат, 6 тематических шкал и подробные объяснения.
Вопрос 13 из 30
Как восстановить полезный стек, если адреса не символицированы и нет dSYM точной сборки?
Swift Журнал аварийного завершения · фрагмент для разбора Копировать
// Адреса стека не символицированы, dSYM для точной сборки отсутствует.
Исправление — оставить контракт прежним и учитывать, что символикация не зависит от точного dSYM конкретной сборки.
Достаточно изменить работу с `dSYM`, исходя из того, что последняя строка стека всегда является первопричиной аварийного завершения.
Найти архив и dSYM той же UUID, символицировать все потоки и связать crash с версией, устройством и действиями пользователя.
Нужно адаптировать только вызов `dSYM`, поскольку force unwrap допустим на данных сервера, если счастливый путь покрыт тестом.
Сигнатуру можно не менять, если считать, что глобальная коллекция диагностируемых объектов не меняет их время жизни.
Вопрос 20 из 30
На какой границе входов, владения или времени жизни результат может стать другим? Не упускайте из виду следующее: связь стека потока с контрактом UI и общим состоянием.
Контрпример появляется, когда force unwrap допустим на данных сервера, если счастливый путь покрыт тестом.
То, что сбой произошёл на главном потоке, не доказывает, что гонка началась там; повреждение могло прийти из общего состояния.
То, что сбой произошёл на главном потоке, доказывает, что гонка началась там; повреждение могло прийти из общего состояния.
Пограничный случай связан с тем, что последняя строка стека всегда является первопричиной аварийного завершения.
Граница применимости проходит там, где символикация не зависит от точного dSYM конкретной сборки.
Вопрос 29 из 30
Какой подход делает неправильное использование заметным раньше? Здесь оценивается воспроизводимость и многоуровневая проверка исправления.
Диагностика должна связывать событие, состояние, версию данных и параллельность эффектов; иначе команда чинит ближайшую строку, а не причину.
Диагностика должна связывать событие, состояние, версию данных и последовательность эффектов; иначе команда чинит ближайшую строку, а не причину.
Диагностика не должна связывать событие, состояние, версию данных и последовательность эффектов; иначе команда чинит ближайшую строку, а не причину.
Архитектуру стоит строить из предположения, что `@MainActor` можно безопасно обойти через `@unchecked Sendable`.
Для устойчивого решения достаточно принять, что глобальная коллекция диагностируемых объектов не меняет их время жизни.
Вопрос 30 из 30
Какой выбор лучше удерживает баланс между ясностью, проверяемостью и стоимостью выполнения? Проверяется наблюдаемость без превращения диагностики в новый дефект.
Для устойчивого решения достаточно принять, что `@MainActor` можно безопасно обойти через `@unchecked Sendable`.
Архитектура надёжности включает crash reporting, символы, feature flags, безопасные миграции и возможность быстро отключить проблемный путь.
Архитектура надёжности включает crash reporting, символы, feature flags, безопасные миграции и вознельзясть быстро отключить проблемный путь.
Архитектуру стоит строить из предположения, что последняя строка стека всегда является первопричиной аварийного завершения.
При расширении системы нужно опираться на то, что символикация не зависит от точного dSYM конкретной сборки.