в таком случае я бы на месте ваших pjm-ов и техлидов задумался о соответствии тимлида занимаемой должности. Алсо стоило ли оно того вкладываться в разработку и поддержку вашего crud generator, тогда, как в экосистеме Go есть несколько зрелых, богатых фичами решений для генерации типизированного CRUD-кода для PostgreSQL? Вам фактически заплатили за поломанный велосипед, имея возможность получить бесплатный автомобиль
и то что вы назвали "англицизмами" - устоявшиеся английские эквиваленты для большинства терминов . Использовать Answer или Response вместо Otvet не только естественнее, но и помогает читать код без лишнего "контекста", ибо в продакшене строго придерживаются английского языка. А транслит (внезапные русские слова, написанные английскими буквами Otvet, Vopros) выбивается из стиля и напоминают студенческие или "пет-" проекты , человеку со стороны сложно понять, почему не используется английский термин . Возможно для Вас это не очевидно из за пресловутой проф деформации 1С. Но уж оч очевидно буквально для всех в IT профессии, это Вам инфа 100
Писать вручную rest api на чем то вроде gin , а затем натягивать на него доку на не проверяемом птичьем мета-языке в комментариях для swag - это ужасный совет. Пж не делайте так никогда. Разрабатывайте rest api от спеки с использованием go-swagger и коллеги скажут вам спасибо.
а ещё у вас в коде (меня только гошный интересует) оч много антипатернов. Вы судя по всему забили на чистую архитектуру и некоторые 12 factor apps, логи в стдаут например. Поэтому выглядит гошная часть не очень
Всё что вы описали - слабо аргументировано вызывает много вопросов. Например, вы пишете Преимуществом собственного типа ошибки стала легкость, с которой мы могли писать тесты, зависящие от ошибок, а также писать чувствительный к ошибкам код вне тестов.
Но в Go ошибки обычно передаются через fmt.Errorf("%w .....") и наследование публичного объекта-ошибки. И как бы этого достаточно и для тестов зависящих от ошибок, и для собственно обработки ошибок, и для преобразовывания ошибки в HTTP-статус, и даже для расчёта сообщения для пользователя. В вашем примере можно было было бы просто обернуть ошибку и прокинуть на верх, либо вообще ни как её не обрабатывать. И затем на самом верху стека, в хендлере, сделать проверку if errors.Is(err, pgx.ErrNoRows) {
Поэтому Ваш собственный тип ошибки выглядит как не нужное усложнение. По крайней мере на таком уровне аргументации.
Далее, вы пишете про graylog и говорите что прикрепляете к ошибке стек трейс чтобы удовлетворить greylog-у. Но greylog вовсе не самое распространённо и далеко не самое лучшее решение, есть другие, и большинство из них вообще не предполагает наличия стек-трейса для сообщения в журнал. Для стектрейсов есть sentry, которая позволяет программисту вообще не иметь дело со стек трейсами и ничего про них не знать.
в таком случае я бы на месте ваших pjm-ов и техлидов задумался о соответствии тимлида занимаемой должности. Алсо стоило ли оно того вкладываться в разработку и поддержку вашего crud generator, тогда, как в экосистеме Go есть несколько зрелых, богатых фичами решений для генерации типизированного CRUD-кода для PostgreSQL? Вам фактически заплатили за поломанный велосипед, имея возможность получить бесплатный автомобиль
и то что вы назвали "англицизмами" - устоявшиеся английские эквиваленты для большинства терминов . Использовать
AnswerилиResponseвместоOtvetне только естественнее, но и помогает читать код без лишнего "контекста", ибо в продакшене строго придерживаются английского языка. А транслит (внезапные русские слова, написанные английскими буквамиOtvet,Vopros) выбивается из стиля и напоминают студенческие или "пет-" проекты , человеку со стороны сложно понять, почему не используется английский термин . Возможно для Вас это не очевидно из за пресловутой проф деформации 1С. Но уж оч очевидно буквально для всех в IT профессии, это Вам инфа 100Писать вручную rest api на чем то вроде gin , а затем натягивать на него доку на не проверяемом птичьем мета-языке в комментариях для swag - это ужасный совет. Пж не делайте так никогда. Разрабатывайте rest api от спеки с использованием go-swagger и коллеги скажут вам спасибо.
а ещё у вас в коде (меня только гошный интересует) оч много антипатернов. Вы судя по всему забили на чистую архитектуру и некоторые 12 factor apps, логи в стдаут например. Поэтому выглядит гошная часть не очень
Всё что вы описали - слабо аргументировано вызывает много вопросов. Например, вы пишете
Преимуществом собственного типа ошибки стала легкость, с которой мы могли писать тесты, зависящие от ошибок, а также писать чувствительный к ошибкам код вне тестов.
Но в Go ошибки обычно передаются через fmt.Errorf("%w .....") и наследование публичного объекта-ошибки. И как бы этого достаточно и для тестов зависящих от ошибок, и для собственно обработки ошибок, и для преобразовывания ошибки в HTTP-статус, и даже для расчёта сообщения для пользователя. В вашем примере можно было было бы просто обернуть ошибку и прокинуть на верх, либо вообще ни как её не обрабатывать. И затем на самом верху стека, в хендлере, сделать проверку
if errors.Is(err, pgx.ErrNoRows) {Поэтому Ваш собственный тип ошибки выглядит как не нужное усложнение. По крайней мере на таком уровне аргументации.
Далее, вы пишете про graylog и говорите что прикрепляете к ошибке стек трейс чтобы удовлетворить greylog-у. Но greylog вовсе не самое распространённо и далеко не самое лучшее решение, есть другие, и большинство из них вообще не предполагает наличия стек-трейса для сообщения в журнал. Для стектрейсов есть sentry, которая позволяет программисту вообще не иметь дело со стек трейсами и ничего про них не знать.
Спасибо, полезный для меня материал. Так можно собственно любой erst-api сервис задеплоить, не только телеграм-бот