да

вот ему этот вопрос и задайте :)

нет, go-style comment это не спека.

А что тогда спека в go для пакета?

он или пошлет вас, или рассказет, что рабочих рук нехватка, и делать лишнее - граничит с саботажем

нет, go-style comment это не спека.

в каком же виде надо писать спеку тогда?

Товарищи, привет! Кто sqlx юзает? Когда в функции стартуешь транзакцию, надо ли по defer ее роллбечить, если вдруг случится что? Паника, например?

Товарищи, привет! Кто sqlx юзает? Когда в функции стартуешь транзакцию, надо ли по defer ее роллбечить, если вдруг случится что? Паника, например?

зависит от задачи. в общем случае - нет

А как он понимает, что надо отменить транзакцию?

а?!

обычно, ели транзакция не прошла успешно - ее надо ролбечить

но штука в том, что транзакция держит коннект к базе

и, если ее не завершать - коннекты быстро заканчиваются

Товарищи, привет! Кто sqlx юзает? Когда в функции стартуешь транзакцию, надо ли по defer ее роллбечить, если вдруг случится что? Паника, например?

Since transactions are connection state, the Tx object must bind and control a single connection from the pool. A Tx will maintain that single connection for its entire life cycle, releasing it only when Commit() or Rollback() is called. You should take care to call at least one of these, or else the connection will be held until garbage collection.

что происходит с коннектом, когда до транзакции добирается gc - я не в курсе, надо код смотреть.

но, скорее всего, ничего хорошего - деструкторов-то нет

Да, я читал это. Жаль, что в го нет деструкторов( Я просто даже не знаю, как поступить. Если вешать defer, то есть шанс, что паника случится уже после нормального коммита.

а надо разбить код по функциям правильно

чтобы не было такой опасности

или выставлять по комиту флаг, и проверять его в deffer

но первый вариант лучше

обычно именованный возвращаемый параметр + блок // Making sure the tx is closed regardless of the result defer func() { if err != nil { tx.Rollback() return } err = tx.Commit() }()

но первый вариант лучше

ага, лучше, когда у тебя не используются левые функции для отправки запроса в базу, которые могут паниковать

лучше, когда у вас код правильно структурирован

Я понял, надо делать функцию, которая начинается с begin, а заканчивается коммитом) Тогда любая паника может случится только внутри транзакции (ну или при коммите, если соедниение пропало, но тут уже все равно)?

вообще, конечно, лучше бы панику не ловить.

ну это понятно

но мало-ли что

ваша программа завершится, транзакция откатится по закрытию соединения

вот как раз на случай мало ли что лучше и не ловить

а если это сервер, который также обрабатывает еще 1000 клиентов, у которых все ок?)

если хлопнулся ваш код - лучше заменить панику на возврат ошибки

ваша программа завершится, транзакция откатится по закрытию соединения

вот я это имел ввиду говоря, что в общем случае явеый роллбэк не нужен

если не ваш - скорее всего, либа, которая панику кинула, продолжать работу не может

Вброшу про тестирование публичных/приватных методов: https://youtu.be/yszygk1cpEc?t=1925

видимо, это тоже опилка 🙂

думаете?

ну, аргументы у него такие же, если что-то внутри сложное, нужно это тестировать, - чтобы быть уверенным во всех слоях, и чтобы при ошибке - сразу понимать где именно и что сломали

аргументы в пользу какого тезиса у него такие же?

тут проблема та же, что и с большинством тестов, какие я видел

ваша позиция не основана ни на чем, кроме ваших же ощущений

и тесты вы такие же пишете - ни на чем не основанные, кроме ваших предположений

и необходимость их написания обосновываете вашими же соображениями о здравом смысле

я спросил - зачем нужны тесты

ответ был единственный: "чтобы ошибка не попала в прод"

3 пункт на слайде, на который дана ссылка "some people take it too far and choose only integration/acceptance tests" - это то, о чем вы говорите

нет

не об этом

integration/acceptance - это не про юнит-тесты вообще

как это - у вас есть спека - это acceptance - то, что волнует заказчика

а вот это - опилки

про заказчика мы поговорили уже

3 пункт на слайде, на который дана ссылка "some people take it too far and choose only integration/acceptance tests" - это то, о чем вы говорите

это вообще не имеет отношение к разработчикам и юнит тестам.

что тут скажешь, поэтмоу и говорю, докладчик тоже опилка, как и часть этого чата

скажите - а вы всегда стоите на своем до конца?

когда есть вермя, и спорим явно о цвете фламастеров, почему бы и нет, ваше подход правилен для 70% кода, который я писал, но говорить о том, что это абсолют - странно

абсолют...

если делать правильно

1. пишете спеку на внутреннюю функцию

2. утверждаете ее у тимлида, вносите как-то в доку (как?)

3. пишете в соответствии со спекой тесты

4. отправляете их тимлиду на ревью

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

6. вы продолжаете стоять на своем

вот это настоящий абсолют, нерушимый

если задача сделана в срок, то тимлида не волнует, на каком уровне разработчик тестирует пакет, также наличие спеки внутренних функций, а стайл гайды вырабатываются командой на основании личного опыта участников

вопрос

а есть ли у вас вообще тимлид?

или это тоже опилки?

это кому вопрос?

если задача сделана в срок, то тимлида не волнует, на каком уровне разработчик тестирует пакет, также наличие спеки внутренних функций, а стайл гайды вырабатываются командой на основании личного опыта участников

это ответ на это сообщение

оу, тимлид есть, с ним как раз согласовываются спеки для внешних интерфейсов

а кто будет проверять, что спеке всё соответствует? что спека покрыла все случаи? что реализация также покрыла все случаи?

примерно 90% того кода, что я написал, спеки не имели, не имели и тестов, соответственно

почему разработка спеки не включает в себя разработку тестов?

хорошо, когда имплементишь что-то по RFC - там спека есть

примерно 90% того кода, что я написал, спеки не имели, не имели и тестов, соответственно

ну - мне так писать неудобно

может включать, может не вклюать, зависит от процесса, у нас такого нет

ну - мне так писать неудобно

всем неудобно

всем неудобно

ну вот. и я просто стараюсь не писать ничего без тестов

примерно 90% того кода, что я написал, спеки не имели, не имели и тестов, соответственно

вы считаете это нормой?