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

Ну внеси это. А желательно вообще какую-то общую формулировку против идиотизмов. А то их код будет патч Бармина выполнять, а они «нет в ТЗ, чтобы не делал такого».

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

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

Прикольный диспут. Я бы уволил нафиг, если бы мне такое выкатил разраб.

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

Нет, ТЗ не описывает обычно необходимость проверок ошибок бд, сети, файла, и т.д. В нетривиальных случаях лид обычно спрашивает, типа так и так, такая фигня всплыла, варианты решения такие и такие, разовьётся так и так. Куда идём?

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

Нанять грамотного спеца вместо «выполнятеля тасков», что делает все быстро, но на от***сь — сложно. У всех же KPI, нужно быть «эффективным», а не адекватным и качественным в работе.

Просто не надо останавливать найм ни на минуту )

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

В конце концов задача начальника в том числе в улучшении команды.

А кпи твой — фигня это все, нифига не работает и не надо начинать.

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

Правильно делают. Решайте этот вопрос на уровне тестов, внутренних соглашений касающихся кода в рамках проекта.

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

Полностью, ну. Клиент, которому сделали всё как он просил - лучший, придёт ещё. Ведь как ему надо ему не сделали, а исполнители хорошие

Я бы уволил нафиг, если бы мне такое выкатил разраб.

У вас не было опыта работы с заказчиком (внутренним или внешним - не важно), который вместо ТЗ просит вас накатать в свободном формате что-то типа КП и в итоге разработка сводится к бесконечной переделке «а я думал, что это будет по другому, а в КП всё описано обще, здесь надо так, а потом мы подумаем и еще раз переделаем»?

Если с ним договориться на оплату по часам - вообще без проблем, но когда стоимость проекта оговаривается сразу, то получается не очень.

в больших конторах не принято вникать и дискутировать.

принято код обкладывать тестами - такими, сякими, эдакими.

если код тесты не проходит - кода нет.

если кода нет - штатного сотрудника могут пожурить и\или мотивировать повышать квалификацию. стороннему разработчику платить за отсутствующий продукт никто не вправе и не будет.

возвращаясь к конкретике.
нет никаких проблем написать тест, который код, не производящий проверки, не пройдет.

Речь в данном случае о ситуации вида «Заказал чизбургер, а там тухлое мясо и вместо сыра пластилин. На претензию — ну вы же не уточняли, что он должен быть съедобен».

Просто не надо останавливать найм ни на минуту )

И новый будет хуже старого. Ещё и за бОльшие деньги, лол

Выходите на руководителя и пусть он с вашей подачи

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

И потом я и сам-то не уверен. Тут такая архитектура, что они дёргают процедуры, внутри которых БД сама перехватывает исключения и отдает ответ с кодом возврата.

Т.е. никаких Exception на той стороне действительно не видно. Примерно, как GoLang получается. На каждый вызов функции - надо проверить err руками. Вот они плюют в БД «запиши_это(id=1, это)» и идут дальше без проверок и исключений.

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

Вы прописываете в ТЗ очевидные вещи?

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

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

У меня есть опыт работы с разными людьми.

Если человек не проверяет ошибку после инсерта в бд и твердо убежден что такую проверку без ТЗ он делать не собирается — этот человек идёт нахер.

Тут нет места для дискуссии.

А что, в убогих языках ошибки записи вручную проверять надо?

С какого перепуга? Ничего конкретного в ОП, что позволяет так думать нет.

А что, в убогих языках ошибки записи вручную проверять надо?

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

всё согласно чертежу, чтоб не было.. жу

И новый будет хуже старого. Ещё и за бОльшие деньги, лол

Да, бюджет из года в год растет. Так и зп разраба растет, как и цены в магазинах, просто такой вот естественный процесс.

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

как я и делаю.

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

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

Вот они плюют в БД «запиши_это(id=1, это)» и идут дальше без проверок и исключений.

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

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

Ваще т нормально. Либо в этом есть системная проблема и ее надо подсветить, либо проблема с разрабом, либо ещё что.

Пусть задаст вектор

правила составления ТЗ

12 лет прошло, етить )

