Мое личное мнение:
работе на фронте это сидеть и пытаться предугадать куда сейчас эта обезьяна с другой стороны захочет тыкнуть и что мне дальше с этим делать.
Часто это доходит до обсурда.
В том числе ты начинаешь делать работу бека на фронте, потому что проще сделать самому чем дождаться и обьяснить что нужен роут с отсортированными данными вот тут.
Проще вытянуть и отмаршировать самому написав ебанутый набор колбеков.
А тестировщики только и рады потому что это их работа ломать то что было сделано.
На беке все четко, вот на нем я как раз четко знаю что прийдет, что сделать если пришло не то что надо.
Лично я не имею большого опыта ни в том ни в том, но больше получаю удовольствие от бека именно по тому что лучше понимаю что от меня хотят на выходе в отличие от фронта где можно 20 раз все предусмотреть но прийдет человек и начинает мне показывать что это все херня и вот тут я ещё вот такую кнопку хочу с данными которые ты вообще сам пойди в поле найди.И ещё одна ремарка, у людей будет в итоге не работать сайт, или приложение, прийдет заказчик скажет вот тут не работает сайт, и ебут всегда фронт, а потом может и до бека дойдёт, но фронт всегда получает пиздюлей первый, хотя в половине случаев он вообще не в теме :)
Бэк, который не может отдать отсортированные данные надо пиздить ногами до полного просветления. Это я как бэкендщик говорю.
Есть, впрочем, исключения, но их предельно мало.
В трёх разных компаниях работала - везде за релиз несли ответственность QA. И пиздюлей отхватывали мы в первую очередь. Я всегда ржу с этой несправедливости)) все деньги и почет разрабам а ответственность и пиздюли - нам, тестировщикам
пытаться предугадать куда сейчас эта обезьяна с другой стороны захочет тыкнуть и что мне дальше с этим делать.
это работа BA/продакта и дизайнераначинаешь делать работу бека на фронте, потому что проще сделать самому чем дождаться
Плохо работают архитектор и ПМ/скрамастеребанутый набор колбеков.
опять плохо работает архитектор, ну и тот кто тебя на работу взял. Какие к черту колбеки в 2020. Не слышал никогда про rxjs? Или хотя бы async/await
На беке все четко, вот на нем я как раз четко знаю что прийдет, что сделать если пришло не то что надо.Это многое объясняет
Лично я не имею большого опыта ни в том ни в том
но фронт всегда получает пиздюлей первый
Вы чё без QA работаете?
Ты че с гугла пришёл? Ухади абратна.
Если глянуть на вакансии, то в среднем каждый фронт должен (по мнению работодателя) знать бэк, дизайн, работать с БД, все это тестировать, естественно. "Или нам ещё тестировщика нанимать и зп ему платить? Да ты ахуел". Ну и время от времени, само собой надо и локалочку бы поднять, маршрутизаторы настроить и проводку в розетке поменять
Где ты такие требования нашел? Скинь поржать ибо я такое только на ебаном видел пару раз😄
Ну или же в конторах, где начальство просто начальство, без каких-либо знаний в области ИТ.
Я когда начинал, то тоже и дизайн сам придумай, и фронт, и бэк, и сисадмин, и SEO, и копирайт.
Web галеры. Слышал про такие? Чтобы попасть на такую работу которую я описал выше, нужно погрести тут пару лет. Такие дела.
Берете книжечку по скраму, читаете, клиента назначаете продактовнером, из девов выбираете скрамастера.
И вот уже появляется какой-то порядок, клиент лучше видит прогресс, меньше меняет свои хотелки, а у разрабов не горит ведь это часть рабочего процесса и посреди итерации поменять требования нельзя
На беке все четко, вот на нем я как раз четко знаю что прийдет, что сделать если пришло не то что надо.Знаем плавали) Чуть что не так - 500 или 400.
К сожалению, нередко бэкендеры не особо вдаются в бизнес-смысл запросов, обрабатывают один позитивный сценарий и считают, что этого достаточно. А о том, что пользователь может сделать 100500 действий, которые будут бессмысленными, но валидными, не думают.
Понятно, что бывают разработчики хорошие и разные, но подход "у меня все четко, а с юзкейсами пусть фронт разбирается" - зачастую пагубен.
Один просто делает от А до Б, другой думает о бизнесе, о юзере, о хотя бы ближайшем будущем системы
Чего ж сам бизнесмен о бизнесе не думает, выдавая тз.. да и в принципе разрабатывая бп. Какой же идеальный мир бы был, если бы все всё делали правильно))
А дальше он может придти к кодеру Васе, который сделает согласно кривому ТЗ какую-то кривую неподдерживаемую какулю потому что он не хочет думать, ведь это не его работа.
Или он пойдет к разрабу Пете, который подумает, объяснит бизнесу где в ТЗ он не прав и разработает нормальную систему которой будет удобно пользоваться юзеру, которая решит проблемы бизнеса и которую будет возможно поддерживать
Как думаешь после посещения какого из ребят у безнеса в итоге будет больше денег? А как следствие какой из ребят будет иметь больший доход?🙃
Да при чём тут кривой код и удобство, я же не про это.
А, всё, перечитал коммент выше и понял, что сам не о том немного подумал, бывает))) Я думал там "бизнес сценарии" какие-то имеются в виду. Типа доход учли, а простой и расход нет. Признаю, не прав был. Теперь понял про что речь шла))
Я вообще не об этом подумал и уже ниже человеку отписался, в чём ошибся. Ваще о другом говорил))
Интересное мнение. Работал по обе стороны барикад. На всех проектах старались сделать фронтенд максимально тупым. ВСЯ бизнес логика должна проходить проверку на бекенде. С фронта хера лысого можно прислать и это вовсе не значит, что сервер должен это кушать. К слову, обе стороны имеют свои сложности. Но в итоге выбрал чистый бекенд - кроссбраузерность и верстка убивали меня.
Есть разработчики, вообще разрабатывающие REST-API чисто как прокладку между фронтом и БД) Но речь сейчас не об этом.
Есть, например, таблица с фильтрацией. И там есть фильтр по дате. Пользователь выбирает: 01.02.2020 - 01.01.2020. С бэка прилетает 500-ка.
В целом это, конечно, бессмысленный кейс. Но ведь валидный. И ожидаемый результат в этом случае - пустая таблица, а не "внутренняя ошибка".
Если на фронте нет валидации (а в фильтрах обычно это так и есть), то данный кейс допустим и данные считаются валидными.
Я придерживаюсь мнения, что HTTP-ошибки вообще не должны приходить при нормальном поведении приложения. Если приходит 5** - баг на сервере. 4** - баг на фронте. Если бэк хочет прислать бизнес-ошибку, пусть заворачивает в 200.
Исключение - только 401 ошибка.
200 ошибки не идут в обрабитчик ошибок же. Приходится каждый 200 ответ проверять на правильность. Ломается типизация данных. Ибо каллбек ожидает список ордеров, а ты ему {message:"Idi nahui"} суёшь!
Если ответ сервера подразумевает возможность бизнес-ошибки, то надо данные типизировать соответствующе. Что-то типа {orders: ['array'], error: 'message'} Если такое происходит часто - лучше не городить велосипедов и взять какой-то существующий протокол типа hateoas, json-rpc, что там еще есть?
Проблема в отлавливании ошибок в catch в том, что смешиваются мухи с котлетами, т.е. нормальное поведение с ошибками. Приходится разделять эти сценарии, ориентируясь на строковые сообщения ошибок, что в принципе плохо, так как создает неявную связь между фронтом и бэком.
Аналогичным образом в большинстве языков не рекомендуется использовать исключения для обработки бизнес-сценариев. Правда, там еще и вопросы производительности встают.
Ну это же не .net где ошибки очень дорого кидать. По-моему 200 означает happy path а 4хх, 5хх всё остальное, что нужно обрабатывать отдельно. Просто по моему опыту.
Отделение мух и котлет - элементарно. Читаем ошибку и если это aхios ошибка значит из неё берем status и message. Всё решается в одном месте в 5 строк.
Давайте я приведу пример.
Есть следующая логика: делаем запрос на то, является ли пользователь клиентом нашего банка, если да, предлагаем войти в личный кабинет, если нет, предлагаем им стать.
Для этого отправляем запрос на поиск клиента по указанным данным.
Предположим, сделали как вы сказали. Если клиент найден, возвращаем его данные, если не найден - возвращаем 404. Если клиентов, удовлетворяющих данным условиям несколько... Вот уже проблема. Но ладно, выведем 400.
Ловим ошибки в catch, проверяем код ошибки - если это 404, предлагаем стать клиентом, если 400 - пишем, что найдено больше одного клиента. Все круто.
Но в один прекрасный момент пользователь вобьет в номер телефона не 11, а 12 цифр. Бэк пришлет 400-ю ошибку из-за неправильного формата, а мы что? Выведем что якобы клиентов больше одного.
Далее, допустим в какой-то момент бэк упал и адрес стал недоступен. Мы получаем 404 и что? Предлагаем стать клиентом.
Получается хрень. Чтобы такого избежать, придется писать что-то типа "client not found" в message и потом на фронте это проверять. Но вдруг какой-нибудь бэкендер, не зная об этом, решит уточнить ошибку и выводить "client not exist" или "can't found client with this data". Опять все сломается, и ведь не сразу даже докопаешься.
Поэтому мой подход - все бизнес-сценарии должны обрабатываться с успешными кодами. Если возникает HTTP-ошибка - это значит, что что-то технически пошло не так.
хмм....
И да и нет. Наверное дело вкуса и удобства работы с IDE.
Ничто не мешает в респонсы ошибок писать данные для бизнес логики.
Типа 404
{message:"UserExists"} и если приходит 404 с любым месседжем, то мы знаем, что юзер не был найден, а не то, что ендпоинт упал.
И вообще 404 с неправильным форматом должно отсекатся еще до этого и обрабатываться как Network Error
Но это вкусовщина, сойдёмся на том что бек валенок)
з.ы. 403, 404 двухсотками ты не отдашь
Это пока ты не хочешь поменять даты на месяц вперёд начиная ОТ, а у тебя не получается потому что ОТ не может быть больше ДО
А с фига 500 ошибка может вообще прилететь?
SQL пофиг на такие данные, всяким лямбда выражениям тоже. Не обработать на бэке пустой результат запроса - это даже не джун, это чувак кодящий копипастой, слабо представляющий как это вообще работает.
Ну, например он может взять разницу между датами... Короче, не знаю, это просто пример. Просто с некоторыми бэкендерами ситуации, когда в ответ на странные, но валидные сценарии прилетает 400 и 500, случаются весьма часто(
лол, закрыл только что ебаную таску, где данные с бэка приходили в виде
[
{data: [...]}
{data: [...]}
....
]
а из них надо было просто сделать таблицу, по сути смержить объекты, и прочитал этот коммент)
Ох уж этот БелАЗ грузоподъёмностью 1 кг. с кучей колбек панелей и хидденфилдов. А я к нему привык.
мне 32) , хочу сменить сферу деятельности но не верю даже сам в себя. , может с высоты опытного человека, направите или подскажете стоит ли в АЙТИ войти в таком возрасте не поздно ли?) , какую сферу на ваш взгляд лучше рассматривать? Понимаю в целом сферу, и какие языки куда нужны , (образование из области IT). Буду очень признателен вашим советам если возможно)Ps тоже хочу 150 и не работать в продажах- надоело просто)))
я в 31 решил уходить, и уже год работаю, главное понимать что легко не будет и тупым себя чуствовать первый год это нормально, надо понимать свой уровень подготовки, потратить примерно год на обучение и реально себя оценивать, многие люди относятся как к обучению в университете, типа вот корочка я курсы прослушал и т.д. Тут корочки никому не нужны, тебя посадят за комп и будут тонкие места спрашивать для твоего текущего уровня.
Советую начинать с js, чтобы зацепится в сфере а потом как устроишся учить нормальный язык паралельно типо C# или Java.
И еще в процессе обучения учить не конкретно язык и фреймворки а само програмированние, в смысле пытатся хоть немного понять что под капотом происходит, потому что знание многих людей остаются на уровне курсов котрые они прослушали, когда им показывают чтото новое они будут его использовать имеено так как написанно и показано, никому в голову не прийдет подумать что же все таки такое показали, и реально понять что это за интсрумент.
И ещё одна ремарка, у людей будет в итоге не работать сайт, или приложение, прийдет заказчик скажет вот тут не работает сайт, и ебут всегда фронт, а потом может и до бека дойдёт, но фронт всегда получает пиздюлей первый
Я работал в одной компании на одном проекте, и сейчас в другой на другом проекте, но в обеих компаниях специфика сайта такая, что ебут в первую очередь бек)
Бек проверяет, не у них ли что-то отвалилось и затем уже может на фронт прилететь, если у бека всё ок
IT-юмор
5.6K постов52.5K подписчика
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору