Насколько следует строго придерживаться буквы ТЗ?

А какой хурмы оно вообще исключение в этом случае не бросает? Типа штатная ситуация, что база отвалилась или кривой запрос в продакшене? Если оно правильно завернуто в транзакцию и нормально бросается исключение, то зачем в каждом запросе проверять? Вручную всю портянку запросов откатывать? Или какая-то другая реакция нужна если один из 10 связанных апдейтов не выполнился?

Предлагаю тебе попытаться пару раз согласовать ТЗ с ожной и с другой стороны. Слово «очевидно» заиграет новыми красками.

Это где так принято? Как вообще тогда консистентность проверить? Что-то выполнилось, а что-то нет, получается мусорная база. Как по мне тут функциональный элемент частоназываемый railway oriented programming + откаты и выдача ошибки точно к месту.

Писал тут уже псевдокод процедуры (например):

BEGIN
    /* тут много SQL кода, про который никому знать не обязательно */
    EXCEPTION
        WHEN NO_DATA_FOUND THEN /* пойти налево */ err := 2
        WHEN UNIQUE_VIOLATION THEN /* пойти направо */ err := 3
        WHEN OTHERS /* вообще всё сломалось, лечь и умереть */ err := 99
END;

Это называется «бизнес-логика в БД». И оно мне нравится.

Просто потому что шило в попе ну вообще никак не помогает

Развитие напрямую влияет на доход. Ну и на спектр решаемых задач. Если человека не мотивирует зарабатывать больше деньгиев, решая более интересные задачи, то, наверное, стоит к нему с некоторой опаской относиться и сильно на него не рассчитывать.

Предлагаю тебе попытаться пару раз согласовать ТЗ с ожной и с другой стороны. Слово «очевидно» заиграет новыми красками.

С одной стороны опыт есть. Со стороны исполнителя опыта нет. До сих пор считаю, что есть очевидные вещи.

Как вообще тогда консистентность проверить?

В том и соль «бизнес-логики в БД», что это не забота внешнего мира. Внешний мир мне говорит, что он хочет в общих чертах - я внутри процедуры сам решаю как это лучше сделать и что ещё подергать по дороге.

Во внешний мир я могу вернуть код - получилось ли.

если он бьёт себя ладошкой по лбу и молвит: «А, точно! Как же я зыбыл? Спасибо за подсказку!»

ну всякое бывает, бывает что «забыл», тут дело-то в том, что у ТС-а кто-то уперся рогом и ладошкой себя не бьет.

В смысле вы просто принесли тз и вам его подписали?

В Т3 невозможно заранее все предусмотреть - иначе для составления ТЗ надо будет сначала его реализовать, кроме того, какие-то вещи вообще в базовую культуру что ли входят, как проверка кодов возврата. Тут наоборот, чтобы их не проверять нужно обоснование почему.

Это при разумном подходе, конечно. Бывают скандальные какие-то ситуации.

Я тут периодически срусь с Питонистами/PHPшниками/etc что им таки следует проверять код возврата от БД об успешности внесения изменений.

На что они мне возражают «этого нет в ТЗ».

Вы неправильно «срётесь». Если подрядчик по вашему мнению что-то делает не так, то: служебка, подпись, протокол, сдал-принял и отпечатки пальцев. Но для оформления служебки надо иметь скилы.
Однако есть нюанс, если подрядчик «замазан» а вы тут «мимокрокодил», то никакая служебка не поможет.

В Т3 невозможно заранее все предусмотреть - иначе для составления ТЗ надо будет сначала его реализовать

Работа с техническим заданием, вплоть до подписания акта о выполненных работах оговаривается в договоре. Разве не так?

И никто вам не запрещает редакции технического задания и дополнения. И снова, и опять же - всё начинается не с технического задания, а с утверждения обеими сторонами договора, пусть даже и устного. :)

Ну, а если договора никакого не было или одна из сторон никак не желает выслушать и согласиться с мнением другой стороны, то какие тут могут быть взаимоотношения? Только санкции!

В Т3 невозможно заранее все предусмотреть - иначе для составления ТЗ надо будет сначала его реализовать

Дык на сабж заказчик выставляет технические требования, а подрядчик уже формирует ТЗ которое утверждает заказчик.

А то их код будет патч Бармина выполнять, а они «нет в ТЗ, чтобы не делал такого».

Вообще-то, это называется «исполнение кода, не предусмотренного ТЗ», и, вообще-то, за это самое атата бывает. Но у программистов другой мир.

О да, это боль…

Звучит как «настучать». Стрёмно.

Дурь какая-то. Нахрена тянуть эти ваши тюремные понятия в рабочие отношения?

Когда заказчик прямые претензии к коду выдвигает - я рассматриваю.

Если человек дело говорит, что б ему навстречу не пойти? И самому приятнее. Обычно, обоим сторонам плевать на код, лишь бы работало, и побыстрее, побыстрее! Если заказчик готов время мне дать на вылизывание - ну, прекрасно. Это редкость редкостная.