https://www.youtube.com/watch?v=MoUheJeEsig

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

Хорошо что тебе весело )

С одной стороны да, а с другой стороны логику обработки ошибок тоже надо писать, а если работа не оплачена(за то что не указано в ТЗ или иных руководящих документах не факт что станут платить), то зачем ее делать?

Если все элементарные вещи описывать в ТЗ, чем ТЗ будет отличатся от реализации? Языком?

зачем ее делать?

Чтоб работало? Зачем делать нерабочее? Ради денег?

Следуй не букве, но духу и всё будет хорошо :)

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

Но не у тебя, кек

Неправда, у меня с этим всё ок, лол

зачем ее делать?

Элементарная грамотность.

Либо это чисто мой личный фетиш, как угодно. Верю что есть компании, которые пишут ПО для одного пользователя, работающее на одном сервере, пригодное для запуска один раз для одной единственной демонстрации. И эти компании имеют многолетние традиции, массу заказов и постоянных клиентов. Охотно верю.

Мне такой подход чужд, если мы не про mvc какой, конечно.

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

Мы же не отождествляем бизнесовые проблемы (типа платеж не прошел, кому и куда слать ошибку? Пользователю? Банку? Сапорту?) и инженерные (файл для записи недоступен? Да а херЪ с ним, работаем дальше), правда?

Вот они плюют в БД «запиши_это(id=1, это)» и идут дальше без проверок и исключений.

Вы там ПДО не используете штоль? Оно ж само фейлится в случае чего. А так вообще отсылка к ТЗ валидный аргумент, вот нужно записать данные в бд и не получилось, что делать? Залогать и пойти дальше? Упасть и лежать? Вернуть юзеру сообщение? А какое сообщение? Сказать что он данные кривые вписал - так ещё валидацию прикручивать. Гуй для сообщеньки пилить на всех страницах где отпасть можно.

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

и твердо убежден что такую проверку без ТЗ он делать не собирается — этот человек идёт нахер.

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

Тогда как?

UDP - это такой протокол, который не требует подтверждений доставки. :) Вдруг вспомнил.

Одно из главных наблюдений, что я вынес за годы, это то, что вдумчивая работа с ТЗ и есть фундаментальное отличие хорошего исполнителя от плохого. Плохой исполнитель прикрутит квадратное колесо к машине и даже глазом не моргнет. Хороший же всегда переспросит у руководства, действительно ли оно хочет именно этого, и предложит ему лучшую альтернативу. Принимающие решение люди при постановке задачи часто упускают что-то из виду, имеют неверное представление и т. д. Как говорится, на местах видней.
И, судя по всему, это универсальный закон, который работает от стройки, написания ПО и до военного дела.

Оно ж само фейлится в случае чего

никто, никак, ни каким способом не сможет «само фейлится» снаружи БД, если в вызываемой процедуре

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

Если человек не проверяет ошибку после инсерта в бд и твердо убежден что такую проверку без ТЗ он делать не собирается — этот человек идёт нахер.

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

Так оно работает пока база работает

говно какое-то

Я уже подзабыл пых, но емнип пдо падает на всём, что не 0000.

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

А ещё в ТЗ не прописано, что по нужде нужно ходить в туалет и расстёгивать ширинку при этом. ТЗ не может и не должно покрывать все очевидные вещи, которые усваиваются в первые месяцы в профессии.

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

Своей работой надо нести не радость людям, а зарабатывать деньги. Если заказчик не указал функционал в ТЗ, то всё на усмотрение разработчика.

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

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

И вообще, техническое задание - это одно, а договор - это другое. Конфликты разрешаются в судебном порядке.

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

Горящие глаза это в том числе и гореть развитием в профессии. Читать книги, статьи, изучать новые подходы и практики. Развиваться, короче.

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

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

Ну тут я однобоко смотрю. Только в продуктовых компаниях работал. Чем меньше будет грабель на пути к проду, тем больше будет прибыль.

Хотя, отдавали тут на аутсорс аппку, так там все плохие примеры из треда встречались. Всё, чего нет в ТЗ, не существует. Работоспособность и устойчивая работа при этом роли не играет.