GO Go · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Пакеты и модули

Проверяет границы пакета, экспорт имён, назначение `go.mod`, выбор версии и воспроизводимую работу с зависимостями. В тесте 20 вопросов, из них 12 требуют чтения кода, команд или диагностических фрагментов. Задания опираются на устойчивые правила современного Go; если поведение зависит от версии, это оговорено в самом вопросе.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 20 вопросов отведено 55 минут. В каждом вопросе верен только один вариант. После завершения вы увидите общий результат и результаты по 4 тематическим шкалам с объяснениями и практическими рекомендациями.

Вопрос 1 из 20

Команда проверяет решение по теме «Устройство пакета». Какое описание результата совпадает с правилами Go?

// Фрагмент для трассировки.
package store

type Item struct{ ID int }
func Find(id int) Item { return Item{ID:id} }

Функции достаточно `io.Reader`, если она только читает поток; требование конкретного файла излишне сужает применение. Новая опция через функциональный параметр позволяет расширить конструктор без изменения старых вызовов. Файлы `a.go` и `b.go` с `package store` компилируются вместе, даже если объявления распределены между файлами. Вызывающий код распознаёт `ErrNotFound` сквозь обёртку и отдельно выводит путь операции. Компилятор выводит `T=int` из аргументов `Min(3,5)`, если ограничение допускает `int`.

Вопрос 2 из 20

Перед публикацией кода по теме «Устройство пакета» нужно уточнить контракт. Какая правка устраняет причину, а не маскирует её проявление?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package store

type Item struct{ ID int }
func Find(id int) Item { return Item{ID:id} }

Принимать минимальный интерфейс, а возвращать конкретный тип, когда вызывающему коду полезны его возможности. Использовать конкретный тип или параметр типа, если допустимые значения известны заранее; `any` оставлять для действительно открытых границ. Добавлять исполняемые Example для основного пути и разделять обязательные гарантии от деталей реализации. Определять интерфейс рядом с потребителем и проверять соответствие через `var _ Interface = (*Type)(nil)` там, где это помогает сопровождению. Разделять пакеты по устойчивой ответственности, а не создавать пакет на каждый тип или технический слой без необходимости.

Вопрос 3 из 20

В рабочем примере по теме «Устройство пакета» важно отделить гарантию от догадки. Что именно гарантирует Go в этой ситуации?

// Определите правило Go, которое объясняет результат.
package store

type Item struct{ ID int }
func Find(id int) Item { return Item{ID:id} }

Все обычные `.go`-файлы одного каталога должны объявлять один пакет; пакет задаёт единицу компиляции и повторного использования. Параметр типа объявляется в квадратных скобках и получает конкретный тип при инстанцировании функции или типа. Ограничение задаёт множество допустимых типов и доступные операции; `comparable` разрешает `==` и использование как ключа карты. Комментарий экспортированного имени объясняет назначение, контракт, ошибки и конкурентную безопасность, а не повторяет сигнатуру. Тип реализует интерфейс автоматически, если его набор методов содержит все методы интерфейса; отдельного объявления `implements` нет.

Вопрос 4 из 20

Фрагмент относится к теме «Устройство пакета». Что нельзя автоматически переносить на похожий код?

Добавление метода в опубликованный интерфейс ломает все внешние реализации этого интерфейса. Нельзя использовать утверждение типа непосредственно для обычного значения параметра типа без преобразования к интерфейсу. Интерфейс с типизированным `nil`-указателем внутри не равен `nil`. Утверждение проверяет динамический тип интерфейсного значения, а не выполняет произвольное преобразование типов. Тестовый файл может использовать пакет `store_test`, чтобы проверять только экспортированный контракт.

Вопрос 5 из 20

На ревью разбирают тему «Устройство пакета». Как оценить этот подход для производственного кода?

Крупный пакет проще навигации до определённого размера, а мелкие пакеты снижают связанность лишь при реальной границе ответственности. Малый контракт улучшает совместимость, но интерфейс ради одной реализации внутри пакета может быть лишним слоем. Строгая совместимость снижает стоимость обновления, но иногда оправдана новая крупная версия с ясной миграцией. Малый интерфейс улучшает заменяемость, но бессмысленное дробление без реальных потребителей создаёт лишние имена. Обобщения дают статическую безопасность коллекций, а интерфейсы лучше выражают открытый набор реализаций поведения.

Вопрос 6 из 20

Перед публикацией кода по теме «Экспорт» нужно уточнить контракт. Какой итог можно предсказать без пробного запуска?

// Фрагмент для трассировки.
package user

type User struct {
    Name string
    age int
}

После `var x any = 3` динамический тип интерфейса — `int`, а само значение не становится нетипизированным. Тип `Age` допускается ограничением `~int`, хотя это отдельный именованный тип. Тип `File` удовлетворяет `Namer`, потому что имеет метод `Name() string` с точной сигнатурой. Функции достаточно `io.Reader`, если она только читает поток; требование конкретного файла излишне сужает применение. Поле `Name` доступно из другого пакета, а поле `age` — нет.

