Лапшекодим валидацию, или запрещаем вводить неправильные данные?
Да, про валидацию...
Заполнил сегодня форму.
Кликнул Сабмит...
Вылезла следующая валидация:
There is an error with this candidate:
Missing required field:
никаких других пометок нет.
Посмотрел - все заполнено.
Подумал, поменял в паре мест нолик на единичку... и все пошло...
А ты говоришь - валидация, много писанины...
никаких других пометок нет.Посмотрел - все заполнено.
Подумал, поменял в паре мест нолик на единичку... и все пошло...
А ты говоришь - валидация, много писанины...
Ситуации разные бывают, когда тебе надо к примеру зарегистрировать машину, будешь вокруг компьютера вытанцовывать,
меняя нолики на единички, дополняя ноликами короткие номера, тк обрезают, а валидацию короткий не проходит итп итд.
пока не добьёшься не успокоишься... в худшем случае прозвон по телефону, на фирме девочки заносят данные от руки...
***
А теперь представим, ненапряжённую ситуацию, когда люди приходят добровольно, например рекламную акция - регистрация...
компания вбухивает мильёны денег в рекламу, проводит кучу праздников, - а люди почему то на странице не регистрируются???
пияр-манагер не понимает, никто не понимает... а всё потому-что новенький джуниор "почистил бесполезный мусор в коде"
и никаких ошибок система не выдаёт, логи не ведёт, МЕТРИКИ самое главное в этом бардаке тоже нет, чтоб исправить ошибку!
***
Это напоминает мне тему, где джунам всёравно точка или запятая, а людям в офисе разгребать лишние проблемы, с сортировкой:
https://foren.germany.ru/programmer/f/39534706.html#Post39...

И так - по всем 200+ полям на форме...
А когда осилишь - тебе еще с полсотни связанных таблиц кинут...
И так - с каждой формой.
Формы, где в каждой по полста связанных таблиц? - Неудивительно, что юзеры делают ошибки и не могут нормально заполнить такую форму. Надо 200 таблиц делать, чтобы наверняка!
Для полей вида "введите число" или "введите строку" можно, наверное, сделать простую подсказку (не всплывающую, а сразу возле лейбла) типа диапазона вводимых чисел или длину строки со списком исключённых символов?
Вылезла следующая валидация:
There is an error with this candidate:
Missing required field:
Поди, сообщение где-то в конце формы - типа, все сообщения валидации пишутся не напротив конкретного поля, а где-нибудь обособленно, на уровне формы. Тоже так себе подход.
Вы сейчас описываете банальные баги. Причём тут мой подход и баги вообще? Такие баги могут быть при любом подходе. Это не дискредитирует конкретно мой подход.
А теперь представим, ненапряжённую ситуацию, когда люди приходят добровольно, например рекламную акция - регистрация...
компания вбухивает мильёны денег в рекламу, проводит кучу праздников, - а люди почему то на странице не регистрируются???
пияр-манагер не понимает, никто не понимает... а всё потому-что новенький джуниор "почистил бесполезный мусор в коде"
и никаких ошибок система не выдаёт, логи не ведёт, МЕТРИКИ самое главное в этом бардаке тоже нет, чтоб исправить ошибку!
Гораздо круче, когда логов и метрик - вагон и тележка, но разобраться и понять из этого всё равно ничего нельзя. Зато диски логами забиты. Ну ты их конечно подчищаешь, убивая предыдущую статистику и всю суть подробного логирования...
когда логов и метрик - вагон и тележка, но разобраться и понять из этого всё равно ничего нельзя. Зато диски логами забиты. Ну ты их конечно подчищаешь, убивая предыдущую статистику и всю суть подробного логирования.
Ты за место на дисках не переживай, подключат ещё несколько штук или даже несколько шкафов. Информация и есть конечный продукт, за это платят деньги.
А вот анализ ошибок и всего остального могут не в ручном режиме, а специальными инструментами проводить, могут даже нейронную сеть задействовать, не?

А блокчейн?
"Due to the protocol changes of Ethereum: Rinkeby, Ropsten and Kovan test networks may not work as reliably and will be deprecated soon.
The Rinkeby testnet explorer has been discontinued and set to read-only on October 5th, 2022. Please migrate your contracts and deploy new ones on Goerli or Sepolia."
кароче, я в процессе переезда!

На другие нарко... тьфу, т.е. в другую область? )) Советую заняться сетевым маркетингом или политикой:
Каждый час в борьбе, каждый день как год -
Слёты, встречи, звонки, рапорта, выступленья.
Нас постоянно окружает народ,
Но мы с честью выходим из окруженья!
- Ну что, молодёжь, о чём мечтаешь?
в другую область? )) Советую заняться сетевым маркетингом или политикой:
В политику национальность у меня неподходящая, а вот в сетевой маркетинг можно, сейчас уже присматриваюсь...
хочешь стать моим рефералом, подо мной регистрироваться? пообещаю тебе мальдивы майями и нестыдную машину))

Вот сейчас типичный кейс валидации встретил, и какой-то странный. Запросили с сервера таблицу и показали юзеру на клиенте. Естественно, клиенту передали набор данных с айдишниками в БД, но в UI их не показываем - т.е. айди не редактируемый. Юзер хочет удалить одно данное. Что делает старый код, который я переписываю - он берёт айдишник выбранного для удаления элемента, делает запрос в БД - есть ли с таким айдишником объект. Если есть, достаёт этот объект, читает его айдишник и передаёт в запрос на удаление на сервер. Получается, что айдишник, который хранится в наборе данных, показанных клиенту, не используется для отправки на удаление на сервер. Это что-то типа валидации - проверка, есть ли такой айдишник в БД? Типа, на клиенте кто-то подменил набор, переданный изначально с сервера?
По-моему, это чушь и лишние запросы в БД. Если так уж не доверяете клиенту, что считаете, что он может нередактируемый айди подменить, то валидация явно должна быть не через запрос в БД. Просто при попытке удалить несуществующий айди будет исключение на сервере, которое передают клиенту, но смысл делать попытку отдельного запроса и доставания целого объекта, чтобы потом просто считать его айди и передать в запрос на удаление?
А главное, если айди существует, то при его подмене будет просто удалён другой объект. Но с точки зрения текущей валидации это норма... Бред какой-то! Ну и ещё главное - софт работает в закрытом виде на территории предприятия, в интранете, и наружу доступа нет. Подменить нередактируемый айди могут
лишь агенты госдепа работники, которые как-то взломали программу. Защита от такого взлома явно не этим тупым запросом с доставанием объекта делается. Остаётся одно - говно- и лапшекод, когда чел, его написавший, сам не понимал, что и зачем там происходит. Тут даже на самописный фреймворк не спишешь, т.к. даже по логике этого фреймворка написанный код делает какую-то лютую дичь.
Говоре же - гении делали. Там весь многосотстрочный говнокод можно на порядок ужать.
Типа, на клиенте кто-то подменил набор, переданный изначально с сервера?
Проверка лишняя, но понять можно. Пока мы смотрим на данные, другой пользователь может их уже удалить.
Просто, тоже самое может произойти и после валидации. Только временное окно будет меньше.
Да я не против, чтобы другой удалил. Но тогда будет исключение фреймворка, работающего с БД - его и будем обрабатывать и показывать - типа объекта в БД нет. Мне непонятно, почему автор кода пытается вытащить полноценный объект из БД, а потом прочитать его айдишник и затем по этому айдишнику удалить. Лишняя операция. Объект могут удалить между его чтением и его удалением по его айдишнику - и опять будет та же ошибка - по такому айди объекта нет. Смысла делать промежуточный запрос нет.
А как интересно он его пытается вытащить?
Я же говорил - из готового списка объектов в гуе, в котором хранится в том числе айди этого объекта в БД, берётся выбранный для удаления объект, читается его айди, по этому айди вытаскивается этот же объект из БД, читается айди вытащенного, даётся команда на удаление объекта по этому айди. А чё только два раза? Можно же было в цикле раз десять повытаскивать и посчитывать, и только потом удалить?
На проверку наличия перед удалением, как я сказал, не похоже - удалить могут в процессе проверки, т.к. она происходит в серверной части приложения, а не в самой БД. Да и в самой БД это явно не атомарная операция. И смысла в такой проверке нет, т.к. всё и так в трай-кэтч завёрнуто, так что ошибка ненахождения по айди при удалении такая же, как ненахождения по айди при запросе объекта.
Что делает старый код, который я переписываю - он берёт айдишник выбранного для удаления элемента, делает запрос в БД - есть ли с таким айдишником объект. Если есть, достаёт этот объект, читает его айдишник и передаёт в запрос на удаление на сервер. Получается, что айдишник, который хранится в наборе данных, показанных клиенту, не используется для отправки на удаление на сервер. Это что-то типа валидации - проверка, есть ли такой айдишник в БД?
Я бы сказал, что это не валидация, а оптимизация.
Подозреваю, что DELETE - довольно медленная операция (как минимум из-за того, что на время удаления надо блокировать БД), поэтому для того, чтобы снизить нагрузку на БД решили встроить дополнительную проверку и удалять только те строки, которые реально существуют.
Тут конечно встрает вопрос - удаляют ли строки достаточно часто, чтобы эта проверка иммела смысл. В принципе ты можешь легко проверить это предположение - сделай цикл из 10К итераций и замерь время выполнения до твоей оптимизации и после.
Возможно также этот код был написан для какой-нибудь старой версии БД, в которой была проблема с удалением несуществующих ключей.
Написано было для старой версии, но MS SQL Server. Далее, удаляются юзеры - для них явно скоростного и частого удаления не требуется.
Какая ошибка - не знаю, не пробовал пока юзеров удалять.
Да там всё проще, похоже. Я думаю, как и всё в этом древнючем приложении, тут не только "гении" чудили, но и код через десятые руки прошёл, где каждый подшаманил что-то своё, не сильно вникая. "Работает же? - Работает... А то, что через задницу - не моё дело, у меня на таску 15 минут." Что-то типа такого, наверное.