Проектирование API и пакетов Go — бесплатный тест онлайн

Вопрос 1 из 30

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

// Фрагмент для трассировки.
package main
type Getter interface{Get(string)([]byte,error)}
func load(g Getter,k string)([]byte,error){return g.Get(k)}
func main(){}

Тип `File` удовлетворяет `Namer`, потому что имеет метод `Name() string` с точной сигнатурой. Универсальная функция копирования среза возвращает `[]T`, не заставляя вызывать утверждение типа. Функция `Has` принимает ключ любого сравнимого типа, согласованного с ключами карты. Функции достаточно `io.Reader`, если она только читает поток; требование конкретного файла излишне сужает применение. Функция принимает только `Get`, поэтому и рабочий клиент, и маленькая заглушка удовлетворяют контракту.

Вопрос 2 из 30

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
type Getter interface{Get(string)([]byte,error)}
func load(g Getter,k string)([]byte,error){return g.Get(k)}
func main(){}

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

Вопрос 3 из 30

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

// Определите правило Go, которое объясняет результат.
package main
type Getter interface{Get(string)([]byte,error)}
func load(g Getter,k string)([]byte,error){return g.Get(k)}
func main(){}

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

Вопрос 4 из 30

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

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

Вопрос 5 из 30

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

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

Вопрос 6 из 30

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

// Фрагмент для трассировки.
package main
import("errors";"fmt")
var ErrNotFound=errors.New("not found")
func get()error{return fmt.Errorf("user 7: %w",ErrNotFound)}
func main(){_=errors.Is(get(),ErrNotFound)}

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

Вопрос 7 из 30

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("errors";"fmt")
var ErrNotFound=errors.New("not found")
func get()error{return fmt.Errorf("user 7: %w",ErrNotFound)}
func main(){_=errors.Is(get(),ErrNotFound)}

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

Вопрос 8 из 30

Команда проверяет решение по теме «Ошибки». Что именно гарантирует Go в этой ситуации?

// Определите правило Go, которое объясняет результат.
package main
import("errors";"fmt")
var ErrNotFound=errors.New("not found")
func get()error{return fmt.Errorf("user 7: %w",ErrNotFound)}
func main(){_=errors.Is(get(),ErrNotFound)}

Все обычные `.go`-файлы одного каталога должны объявлять один пакет; пакет задаёт единицу компиляции и повторного использования. Интерфейс с одним-двумя методами легче реализовать, тестировать и комбинировать; контракт должен отражать потребность вызывающего кода. Публичный API должен позволять программно распознавать значимые категории через `errors.Is/As`, сохраняя контекст. Обобщения хорошо сохраняют точный тип данных, но не выполняют динамическую диспетчеризацию поведения сами по себе. Ограничение задаёт множество допустимых типов и доступные операции; `comparable` разрешает `==` и использование как ключа карты.

Вопрос 9 из 30

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

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

Вопрос 10 из 30

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

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

Вопрос 11 из 30

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

// Фрагмент для трассировки.
package main
type Option func(*Client)
type Client struct{timeout int}
func New(opts ...Option)*Client{c:=&Client{};for _,o:=range opts{o(c)};return c}
func main(){}

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

Вопрос 12 из 30

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
type Option func(*Client)
type Client struct{timeout int}
func New(opts ...Option)*Client{c:=&Client{};for _,o:=range opts{o(c)};return c}
func main(){}

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

Вопрос 13 из 30

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

// Определите правило Go, которое объясняет результат.
package main
type Option func(*Client)
type Client struct{timeout int}
func New(opts ...Option)*Client{c:=&Client{};for _,o:=range opts{o(c)};return c}
func main(){}

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

Вопрос 14 из 30

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

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

Вопрос 15 из 30

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

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

Вопрос 16 из 30

Команда проверяет решение по теме «Документирование». Как точнее всего описать выполнение фрагмента?

// Фрагмент для трассировки.
package client
// Client безопасен для одновременного использования несколькими горутинами.
type Client struct{}
// Close освобождает ресурсы; после Close новые вызовы возвращают ErrClosed.
func(*Client)Close()error{return nil}

Тип `Age` допускается ограничением `~int`, хотя это отдельный именованный тип. Документация прямо говорит, можно ли вызывать `Client.Do` одновременно и кто закрывает возвращаемый ресурс. Компилятор выводит `T=int` из аргументов `Min(3,5)`, если ограничение допускает `int`. Универсальная функция копирования среза возвращает `[]T`, не заставляя вызывать утверждение типа. Файлы `a.go` и `b.go` с `package store` компилируются вместе, даже если объявления распределены между файлами.

Вопрос 17 из 30

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package client
// Client безопасен для одновременного использования несколькими горутинами.
type Client struct{}
// Close освобождает ресурсы; после Close новые вызовы возвращают ErrClosed.
func(*Client)Close()error{return nil}

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

