Ну, слушай, про качество кода в Go — это, блядь, целая опера, а не просто «написать и забыть». Тут тебе не хухры-мухры, а целый арсенал, чтобы не выстрелить себе в ногу. Ёпта, разбираем по косточкам.

Первое, с чего начинается любая адекватная разработка — это форматирование. Тут у нас два священных инструмента: gofmt и goimports. Первый расставляет отступы и скобки так, как завещал сам Кен Томпсон, чтобы не было этих идиотских споров, куда ставить фигурную скобку. Второй — тот же самый, только ещё и импорты по полочкам разложит, чтобы не было этой дичи, когда стандартные библиотеки вперемешку с локальными. Запускаешь — и код уже не выглядит как пиздец, написанный в три часа ночи.

Дальше — статический анализ, или линтинг, если по-умному. Это когда специальные программы тычут тебе пальцем в твои косяки, ещё до того как ты этот код запустил. Инструмент номер один — golangci-lint. Это, сука, такой монстр, который под капотом держит овердохуища разных линтеров. Он найдёт всё: от неиспользованной переменной, которая мозолит глаза, до таких подводных камней в конкурентности, что сам от себя офигеешь. Ставится одной командой, запускается другой — и вуаля, тебе вываливают список, над чем нужно попотеть.

# Берёшь и ставишь, блядь
go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest

# А потом в корне проекта просто:
golangci-lint run

Ну а теперь про тесты. Без них — вообще никуда, это как ехать на машине с закрытыми глазами. go test — наш всему голова. Юнит-тесты щупают каждую функцию по отдельности, интеграционные — смотрят, как эти функции друг с другом уживаются. А ещё есть покрытие кода — это такая метрика, которая показывает, сколько твоего кода хоть раз выполнилось во время тестов. Если покрытие низкое — это пиздецкий звоночек, что ты проверяешь только счастливый путь, а все углы и грабли остались за кадром.

# Запускаешь и сразу видишь, не обосрался ли ты
go test -cover ./...

А если хочешь помериться пипирками с производительностью — тебе в бенчмарки. go test -bench запустит твою функцию столько раз, сколько надо, и выдаст, насколько она шустрая. Идеально, чтобы поймать регрессию, когда после твоего «гениального» рефакторинга всё стало работать в десять раз медленнее.

// Вот смотри, как просто замерить, не тормозит ли твоя фибоначчи
func BenchmarkFib(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Fib(10) // Считаем, блядь, десятое число
    }
}

Но все эти инструменты — хуй без ревью кода. Это когда другие разработчики смотрят на твои творения и задают неудобные вопросы. Цель — не устроить разнос, а найти те логические косяки, до которых линтер не додумается, и чтобы знания по проекту не лежали в одной голове. Волнение ебать, но необходимо.

Ещё есть куча метрик, которые умные люди придумали. Например, цикломатическая сложность — она считает, сколько разных путей выполнения в твоей функции. Если их больше 10-15 — это уже не функция, а лабиринт Минотавра, в котором все заблудятся. Такую херню надо дробить, а то потом сам не разберёшься.

Ну и вишенка на торте — документация. Комментарии к экспортируемым функциям и типам — это не для галочки. Это чтобы через полгода ты, или кто-то другой, не ломал голову, что эта функция CalculateSomething вообще делает и в каком порядке аргументы передавать. godoc соберёт всё это в красивую справку. В общем, качество кода — это не про «работает и ладно», это про то, чтобы через год не пришлось всё переписывать с нуля, проклиная день, когда ты это написал.