Инструменты Go

Инструменты Go образуют единый цикл: зафиксировать зависимости, отформатировать и проверить код, доказать корректность тестами, измерить проблему и отладить её с минимальным риском для production.

Зачем это на интервью

Интервьюер ожидает не перечень флагов, а последовательность действий: как воспроизвести дефект, какой сигнал собирать, как исключить ложный вывод и чем подтвердить исправление.

Результат раздела

После раздела вы умеете подготовить воспроизводимый запуск проекта, выбрать диагностический инструмент по симптомам и объяснить его ограничения.

Темы

1. go mod, версии и vendor
2. Форматирование, vet и staticcheck
3. go test, race, count и run
4. Бенчмарки и benchmem
5. pprof
6. trace и escape analysis
7. Отладчик Delve

Ключевые понятия

• Воспроизводимость: одинаковые исходники, зависимости, версия Go и сценарий запуска.
• Статическая проверка находит классы ошибок без исполнения; тест и профиль отвечают на другие вопросы.
• Измерение до и после изменения важнее впечатления от «быстрого» кода.

Минимум для E4

• Запускать go mod tidy, go test ./..., go vet ./... и понимать, что они проверяют.
• Выбирать -race, benchmark, pprof, trace или Delve по наблюдаемому симптому.
• Не публиковать диагностические endpoints и артефакты без контроля доступа.

Углубление для E5/Senior

Старший инженер строит CI и operational-процедуры так, чтобы они были быстрыми, повторяемыми и безопасными: фиксирует toolchain, разделяет unit/integration/race-проверки, сохраняет baseline и ограничивает доступ к профилям.

Типовые вопросы

1. Почему go test не заменяет go vet?
   • Тесты исполняют выбранные пути; vet ищет известные подозрительные конструкции статически.
2. Когда нужен -race?
   • Для конкурентного кода в CI и при воспроизведении подозрительной гонки, с учётом заметного overhead.
3. Чем профиль отличается от trace?
   • Профиль агрегирует стоимость; trace показывает временную картину scheduler, блокировок и GC.
4. Почему один benchmark недостаточен?
   • Нужны стабильный workload, несколько прогонов и end-to-end метрика, если изменение затрагивает сервис.
5. Почему pprof нельзя открывать публично?
   • Он раскрывает детали бинарника и runtime, создаёт нагрузку и может стать operational-риском.

Практика

• Соберите для небольшого сервиса команду CI из format-check, vet, staticcheck и тестов. Готово: команды запускаются с чистого checkout и результат каждого шага понятен.
• Найдите искусственную проблему конкурентности и производительности разными инструментами. Готово: для каждой проблемы есть гипотеза, команда, артефакт и повторная проверка исправления.

Частые ошибки и ловушки

• Использовать инструмент до формулировки вопроса и затем подгонять объяснение под его вывод.
• Сравнивать результаты с разными входами, toolchain или нагрузкой.
• Считать отсутствие отчёта race detector доказательством отсутствия всех гонок.

Связанные темы

Go · Производительность и память · Наблюдаемость · Тестирование

Источники

• Command go
• Go diagnostics
• Go testing package