Вопрос 18 из 30

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

// Определите правило Go, которое объясняет результат.
package client
// Client безопасен для одновременного использования несколькими горутинами.
type Client struct{}
// Close освобождает ресурсы; после Close новые вызовы возвращают ErrClosed.
func(*Client)Close()error{return nil}

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

Вопрос 19 из 30

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

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

Вопрос 20 из 30

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

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

Вопрос 21 из 30

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

// Фрагмент для трассировки.
package client_test
import("fmt";"example.com/client")
func Example(){
    c:=client.New()
    fmt.Println(c!=nil)
    // Output: true
}

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

Вопрос 22 из 30

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

// Фрагмент из ревью: требуется выбрать безопасную правку.
package client_test
import("fmt";"example.com/client")
func Example(){
    c:=client.New()
    fmt.Println(c!=nil)
    // Output: true
}

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

Вопрос 23 из 30

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

// Определите правило Go, которое объясняет результат.
package client_test
import("fmt";"example.com/client")
func Example(){
    c:=client.New()
    fmt.Println(c!=nil)
    // Output: true
}

Клиент тестируют через `httptest.Server` и подменный `RoundTripper`, проверяя статусы, тело, отмену и число попыток. Производительность проверяют устойчивым бенчмарком, базовой линией и эксплуатационными метриками, а не одним быстрым запуском. Синхронизацию проверяют под `-race`, повторными прогонами и инвариантами результата, а не только отсутствием паники. Протокол канала тестируют на обычном пути, закрытии, отмене и отсутствии потребителя; зависание ограничивают таймаутом теста. Публичный пакет проверяют как внутренними тестами, так и внешним пакетом `_test`, примерами и тестами совместимости ошибок.

Вопрос 24 из 30

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

Тест только конечного тела не обнаружит двойной вызов `next` или потерю `Flusher`. Подмена SQL не воспроизводит блокировки, изоляцию и различия диалекта реальной базы. Проверка только текста ошибки может сломаться; причины следует распознавать через значения пакета `context` и `errors.Is`. Чистый отчёт не доказывает отсутствие непокрытой гонки; найденный отчёт нельзя «лечить» случайным `Sleep`. Тесты только внутри пакета могут случайно зависеть от деталей, недоступных реальному пользователю.

Вопрос 25 из 30

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

Модульный тест быстр, а отдельный `httptest.Server` нужен для маршрутизации, транспорта и завершения соединений. Виртуальное время делает тесты быстрыми, но требует дополнительной абстракции и проверки её соответствия реальным таймерам. Внешние тесты защищают границу, а внутренние быстрее локализуют сложные алгоритмы. Изолированный тест локализует дефект, а тест цепочки ловит ошибки порядка и взаимодействия слоёв. Большее число инстанцирований повышает уверенность, но не должно превращать тесты в повторение одинаковой арифметики.

Вопрос 26 из 30

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

// Фрагмент для трассировки.
package main
import "sync"
type Worker struct{once sync.Once;stop chan struct{}}
func(w *Worker)Close(){w.once.Do(func(){close(w.stop)})}
func main(){}

Десятки горутин могут ждать свободное соединение, даже если процессор почти не занят. Сигнал запускает `Shutdown`, а `ListenAndServe` возвращает `http.ErrServerClosed`, который не является аварией. Идемпотентный `Close` через `sync.Once` безопасно останавливает одну фоновую горутину. Снимок горутин показывает множество работников, ожидающих один и тот же мьютекс. Высокое время блокировки указывает, что горутины ждут канал или мьютекс, хотя CPU может быть свободен.

Вопрос 27 из 30

Фрагмент относится к теме «Конкурентность и эксплуатация». Какая правка устраняет причину, а не маскирует её проявление?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "sync"
type Worker struct{once sync.Once;stop chan struct{}}
func(w *Worker)Close(){w.once.Do(func(){close(w.stop)})}
func main(){}

Иметь общий корневой контекст, идемпотентное закрытие, ограниченный льготный срок и принудительный финальный путь. Собирать профили горутин, блокировок и мьютексов при превышении порога, сохраняя контекст нагрузки. Ограничивать параллелизм, задавать контекст, отслеживать WaitCount/WaitDuration и избегать запросов N+1. Не запускать скрытую вечную горутину без способа остановки, контекста и наблюдаемой ошибки. Связать лимиты HTTP, пула базы и внешних клиентов; следить за горутинами, памятью, паузами GC и очередями.

Вопрос 28 из 30

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

// Определите правило Go, которое объясняет результат.
package main
import "sync"
type Worker struct{once sync.Once;stop chan struct{}}
func(w *Worker)Close(){w.once.Do(func(){close(w.stop)})}
func main(){}

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

Вопрос 29 из 30

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

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

Вопрос 30 из 30

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

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