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

Сообщить пользователю что именно пошло не так - разве не очевидно?

Кабы оно было - пользователь бы и не тупил долго пытаясь сделать то что нельзя сделать, и ко мне бы не прибежал с вопросом ЧЗХ у меня тут в БД творится.

Нет?

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

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

другого пути нет.

Вы почему-то решили, что тут какой-то конфликт. Нет никакого конфликта. Ко мне пришел человек с жалобой, я пошел к бэкэндщикам - они сказали: «ладно, сделаем, просто этого не было в задаче»

Слово «срусь» тут так, для красоты. Я вообще обычно «срусь» внутрь себя, без внешних проявлений.

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

Вопрос именно в «зачем кому-то куда-то ходить и с кем-то о чем-то говорить

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

И ответ лично у меня не вызывает ни малейших сомнений: на все сто! Иначе, что за нафиг это ТЗ, если его не придерживаться хоть в чём-то? Или что за нафиг это ТЗ, в котором тексты видятся в пустом месте между строк?

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

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

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

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

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

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

Ты не прав, это зависит от наличия или отсутствия обработки ошибок в целом, что должно быть явным образом описано при постановке задачи. Хз как там в оффлайне, но на фрилансе все клали на это дело. Так и какой смысл что-то там проверять, если дальше лога оно никуда не пойдёт? try-catch на верхнем уровне — и так сойдёт, а доп. часы не оплачивают, так что с хера ли тратить своё личное время на идеологически правильный код — я решительно не понимаю.

Есть у меня подозрения, что в оффлайне всё примерно так же и тем питонистам, на которых ноет ТС, режут часы в угоду менеджерским KPI.

Какое отношение заказчика — таков и результат. Проверки, юнит-тесты, документация — всё это время, которое должно оплачиваться.

А в своих личных проектах проверяю конечно же.

Ну вот, так я и думал. А раз он ничего не должен видеть — то пусть думает, что всё нормально. Если фронт в принципе не принимает ошибки, то я вообще хз как бэк их должен обрабатывать. И такое говно на каждом первом проекте.

Для REST API, например, в задаче всегда должны быть прописаны поля для ошибки и перечень этих самых ошибок, которые передаются енумами или ещё как-нибудь. А если таких описаний нет — то логично, что делают только try-catch.

код возврата от БД об успешности внесения изменений.

Любой нормальный программсит ОБЯЗАН это делать, чтобы у него же самого не было проблем в будущем.
Печально, что ты работаешь с роботами, которые не могут думать сами.

ты давай отделяй две ситуации.

1. допустим они проигнорировали ошибку вызова запроса пришедшую стандартным способом, то есть какое-нибудь pdo знает, что стейтмент упал, но у них эти состояния не конвертируются в исключения (или нет if), соответственно UI выглядит будто всё успешно. это одно. так быть не должно конечно.

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

cпроецируем это на http (К ОПу это не относится, у него там исторически сложилось, и не он это придумал, и наверняка есть причины почему так):

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

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

Уволь их, найми меня, потому как это верх идиотизма не проверять код возврата от бд. Поди они ещё и про тесты не слышали?

Там всё сложно...

На самом деле - любой другой ответ кроме "...этого в задаче не было..." я б, наверное, и не триггернулся.

одним из очевидных «выходов»

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

как то так

совсем отдельный вопрос - давно ведь известны последствия залёта дятла в дома построенные архитекторами следующими образу работы программистов