Обобщения Go — бесплатный тест онлайн

Вопрос 1 из 25

В рабочем примере по теме «Параметры типов» важно отделить гарантию от догадки. Как изменится состояние программы после этого фрагмента?

// Фрагмент для трассировки.
package main
func First[T any](xs []T) T { return xs[0] }
func main(){ _=First([]string{"go"}) }

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

Вопрос 2 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
func First[T any](xs []T) T { return xs[0] }
func main(){ _=First([]string{"go"}) }

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

Вопрос 3 из 25

На ревью разбирают тему «Параметры типов». Какое правило важнее случайных деталей конкретного запуска?

// Определите правило Go, которое объясняет результат.
package main
func First[T any](xs []T) T { return xs[0] }
func main(){ _=First([]string{"go"}) }

`any` — псевдоним `interface{}` и может хранить значение любого типа, но операции требуют проверки динамического типа. Добавление экспортированной функции обычно совместимо, а изменение сигнатуры, удаление имени или добавление метода в интерфейс ломает пользователей. Параметр типа объявляется в квадратных скобках и получает конкретный тип при инстанцировании функции или типа. Все обычные `.go`-файлы одного каталога должны объявлять один пакет; пакет задаёт единицу компиляции и повторного использования. Утверждение типа в двухзначной форме возвращает значение и `ok`; однозначная форма вызывает панику при несовпадении.

Вопрос 4 из 25

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

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

Вопрос 5 из 25

Команда проверяет решение по теме «Параметры типов». Что учитывать при выборе этого приёма для публичного API?

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

Вопрос 6 из 25

Фрагмент относится к теме «Ограничения типов». Какой результат даст этот код на поддерживаемой реализации Go?

// Фрагмент для трассировки.
package main
func Has[K comparable,V any](m map[K]V,k K) bool { _,ok:=m[k]; return ok }
func main(){ _=Has(map[int]string{1:"x"},1) }

После `var x any = 3` динамический тип интерфейса — `int`, а само значение не становится нетипизированным. Функция `Has` принимает ключ любого сравнимого типа, согласованного с ключами карты. Функции достаточно `io.Reader`, если она только читает поток; требование конкретного файла излишне сужает применение. Функция принимает только `Get`, поэтому и рабочий клиент, и маленькая заглушка удовлетворяют контракту. Новая опция через функциональный параметр позволяет расширить конструктор без изменения старых вызовов.

Вопрос 7 из 25

На ревью разбирают тему «Ограничения типов». Что нужно поменять, чтобы граничный случай не превратился в сбой?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
func Has[K comparable,V any](m map[K]V,k K) bool { _,ok:=m[k]; return ok }
func main(){ _=Has(map[int]string{1:"x"},1) }

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

Вопрос 8 из 25

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

// Определите правило Go, которое объясняет результат.
package main
func Has[K comparable,V any](m map[K]V,k K) bool { _,ok:=m[k]; return ok }
func main(){ _=Has(map[int]string{1:"x"},1) }

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

Вопрос 9 из 25

Команда проверяет решение по теме «Ограничения типов». Что стоит проверить до переноса решения в общий компонент?

`any` не разрешает операторы `<` или `+`, потому что они поддерживаются не всеми типами. Обещание конкретного порядка карты или внутреннего кеша превращает случайную деталь в совместимость. Интерфейс с типизированным `nil`-указателем внутри не равен `nil`. Крупная версия `v2+` обычно входит в путь импорта, например `/v2`, поэтому это отдельный модульный путь. Утверждение проверяет динамический тип интерфейсного значения, а не выполняет произвольное преобразование типов.

Вопрос 10 из 25

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

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

Вопрос 11 из 25

На ревью разбирают тему «Приближённый базовый тип ~T». К какому результату приводит показанная конструкция?

// Фрагмент для трассировки.
package main
type Integer interface{ ~int | ~int64 }
type Age int
func Twice[T Integer](x T) T { return x+x }
func main(){ _=Twice(Age(3)) }

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

Вопрос 12 из 25

В разделе «Приближённый базовый тип ~T» показан конкретный случай. Какую правку стоит предложить на ревью, сохранив назначение кода?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
type Integer interface{ ~int | ~int64 }
type Age int
func Twice[T Integer](x T) T { return x+x }
func main(){ _=Twice(Age(3)) }

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

Вопрос 13 из 25

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

// Определите правило Go, которое объясняет результат.
package main
type Integer interface{ ~int | ~int64 }
type Age int
func Twice[T Integer](x T) T { return x+x }
func main(){ _=Twice(Age(3)) }

Добавление экспортированной функции обычно совместимо, а изменение сигнатуры, удаление имени или добавление метода в интерфейс ломает пользователей. Утверждение типа в двухзначной форме возвращает значение и `ok`; однозначная форма вызывает панику при несовпадении. `any` — псевдоним `interface{}` и может хранить значение любого типа, но операции требуют проверки динамического типа. Элемент `~T` в ограничении включает именованные типы, чей базовый тип равен `T`. Комментарий экспортированного имени объясняет назначение, контракт, ошибки и конкурентную безопасность, а не повторяет сигнатуру.

Вопрос 14 из 25

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

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

Вопрос 15 из 25

В рабочем примере по теме «Приближённый базовый тип ~T» важно отделить гарантию от догадки. Какой вывод о сопровождении решения наиболее взвешенный?

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

Вопрос 16 из 25

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

// Фрагмент для трассировки.
package main
func Clone[T any](src []T) []T { return append([]T(nil),src...) }
func main(){ _=Clone([]int{1,2}) }

Документация прямо говорит, можно ли вызывать `Client.Do` одновременно и кто закрывает возвращаемый ресурс. Функция принимает только `Get`, поэтому и рабочий клиент, и маленькая заглушка удовлетворяют контракту. После `var x any = 3` динамический тип интерфейса — `int`, а само значение не становится нетипизированным. Новая опция через функциональный параметр позволяет расширить конструктор без изменения старых вызовов. Универсальная функция копирования среза возвращает `[]T`, не заставляя вызывать утверждение типа.

Вопрос 17 из 25

Команда проверяет решение по теме «Практические границы». Что здесь следует изменить прежде всего?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
func Clone[T any](src []T) []T { return append([]T(nil),src...) }
func main(){ _=Clone([]int{1,2}) }

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

Вопрос 18 из 25

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

// Определите правило Go, которое объясняет результат.
package main
func Clone[T any](src []T) []T { return append([]T(nil),src...) }
func main(){ _=Clone([]int{1,2}) }

Обобщения хорошо сохраняют точный тип данных, но не выполняют динамическую диспетчеризацию поведения сами по себе. `any` — псевдоним `interface{}` и может хранить значение любого типа, но операции требуют проверки динамического типа. Публичный API должен позволять программно распознавать значимые категории через `errors.Is/As`, сохраняя контекст. Файл `go.mod` задаёт путь модуля, версию языка и требования к модулям, но не хранит исходный код зависимостей. Тип реализует интерфейс автоматически, если его набор методов содержит все методы интерфейса; отдельного объявления `implements` нет.

Вопрос 19 из 25

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

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

Вопрос 20 из 25

Фрагмент относится к теме «Практические границы». Какой выбор лучше отражает баланс простоты и контроля?

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

Вопрос 21 из 25

Команда проверяет решение по теме «Тестирование и наблюдаемость». Как изменится состояние программы после этого фрагмента?

// Фрагмент для трассировки.
package sample
import "testing"
type Age int
func TestTwice(t *testing.T){ if Twice(Age(2))!=4{t.Fatal()} }
func Twice[T ~int|~int64](x T)T{return x+x}

Специальный `Reader` с одним байтом за вызов проверяет, что функция не рассчитывает на заполнение буфера сразу. Тест проверяет и значение, и `ok`, поэтому не путает нулевой элемент с закрытым каналом. Тест отменяет контекст после первого результата и убеждается, что выход закрывается за ограниченное время. Тест ошибки проверяет `errors.Is`, а не точное длинное сообщение с контекстом. Таблица проверяет `int64` и собственный `Age`, поэтому ловит ошибочное сужение ограничения.

Вопрос 22 из 25

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package sample
import "testing"
type Age int
func TestTwice(t *testing.T){ if Twice(Age(2))!=4{t.Fatal()} }
func Twice[T ~int|~int64](x T)T{return x+x}

Запускать `-shuffle`, `-count`, `-race`, хранить медленные интеграционные тесты отдельно и анализировать пропуски покрытия по риску. Определить SLO, проверку готовности, тревоги по расходу бюджета ошибок и автоматический откат с ручным подтверждением опасных миграций. Добавлять компиляционные проверки допустимых типов и обычные поведенческие тесты граничных значений. Хранить примеры компилируемыми, тестировать нулевое значение и конкурентный контракт, если они обещаны. Добавлять нагрузочные тесты, `-race` и снимки горутин при зависании; число сообщений в очереди использовать только как метрику.

Вопрос 23 из 25

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

// Определите правило Go, которое объясняет результат.
package sample
import "testing"
type Age int
func TestTwice(t *testing.T){ if Twice(Age(2))!=4{t.Fatal()} }
func Twice[T ~int|~int64](x T)T{return x+x}

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

Вопрос 24 из 25

Фрагмент относится к теме «Тестирование и наблюдаемость». Где корректный фрагмент легко становится ошибочным?

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

Вопрос 25 из 25

На ревью разбирают тему «Тестирование и наблюдаемость». Что учитывать при выборе этого приёма для публичного API?

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