Вопрос 7 из 20

В рабочем примере по теме «Экспорт» важно отделить гарантию от догадки. Как изменить решение, не ломая его исходную задачу?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package user

type User struct {
    Name string
    age int
}

Экспортировать минимальный устойчивый контракт и оставлять детали реализации неэкспортируемыми. Планировать расширение через структуры параметров или опции, поддерживать старый контракт в пределах крупной версии. Использовать конкретный тип или параметр типа, если допустимые значения известны заранее; `any` оставлять для действительно открытых границ. Принимать минимальный интерфейс, а возвращать конкретный тип, когда вызывающему коду полезны его возможности. Не обобщать функцию, если конкретная версия короче, яснее и не дублируется в реальных местах.

Вопрос 8 из 20

Фрагмент относится к теме «Экспорт». Какое утверждение остаётся верным на всех поддерживаемых платформах?

// Определите правило Go, которое объясняет результат.
package user

type User struct {
    Name string
    age int
}

Комментарий экспортированного имени объясняет назначение, контракт, ошибки и конкурентную безопасность, а не повторяет сигнатуру. Идентификатор экспортируется, если начинается с заглавной Unicode-буквы и объявлен на подходящем уровне. Тип реализует интерфейс автоматически, если его набор методов содержит все методы интерфейса; отдельного объявления `implements` нет. Параметр типа объявляется в квадратных скобках и получает конкретный тип при инстанцировании функции или типа. Добавление экспортированной функции обычно совместимо, а изменение сигнатуры, удаление имени или добавление метода в интерфейс ломает пользователей.

Вопрос 9 из 20

На ревью разбирают тему «Экспорт». Какое условие нельзя считать выполненным по умолчанию?

Метод с получателем `*T` входит в набор методов `*T`, но не обязательно `T`. Нельзя использовать утверждение типа непосредственно для обычного значения параметра типа без преобразования к интерфейсу. Обещание конкретного порядка карты или внутреннего кеша превращает случайную деталь в совместимость. Интерфейс с типизированным `nil`-указателем внутри не равен `nil`. Экспортированное поле структуры нельзя позднее скрыть без нарушения совместимости пользователей пакета.

Вопрос 10 из 20

В разделе «Экспорт» показан конкретный случай. Какой вариант честно называет и преимущество, и издержку?

Меньшая публичная поверхность легче эволюционирует, но чрезмерное сокрытие может вынудить создавать громоздкие обёртки. Структурированная ошибка богаче, но простой sentinel легче для редкого бинарного случая. Хорошая документация уменьшает неверное использование, но избыточное описание реализации быстро устаревает. Малый интерфейс улучшает заменяемость, но бессмысленное дробление без реальных потребителей создаёт лишние имена. Широкое ограничение повышает применимость, но может не дать операций, нужных алгоритму.

Вопрос 11 из 20

В рабочем примере по теме «Файл модуля go.mod» важно отделить гарантию от догадки. Как точнее всего описать выполнение фрагмента?

module example.com/app

go 1.26

require example.com/lib v1.4.0

Универсальная функция копирования среза возвращает `[]T`, не заставляя вызывать утверждение типа. Функции достаточно `io.Reader`, если она только читает поток; требование конкретного файла излишне сужает применение. Команда `go mod tidy` добавляет необходимые требования и удаляет неиспользуемые с учётом импортов и тестов. Новая опция через функциональный параметр позволяет расширить конструктор без изменения старых вызовов. Компилятор выводит `T=int` из аргументов `Min(3,5)`, если ограничение допускает `int`.

Вопрос 12 из 20

Фрагмент относится к теме «Файл модуля go.mod». Какая доработка делает поведение явным для вызывающего кода?

module example.com/app

go 1.26

require example.com/lib v1.4.0

Контекст проверки: Файл модуля go.mod.

Определять интерфейс рядом с потребителем и проверять соответствие через `var _ Interface = (*Type)(nil)` там, где это помогает сопровождению. Хранить `go.mod` и `go.sum` в системе версий и проверять изменения зависимостей как обычный код. Планировать расширение через структуры параметров или опции, поддерживать старый контракт в пределах крупной версии. Использовать `~`, когда алгоритму важны операции базового представления и нужно сохранить пользовательский именованный тип. Не обобщать функцию, если конкретная версия короче, яснее и не дублируется в реальных местах.

Вопрос 13 из 20

На ревью разбирают тему «Файл модуля go.mod». Какое правило достаточно применить для проверки ответа?

module example.com/app

go 1.26

require example.com/lib v1.4.0

Вопрос относится к теме: Файл модуля go.mod.

`any` — псевдоним `interface{}` и может хранить значение любого типа, но операции требуют проверки динамического типа. Интерфейс с одним-двумя методами легче реализовать, тестировать и комбинировать; контракт должен отражать потребность вызывающего кода. Файл `go.mod` задаёт путь модуля, версию языка и требования к модулям, но не хранит исходный код зависимостей. Обобщения хорошо сохраняют точный тип данных, но не выполняют динамическую диспетчеризацию поведения сами по себе. Ограничение задаёт множество допустимых типов и доступные операции; `comparable` разрешает `==` и использование как ключа карты.

