Comments 13
Если id не serial а uuid будет работать?
Postgrest?
А как понять что это «у вас в проде» работает?
Выглядит так что вы либо джун либо с другого языка перешли, но судя по переменным «otvet := …” и прочему неймингу - скорее сразу оба варианта и вам по какой то причине в маленькой конторе дали карт-бланш на технические решения, а значит лида нет либо он на другом языке и забил на проект.
напишите название компании плз чтобы сразу понимать)
Шаблоны кода можно изменять, можете сделать любой нейминг
Тимлид есть, проекты развиваются
Компания Росатом
Репозиторию уже 3 года, и реальным рабочим проектам тоже столько же.
Перешёл с языка 1С на golang 4 года назад
Слово "Otvet" любой поймёт что означает, и для чего нужно.
У англицизмов неочевидное назначение, слово "Result" может означать что угодно, а слово "Ответ" означает всегда одинаково - что вернётся в результате работы функции
в таком случае я бы на месте ваших pjm-ов и техлидов задумался о соответствии тимлида занимаемой должности. Алсо стоило ли оно того вкладываться в разработку и поддержку вашего crud generator, тогда, как в экосистеме Go есть несколько зрелых, богатых фичами решений для генерации типизированного CRUD-кода для PostgreSQL? Вам фактически заплатили за поломанный велосипед, имея возможность получить бесплатный автомобиль
и то что вы назвали "англицизмами" - устоявшиеся английские эквиваленты для большинства терминов . Использовать Answer или Response вместо Otvet не только естественнее, но и помогает читать код без лишнего "контекста", ибо в продакшене строго придерживаются английского языка. А транслит (внезапные русские слова, написанные английскими буквами Otvet, Vopros) выбивается из стиля и напоминают студенческие или "пет-" проекты , человеку со стороны сложно понять, почему не используется английский термин . Возможно для Вас это не очевидно из за пресловутой проф деформации 1С. Но уж оч очевидно буквально для всех в IT профессии, это Вам инфа 100
Приятно видеть, что на любом языке все эти автокруды оказываются калом :)
На картинке crud service выглядит как корзина, в которую сложили все яйца.
Надёжнее было бы каждому сервису с выделенной бизнес-логикой генерить свой crud service.
Голяковые crud операции в 75% случаев не нужны - ибо база это транзакции и ссылочная целостность. По этой же причине orm это зло - ибо откат orm транзакций - проще застрелиться.
Нужны обычно семантические операции, а не чистый, сферический crud, иначе проще сразу работать не с реляционной базой
CRUD generator для golang + PostgreSQL