С другой стороны, я и аргументировать могу, если он дичь предлагает. Обычно на той стороне понимают

Изначальное ТЗ может быть очень разным по технической конкретике и детализации. Обычно описывается идеальный безошибочный сценарий, и поведение при ошибке описывается только тогда, когда есть несколько вариантов, и заказчика интересует конкретно один из них. Во всех остальных случаях подразумевается, что при возникновении ошибки реализация будет вести исходя из «здравого смысла», и так, чтобы не нарушить требования того же ТЗ.

Я ниразу не видел, чтобы было в ТЗ написано что-то о кодах возврата. Это самый низший уровень кодинга, и нормального заказчика это не должно интересовать.

Другое дело, если под ТЗ подразумевается конкретная реализация, разжеванная синьером джуну, чтобы последний вообще не думал, а кодерил по бумажке. Но это уже другое техническое задание.

А, так ты про реализацию бизнес логики, когда ее не покрывают тестами, линтером, когда не гарантируется ее консистентность в случае кластера, потокобезопасность и прочее? Ну тут да, разумно всё десять раз перепроверить, раз уж изначально архитектура говно, то сюрпризов может быть много.

Это говно.

Вы там ПДО не используете штоль?

ПДО - фу

Как и все аналогичные полуавтоматизированные обёртки.

Я конечно же верю, что общение с базой ты пишень на сырых сокетах, но не все в мире такие упоротые.

Я ниразу не видел, чтобы было в ТЗ написано что-то о кодах возврата

Если это ТЗ на API, то очень даже пишется.

они подразумевают, что при любом вообще неуспехе этот запрос «упадет» (неважно из-за рейза или нет, и неважно с каким склстейт), а дальше, вероятно, разумный драйвер доступа при упавшем запросе бросит исключение, которое они не будут ловить а дадут всплыть в блоке файнали откатив т. деталей твоих не знаю, но может быть, что твоя фигня кривовата. мне думается, что тут дело не в «техническом задании», документ называется «документация» на твой скл-апи, где должно быть сказано, что при неуспехе ф. делает то-то (возвращает резалт-сер внезапно). но раз уже такое возникло и переделывать невозможно, они должно потребить твою фигню согласно тому, как ты придумал и документировал, то есть расставить проверки везде или соорудить обертку. незабудь убедиться, что успешный резалт-сет всегда отличим от неуспешно

На что они мне возражают «этого нет в ТЗ».

В «правильном ТЗ» должен быть пункт: «допускается изменение ТЗ по согласованию сторон».
В противном случае можно устраивать «итальянские забастовки» ©.

Оно не я придумывал, оно тут всегда так было.
И никто уже не помнит зачем и почему. И документации, понятно дело нет.

Они мне - хочу_это(бла-бла) - я им {«ret»: 0, «data»: [bla-bla]}::json (плюс/минус)

Но странно всё равно... вы ведь когда прерывания дёргаете, или сисколы - у вас же не возникает вопроса проверить регистры после? Почему дергая процедуру в БД такой вопрос возникает?

Нужно реализовывать допустимый минимум, чем меньше телодвижений тем лучше (мне). Не испытываю никакой любви к заказчику, компании и проектам которые я делаю.

этого нет в ТЗ

Фраза «этого нет в ТЗ» слишком вырвана из контекста. ТЗ чаще идет именно на бизнесовом уровне, а техническая проработка от нее не зависит. Но описанный пример это как раз часть продуктового мышления. Поэтому гребцы так боятся джунов с курсиков.

напрямую

Да щаз. Влияет, но как один из факторов. Но если человек обменивает выходные на надежды - конечно за него надо хвататься, где ещё такого дурака найдёшь

Почему дергая процедуру в БД такой вопрос возникает?

протокол позволяет отразить ошибку, т.н. «драйвер» (библиотека доступа к БД) «видит» эту ошибку и далее либо даёт возможность программисту явно ее проверить, либо (что более разумно) автоматом бросает исключение. и даже уродский pdo можно сконфигурировать чтобы бросал исключение. я не знаю, но возможно, что потребители рассчитывали именно на это, т.к. это sane способ организации.

вы ведь когда прерывания дёргаете, или сисколы - у вас же не возникает вопроса проверить регистры после

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

если я правильно понял, у вас сложилась вторая система сигнализировать ошибку (протокол в протоколе), возможно они отказываются ее признавать.

Оно не я придумывал, оно тут всегда так было. И никто уже не помнит зачем и почему. И документации, понятно дело нет.

моё понимание таково, что если переделать нельзя, они как потребитель должны потреблять в соответствии с тем как оно работает, даже если криво. НО, это поведение должно быть документировано и доведено до них. если же оно не документировано и не доведено до них, то ничего проверять [добавлено: сверх протокола] они не должны.

Тут, кстати, стоило тогда сразу и про вторую боль спросить.

Это нормально, что программисты нынче общаются скриншотами? Просишь показать код - показывают снимок экрана с кодом.

Сбрасывать стресс в ЛОР, так сбрасывать.

Если ты получаешь процент от дохода за работу проекта - то чем больше ды додумываешь сам, тем лучше.

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

Текст форматируется в мессенджере плохо

Это нормально, что программисты нынче общаются скриншотами? Просишь показать код - показывают снимок экрана с кодом.

Тебе копипастить? Или чё?

Кодинг под диктовку — пошарь экран.

Просто пазырить — так скриншот оставляет форматирование и раскраску.

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

Obezyan, как у вас с этим?

У нас, у обезъян, с этим все хорошо потому что есть PSR (PHP Standards Recommendations). В частности, есть стандарт PSR-7. В нем описан объект Response, у которого должен быть определенный числовой статус ответа из HTTP/1.1.

Вы прописываете в ТЗ очевидные вещи? Или «раз этого нет в ТЗ, значит в этом есть какой-то глубокий смысл и не нашего ума дело»?

В ТЗ указывается что API должен соответствовать следующим PSR стандартам: PSR-3 (Logging), PSR-4 (Autoload), PSR-7 (HTTP message interfaces), PSR-11 (Container Interface), PSR-11 (Container Interface) и тд.

Запрос же к БД возвращает true/false по выполнению, если false то детали с кодом ошибки идут в лог. А апишка выдает код статуса в ответе по PSR-7.

Да нет. Ничего из перечисленного.

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

Почему-то сразу анекдоты про бухгалтеров со сканированными документами в Ворде в голову лезут.

----

Ну..... нормально, так нормально. Ладно.

Можно сделать отдельный документ со сборником лучших практик программирования - можно насобирать по интернету и дополнить своим опытом. А в ТЗ ссылаться на этот документ. Он же будет один на разные проекты.

Можно сделать отдельный документ со сборником лучших практик программирования - можно насобирать по интернету и дополнить своим опытом. А в ТЗ ссылаться на этот документ. Он же будет один на разные проекты.

Это и есть PSR

Форматирование. Ну и можно выделить нужные блоки стрелочками.

Код или текст на маке из скриншота сейчас распознаётся, можно прямо из картинки скопипастить, как обычный текст.

Форматирование кого-то волнует кроме педонистов, без которого у них код сломается?

Виноват, не понял. Можете на конкретной ситуации пояснить?

• Пользователь инициирует запрос на некое изменение в БД.
• «Апишка» пошла в БД, но там произошло исключение и изменения не внеслись (вся транзакция, которая должна была произойти, откатилась).
• «Апишка» об этом может узнать только по коду, возвращаемому процедурой в JSON-ответе. Исключения и ошибки БД «апишка» не видит. Только ошибки более высокого уровня протокола/приложения.

Как на ваш взгляд должен поступить программист «апишки» если он знает, что пользователь ожидает увидеть изменения и не видит?

Влияет, но как один из факторов

Без этого фактора лучше искать другие источники дохода.

«Апишка» об этом может узнать только по коду, возвращаемому процедурой в JSON-ответе. Исключения и ошибки БД «апишка» не видит. Только ошибки более высокого уровня протокола/приложения.

Почему же, она видит эти исключения. Все зависит от уровня ошибки, если это исключение как в вашем примере, то оно из ORM попадет на уровень HTTP client (PSR-18) в стандарте которого описан Psr\Http\Client\ClientExceptionInterface. В классе реализующем данный интерфейс и будет логика что делать с конкретными кодами конкретных исключений, будь то БД или 3rd-party сервисы.

Есть еще два интерфейса которые расширяют указанное выше поведение, это Psr\Http\Client\RequestExceptionInterface.php и Psr\Http\Client\NetworkExceptionInterface.php для обработки исключений на разных уровнях. Можно также создавать свои интерфейсы, наследовать от ClientExceptionInterface и в реализации класса писать свою логику работы с исключениями.

Пока я писал это комментарий форум упал с org.springframework.jdbc.CannotGetJdbcConnectionException:

Failed to obtain JDBC Connection; nested exception is java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms (total=10, active=10, idle=0, waiting=189)

К сожалению, произошла исключительная ситуация при генерации страницы.

Произошла непредвиденная ошибка. Администраторы получили об этом сигнал.

Как видите, на ЛОРе также пробрасывают и обрабатывают эти исключения :)

нынче общаются скриншотами

Ещё лет 10 назад столкнулся с тем что на просьбу скинуть стректрейс ошибки мне прислали линк на файлообменник со скриншотом стектрейса из окна консольки. Так что это давно началось.

пользователь ожидает увидеть изменения и не видит?

Что по ТЗ должен увидеть пользователь?

Что по ТЗ должен увидеть пользователь?

Не оговаривается. Этого нет в ТЗ.

Форматирование кого-то волнует кроме педонистов

подсветка кода же

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

«Апишка» пошла в БД, но там произошло исключение и изменения не внеслись

– Я тебе запрос на сохранение данных послал?
– Послал.
– Ты его выполнил?
– Выполнил.
– Данные сохранились?
– Похоже на то.
– И где сохранённые данные?
– Какие данные?

Погоди, а какое тогда очевидное поведение?