Вопрос 14 из 20

В разделе «Файл модуля go.mod» показан конкретный случай. Какой граничный случай нужно проверить отдельно?

Метод с получателем `*T` входит в набор методов `*T`, но не обязательно `T`. Добавление метода в опубликованный интерфейс ломает все внешние реализации этого интерфейса. Обещание конкретного порядка карты или внутреннего кеша превращает случайную деталь в совместимость. Каждая новая sentinel-ошибка становится частью публичного протокола и может закрепить внутреннюю деталь. Директива `replace` удобна локально, но случайная публикация замены на путь файловой системы ломает сборку у других.

Вопрос 15 из 20

Команда проверяет решение по теме «Файл модуля go.mod». Какой инженерный компромисс здесь действительно существует?

Малый интерфейс улучшает заменяемость, но бессмысленное дробление без реальных потребителей создаёт лишние имена. Модули дают воспроизводимость версий, но обновления всё равно требуют проверки совместимости и безопасности. Неявная реализация снижает связанность, но слишком широкие интерфейсы трудно удовлетворять и подменять. Широкое ограничение повышает применимость, но может не дать операций, нужных алгоритму. Малый контракт улучшает совместимость, но интерфейс ради одной реализации внутри пакета может быть лишним слоем.

Вопрос 16 из 20

Фрагмент относится к теме «Версии модулей». Что именно произойдёт при выполнении показанного фрагмента?

module example.com/app

go 1.26

require example.com/lib/v2 v2.3.1

Если один модуль требует `v1.2.0`, а другой `v1.4.0`, сборка использует как минимум `v1.4.0`. Функции достаточно `io.Reader`, если она только читает поток; требование конкретного файла излишне сужает применение. Функция принимает только `Get`, поэтому и рабочий клиент, и маленькая заглушка удовлетворяют контракту. Компилятор выводит `T=int` из аргументов `Min(3,5)`, если ограничение допускает `int`. Функция `Has` принимает ключ любого сравнимого типа, согласованного с ключами карты.

Вопрос 17 из 20

На ревью разбирают тему «Версии модулей». Как исправить основной риск без ненужной перестройки решения?

module example.com/app

go 1.26

require example.com/lib/v2 v2.3.1

Контекст проверки: Версии модулей.

Добавлять исполняемые Example для основного пути и разделять обязательные гарантии от деталей реализации. Документировать категории ошибок и не обещать стабильность полного текста сообщения. Определять интерфейс рядом с потребителем и проверять соответствие через `var _ Interface = (*Type)(nil)` там, где это помогает сопровождению. Использовать конкретный тип или параметр типа, если допустимые значения известны заранее; `any` оставлять для действительно открытых границ. Обновлять зависимость явной командой и проверять `go.mod`, `go.sum`, тесты и заметки о выпуске.

Вопрос 18 из 20

В разделе «Версии модулей» показан конкретный случай. Какой принцип позволяет вывести ответ без запуска программы?

module example.com/app

go 1.26

require example.com/lib/v2 v2.3.1

Вопрос относится к теме: Версии модулей.

Интерфейс определяет потребитель; часто достаточно одного метода, который функция действительно вызывает. Ограничение задаёт множество допустимых типов и доступные операции; `comparable` разрешает `==` и использование как ключа карты. Обобщения хорошо сохраняют точный тип данных, но не выполняют динамическую диспетчеризацию поведения сами по себе. Минимальный выбор версий выбирает наибольшую из минимально требуемых версий в графе, а не обязательно самую свежую доступную. `any` — псевдоним `interface{}` и может хранить значение любого типа, но операции требуют проверки динамического типа.

Вопрос 19 из 20

Команда проверяет решение по теме «Версии модулей». Какой контрпример разрушит слишком широкое толкование правила?

Ограничение `int` без `~` допускает сам `int`, но не произвольный `type Age int`. Методы не могут вводить собственные дополнительные параметры типов сверх параметров типа получателя. Нельзя использовать утверждение типа непосредственно для обычного значения параметра типа без преобразования к интерфейсу. Метод с получателем `*T` входит в набор методов `*T`, но не обязательно `T`. Крупная версия `v2+` обычно входит в путь импорта, например `/v2`, поэтому это отдельный модульный путь.

Вопрос 20 из 20

Перед публикацией кода по теме «Версии модулей» нужно уточнить контракт. Что важно учесть помимо формальной корректности?

Приближённый тип делает API дружелюбнее к доменным типам, но слишком широкое объединение усложняет сообщение об ошибке. Малый контракт улучшает совместимость, но интерфейс ради одной реализации внутри пакета может быть лишним слоем. Фиксация версий делает сборку повторяемой, но слишком редкие обновления накапливают риски миграции и уязвимости. Неявная реализация снижает связанность, но слишком широкие интерфейсы трудно удовлетворять и подменять. Широкое ограничение повышает применимость, но может не дать операций, нужных алгоритму.

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу