Шаблон репозитория для практического трека «Go в веб-разработке».
- Склонируйте репозиторий в любую подходящую директорию на вашем компьютере.
- В корне репозитория выполните команду
go mod init <name>(где<name>- адрес вашего репозитория на GitHub без префиксаhttps://) для создания модуля.
Чтобы иметь возможность получать обновления автотестов и других частей шаблона выполните следующую команду:
git remote add -m main template https://github.com/yandex-praktikum/go-musthave-shortener-tpl.git
Для обновления кода автотестов выполните команду:
git fetch template && git checkout template/main .github
Затем добавьте полученные изменения в свой репозиторий.
Я бы изменил прототип на Get(key string) (*string, error). С точки зрения БД, ключ не найден это не ошибка. Если не найдет будет возврат (nil, nil), который удобно обработать на уровне логики.
Лучше создавать map / slice через make, если в этом же scope (пакет в данном случае), будет запись.
В Go принято иначе именовать интерфейсы: Writer, Storer, Updater и т.д. Префикс обычно не ставят. В данном случае я бы переименовал в StorerExpected, т.к. тут объявлено ожидаемое поведение зависимости. Интерфейсы, обычно, оформляют отдельным файлом для упрощения навигации по коду + так легче генерить моки (например через gomock).
IStorage может быть nil, хорошо бы добавить на это проверку и вернуть ошибку, если конструктор не может создать валидный объект из входов.
Очень "большой" конструктор, тяжело его будет поддерживать. Почитай про паттерн опций, это общепринятый подход. Например тут: https://medium.com/star-gazers/go-options-pattern-da49185a2526
Очень странные консольные логи. Лучше либо их убрать, либо использовать "большой" логгер с контекстом (кто запросил, какой ендпоинт, что пошло не так).
Тут аналогично. Может лучше эту ошибку пользователю отдать в теле ответа?