Фронт он такой

Фронт он такой

IT-юмор

5.6K поста52.5K подписчика

Добавить пост

Правила сообщества

Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору

Вы смотрите срез комментариев. Показать все
130
Автор поста оценил этот комментарий

Мое личное мнение:

работе на фронте это сидеть и пытаться предугадать куда сейчас эта обезьяна с другой стороны захочет тыкнуть и что мне дальше с этим делать.

Часто это доходит до обсурда.

В том числе ты начинаешь делать работу бека на фронте, потому что проще сделать самому чем дождаться и обьяснить что нужен роут с отсортированными данными вот тут.

Проще вытянуть и отмаршировать самому написав ебанутый набор колбеков.

А тестировщики только и рады потому что это их работа ломать то что было сделано.


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

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


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

раскрыть ветку (74)
110
Автор поста оценил этот комментарий

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


Есть, впрочем, исключения, но их предельно мало.

17
Автор поста оценил этот комментарий

По моему опыту тестирования - пиздюлей всегда первыми получают тестировщики)

раскрыть ветку (6)
3
Автор поста оценил этот комментарий

скажи где работаешь я уже готов резюме отправить

раскрыть ветку (5)
11
Автор поста оценил этот комментарий

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

раскрыть ветку (4)
14
Автор поста оценил этот комментарий

Ну так вы ж проверяете все ли работает

раскрыть ветку (1)
3
Автор поста оценил этот комментарий
Это не так работает немного... Задача и зона ответственности тостера - обозначить насколько готова версия к релизу (качественно или количественно) и дать свою рекомендацию по поставке. Вся ответственность за релиз на продакте. Ну а если очевидный баг проебал, то тут да, пиздов получать нужно
3
Автор поста оценил этот комментарий

Нефиг пассить все подряд потому что!

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

А разрабам нефиг говнокодить))

55
DELETED
Автор поста оценил этот комментарий

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


это работа BA/продакта и дизайнера

начинаешь делать работу бека на фронте, потому что проще сделать самому чем дождаться


Плохо работают архитектор и ПМ/скрамастер

ебанутый набор колбеков.


опять плохо работает архитектор, ну и тот кто тебя на работу взял. Какие к черту колбеки в 2020. Не слышал никогда про rxjs? Или хотя бы async/await

На беке все четко, вот на нем я как раз четко знаю что прийдет, что сделать если пришло не то что надо.
Лично я не имею большого опыта ни в том ни в том
Это многое объясняет

но фронт всегда получает пиздюлей первый


Вы чё без QA работаете?

раскрыть ветку (17)
66
Автор поста оценил этот комментарий

Ты че с гугла пришёл? Ухади абратна.

Если глянуть на вакансии, то в среднем каждый фронт должен (по мнению работодателя) знать бэк, дизайн, работать с БД, все это тестировать, естественно. "Или нам ещё тестировщика нанимать и зп ему платить? Да ты ахуел". Ну и время от времени, само собой надо и локалочку бы поднять, маршрутизаторы настроить и проводку в розетке поменять

раскрыть ветку (9)
10
Автор поста оценил этот комментарий
Это справедливо скорее для маленьких компаний. В энтерпрайзе такого нет, по крайней мере я занимаюсь только своим фронтом и никто больше ничего не просит
15
Автор поста оценил этот комментарий
Аналогично как и каждый бек должен уметь в ангуляр/реакт, кубер, CI/CD и т.д.
раскрыть ветку (1)
9
Автор поста оценил этот комментарий
Хз где вы такие вакансии нашли, есть фронт, есть бэк, есть фулстек. Если чистому фронтендщику шлют вакансии со знанием бэка, 90% либо рекрутер ебобо, либо в профиле что-то левое указано
4
Автор поста оценил этот комментарий
Сейчас конкуренция большая. То что лет 10-15 назад делал сениор теперь делает джуниор
1
Автор поста оценил этот комментарий
Про знания БД, как по мне, это перебор, но иметь базовое представление о том что и как принимает/отправляет другая сторона все же стоит, и тебе проще будет договориться с бекендщиком и в целом работа пойдет более гладко, опять же, базовое, требования сапортить бек уже глупы
ещё комментарии
Автор поста оценил этот комментарий

И чайник почини тыжпограмист

3
Автор поста оценил этот комментарий
Дай угадаю. Продуктовая компания? Свои сервисы на своих платформах? ЗП от 150 и комнаты релакса с настоящим газоном вместо ламината?
Web галеры. Слышал про такие? Чтобы попасть на такую работу которую я описал выше, нужно погрести тут пару лет. Такие дела.
раскрыть ветку (4)
4
DELETED
Автор поста оценил этот комментарий
Не угадал, аутстафф галера. Ни газонов, ни прочих изысков. Даже массажист не приходит, хотя на прошлых галерах поменьше был. Для релакса настольный теннис/футбол, турники и старая плойка которую командой купили.
За более чем 7 лет опыта повидал чуток галер разных
2
Автор поста оценил этот комментарий
Хз, не пришлось нигде «пару лет» грести, понадобилось только выучить нормально язык и нужные технологии. Поработал год в маленькой веб-студии у которой проекты были с постоянными заказчиками и в одной сфере. Сейчас в энтерпрайзе пилю фронт и когда задач мало копаюсь в бэкенде
раскрыть ветку (2)
Автор поста оценил этот комментарий

А можно примерный список технологий, который нужен для Джуна?

раскрыть ветку (1)
2
Автор поста оценил этот комментарий
Джун должен знать всю базу - HTML, CSS, JavaScript, асинхронность, чуток алгоритмов, работу протоколов передачи данных и тд
2
Автор поста оценил этот комментарий
Далеко не на каждом проекте есть четкое разделение на роли описанные тобой, иногда это просто команда из 3-4 дева и клиент с +- пониманием чего он хочет, а дальше ебитесь как хотите
раскрыть ветку (1)
1
DELETED
Автор поста оценил этот комментарий
В команде из 3-4 человек все проблем с коммуникацией описанных выше быть не должно, а роли описанные выше даже не нужны ибо у каждого будет достаточно полномочий(в таких командах вертикали нет).
Берете книжечку по скраму, читаете, клиента назначаете продактовнером, из девов выбираете скрамастера.
И вот уже появляется какой-то порядок, клиент лучше видит прогресс, меньше меняет свои хотелки, а у разрабов не горит ведь это часть рабочего процесса и посреди итерации поменять требования нельзя
13
Автор поста оценил этот комментарий
На беке все четко, вот на нем я как раз четко знаю что прийдет, что сделать если пришло не то что надо.
Знаем плавали) Чуть что не так - 500 или 400.

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

Понятно, что бывают разработчики хорошие и разные, но подход "у меня все четко, а с юзкейсами пусть фронт разбирается" - зачастую пагубен.
раскрыть ветку (33)
12
DELETED
Автор поста оценил этот комментарий
Этим не только бекендеры грешат, а все кодеры. Собственно в этом и разница между кодером и разработчиком.
Один просто делает от А до Б, другой думает о бизнесе, о юзере, о хотя бы ближайшем будущем системы
раскрыть ветку (8)
12
Автор поста оценил этот комментарий

Чего ж сам бизнесмен о бизнесе не думает, выдавая тз.. да и в принципе разрабатывая бп. Какой же идеальный мир бы был, если бы все всё делали правильно))

раскрыть ветку (7)
11
DELETED
Автор поста оценил этот комментарий
А чего он сам себе программный продукт не разрабатывает и тратит деньги не в ресторане, а на какого-то Васю чтобы тот в комплюхтер тыкал🙃
раскрыть ветку (3)
3
Автор поста оценил этот комментарий

Потому, что не умеет? Но ведь он же бизнесмен и в бизнес-то должен уметь.

раскрыть ветку (2)
8
DELETED
Автор поста оценил этот комментарий
В бизнес то он умеет, а в ПО нет. Его задача сказать хотелки и оплатить их.
А дальше он может придти к кодеру Васе, который сделает согласно кривому ТЗ какую-то кривую неподдерживаемую какулю потому что он не хочет думать, ведь это не его работа.
Или он пойдет к разрабу Пете, который подумает, объяснит бизнесу где в ТЗ он не прав и разработает нормальную систему которой будет удобно пользоваться юзеру, которая решит проблемы бизнеса и которую будет возможно поддерживать
Как думаешь после посещения какого из ребят у безнеса в итоге будет больше денег? А как следствие какой из ребят будет иметь больший доход?🙃
раскрыть ветку (1)
2
Автор поста оценил этот комментарий

Да при чём тут кривой код и удобство, я же не про это.

А, всё, перечитал коммент выше и понял, что сам не о том немного подумал, бывает))) Я думал там "бизнес сценарии" какие-то имеются в виду. Типа доход учли, а простой и расход нет. Признаю, не прав был. Теперь понял про что речь шла))

Автор поста оценил этот комментарий
Могу ответить как аналитик: потому что чтобы подумать об этом, нужно в этом шарить. А еще иметь опыт проектирования для используемого класса систем. :с
раскрыть ветку (2)
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий
Ааа, ок)
2
Автор поста оценил этот комментарий

Интересное мнение. Работал по обе стороны барикад. На всех проектах старались сделать фронтенд максимально тупым. ВСЯ бизнес логика должна проходить проверку на бекенде. С фронта хера лысого можно прислать и это вовсе не значит, что сервер должен это кушать. К слову, обе стороны имеют свои сложности. Но в итоге выбрал чистый бекенд - кроссбраузерность и верстка убивали меня.

2
DELETED
Автор поста оценил этот комментарий

есть бек разработчики которые оставляют валидацию данных на фронт?

раскрыть ветку (21)
11
DELETED
Автор поста оценил этот комментарий

Есть, но им быстро дают пизды на ревью.

2
Автор поста оценил этот комментарий

Есть разработчики, вообще разрабатывающие REST-API чисто как прокладку между фронтом и БД) Но речь сейчас не об этом.

Есть, например, таблица с фильтрацией. И там есть фильтр по дате. Пользователь выбирает: 01.02.2020 - 01.01.2020. С бэка прилетает 500-ка.

В целом это, конечно, бессмысленный кейс. Но ведь валидный. И ожидаемый результат в этом случае - пустая таблица, а не "внутренняя ошибка".

раскрыть ветку (19)
13
DELETED
Автор поста оценил этот комментарий
Ожидаемый результат 400 потому что невалидные данные от клиента
Иллюстрация к комментарию
раскрыть ветку (15)
4
Автор поста оценил этот комментарий

Если на фронте нет валидации (а в фильтрах обычно это так и есть), то данный кейс допустим и данные считаются валидными.

Я придерживаюсь мнения, что HTTP-ошибки вообще не должны приходить при нормальном поведении приложения. Если приходит 5** - баг на сервере. 4** - баг на фронте. Если бэк хочет прислать бизнес-ошибку, пусть заворачивает в 200.

Исключение - только 401 ошибка.

раскрыть ветку (14)
1
Автор поста оценил этот комментарий

200 ошибки не идут в обрабитчик ошибок же. Приходится каждый 200 ответ проверять на правильность. Ломается типизация данных. Ибо каллбек ожидает список ордеров, а ты ему {message:"Idi nahui"} суёшь!

раскрыть ветку (6)
Автор поста оценил этот комментарий

Если ответ сервера подразумевает возможность бизнес-ошибки, то надо данные типизировать соответствующе. Что-то типа {orders: ['array'], error: 'message'} Если такое происходит часто - лучше не городить велосипедов и взять какой-то существующий протокол типа hateoas, json-rpc, что там еще есть?


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

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

раскрыть ветку (5)
Автор поста оценил этот комментарий

Ну это же не .net где ошибки очень дорого кидать. По-моему 200 означает happy path а 4хх, 5хх всё остальное, что нужно обрабатывать отдельно. Просто по моему опыту.


Отделение мух и котлет - элементарно. Читаем ошибку и если это aхios ошибка значит из неё берем status и message. Всё решается в одном месте в 5 строк.

раскрыть ветку (4)
1
Автор поста оценил этот комментарий

Давайте я приведу пример.

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

Для этого отправляем запрос на поиск клиента по указанным данным.

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

Ловим ошибки в catch, проверяем код ошибки - если это 404, предлагаем стать клиентом, если 400 - пишем, что найдено больше одного клиента. Все круто.

Но в один прекрасный момент пользователь вобьет в номер телефона не 11, а 12 цифр. Бэк пришлет 400-ю ошибку из-за неправильного формата, а мы что? Выведем что якобы клиентов больше одного.

Далее, допустим в какой-то момент бэк упал и адрес стал недоступен. Мы получаем 404 и что? Предлагаем стать клиентом.

Получается хрень. Чтобы такого избежать, придется писать что-то типа "client not found" в message и потом на фронте это проверять. Но вдруг какой-нибудь бэкендер, не зная об этом, решит уточнить ошибку и выводить "client not exist" или "can't found client with this data". Опять все сломается, и ведь не сразу даже докопаешься.

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

раскрыть ветку (3)
Автор поста оценил этот комментарий

хмм....

И да и нет. Наверное дело вкуса и удобства работы с IDE.


Ничто не мешает в респонсы ошибок писать данные для бизнес логики.

Типа 404

{message:"UserExists"} и если приходит 404 с любым месседжем, то мы знаем, что юзер не был найден, а не то, что ендпоинт упал.


И вообще 404 с неправильным форматом должно отсекатся еще до этого и обрабатываться как Network Error

раскрыть ветку (2)
DELETED
Автор поста оценил этот комментарий
Мне кажется в date range дата ОТ не может быть позже даты ДО
Но это вкусовщина, сойдёмся на том что бек валенок)
з.ы. 403, 404 двухсотками ты не отдашь
раскрыть ветку (6)
2
DELETED
Автор поста оценил этот комментарий

Это пока ты не хочешь поменять даты на месяц вперёд начиная ОТ, а у тебя не получается потому что ОТ не может быть больше ДО

раскрыть ветку (3)
DELETED
Автор поста оценил этот комментарий
Изменение парент поля должно сбрасывать состояние чацлда, это ж очевидно 🙃
раскрыть ветку (2)
DELETED
Автор поста оценил этот комментарий

Скажи это разработчикам Microsoft, как же они меня этим в PowerBI задолбали.

раскрыть ветку (1)
1
DELETED
Автор поста оценил этот комментарий
Ты их юзер ты и скажи🙃
1
DELETED
Автор поста оценил этот комментарий
С фронта могут хоть пуки вместо даты прийти, валидация на фронте только для удобства юзера годится
раскрыть ветку (1)
DELETED
Автор поста оценил этот комментарий
Именно так
1
Автор поста оценил этот комментарий

А с фига 500 ошибка может вообще прилететь?

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

раскрыть ветку (2)
2
Автор поста оценил этот комментарий

Ну, например он может взять разницу между датами... Короче, не знаю, это просто пример. Просто с некоторыми бэкендерами ситуации, когда в ответ на странные, но валидные сценарии прилетает 400 и 500, случаются весьма часто(

раскрыть ветку (1)
Автор поста оценил этот комментарий

В общем понятно, просто неудачный пример...

Автор поста оценил этот комментарий

с юзкейсами пусть разбирается PO

4
Автор поста оценил этот комментарий

лол, закрыл только что ебаную таску, где данные с бэка приходили в виде

[

{data: [...]}

{data: [...]}

....

]

а из них надо было просто сделать таблицу, по сути смержить объекты, и прочитал этот коммент)

2
DELETED
Автор поста оценил этот комментарий

Как тестировщик, радуюсь когда меньше багов и ничего не ломается. И очень часто пендали qa Тима получает)))

1
Автор поста оценил этот комментарий
Сейчас пытаюсь использовать фреймворк Devexpress под http://Asp.Net MVC. Горечь страдания заполонила моё сердце. Что-то где-то не дописал и у тебя не сформировался контрол, без объявления войны. Чувствую себя тупым.
раскрыть ветку (2)
1
Автор поста оценил этот комментарий
Иллюстрация к комментарию
1
Автор поста оценил этот комментарий

Ох уж этот БелАЗ грузоподъёмностью 1 кг. с кучей колбек панелей и хидденфилдов. А я к нему привык.

Автор поста оценил этот комментарий

мне 32) , хочу сменить сферу деятельности но не верю даже сам в себя.   , может с высоты опытного человека, направите или подскажете стоит ли в АЙТИ войти в таком возрасте не поздно ли?) , какую сферу на ваш взгляд лучше рассматривать? Понимаю в целом сферу, и какие языки куда нужны , (образование из области IT). Буду очень признателен вашим советам если возможно)Ps тоже хочу 150 и не работать в продажах- надоело просто)))

раскрыть ветку (7)
5
Автор поста оценил этот комментарий
Имхо, конечно можно, в любом возрасте можно обучиться любой профессии, конечно ты можешь не быть в ней лучшим, но обучиться можно. Сейчас все хотят в IT так как думают что будут грести деньги лопатой, но тут все зависит от званий и конторы. Начнём со знаний, все платные курсы это туфта, и лично я бы не тратил на них бабки, ты всю информацию можешь найти в интернете или на торренте, причём этот же курс. Единственное там хорошо, это что есть ментор который проверит твой код, но ради этого платить такие бабки очень сомнительно. А для сертификата ты можешь найти бесплатные курсы с сертификатом или на том же udemy купить курс за 10$, что не так уж и дорого и курс пройти и сертификат получить. Конторы бывают разные, и если ты думаешь что мало знаешь и тебе нужна контора похуже, чтобы набрать опыта, то это не так, если бы я сейчас захочу сменить работу, то я начну пытаться попасть в самую топовую, если не возьмут то в ту что чуть похуже и тд.. Так как, во-первых там будут лучшие условия, лучше зп, и больше возможностей, будет больше мотивации развиваться, одно дело учить чёт новое, когда тебе за это платят 100$ и другое когда 500$ к примеру. Но все это не будет иметь значения, если тебе это не интересно, поверь, обучение будет идти очень медленно, работа будет раздражать и в итоге ты просто бросишь это дело или же будешь плавать на базовом уровне. Вот как-то так, если подвести итог, то обучиться можно, но это должно быть интересно, нужно постоянно улучшать свои навыки и учить что-то новое так как от этого напрямую зависит твоё зп. Больше знаешь - больше зарплата.
раскрыть ветку (1)
Автор поста оценил этот комментарий

спасибо большое что нашли время для ответа, благодарЮ приму к сведению!)

3
Автор поста оценил этот комментарий

я в 31 решил уходить, и уже год работаю, главное понимать что легко не будет и тупым себя чуствовать первый год  это нормально, надо понимать свой уровень подготовки, потратить примерно год на обучение и реально себя оценивать, многие люди относятся как к обучению  в университете, типа вот корочка я курсы прослушал и т.д. Тут корочки никому не нужны, тебя посадят за комп и будут тонкие места спрашивать для твоего текущего уровня.
Советую начинать с js, чтобы зацепится в сфере а потом как устроишся учить нормальный язык паралельно типо C# или Java.

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

спасибо большое что нашли время для ответа, благодарЮ приму к сведению!)

2
Автор поста оценил этот комментарий
Переобучение в течение месяца на курсах ручных тестировщиков, далее напрашиваешься на стажировку, вакансий как правило много. Работаешь, изучаешь систему, учишь java или еще что то и далее смотри по возможностям.
1
Автор поста оценил этот комментарий
Можно, но учеба требует много времени, если есть семья/личная жизнь и прочие обязательства, которые требуют много времени, то будет сложнее, чем если начинать в 20 лет, в этом основная сложность. А по сфере это веб или интерпрайз(джава например), но в первое вкатиться легче(вакансий много, технологии попроще, джуны требуются всегда, даже без проф образования, делать проекты чтобы показать код проще). + понадобится много времени для получения опыта коммерческой разработки, чтобы зп достойную(стотыщ мильенов) получать. А при таком возрасте это тоже добавляет сложности(одно дело до 30 лет задрачиваться, другое после). А так вообще можно, причину, почему нет, написал выше.
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

спасибо большое что нашли время для ответа, благодарЮ приму к сведению!)

Автор поста оценил этот комментарий
И ещё одна ремарка, у людей будет в итоге не работать сайт, или приложение, прийдет заказчик скажет вот тут не работает сайт, и ебут всегда фронт, а потом может и до бека дойдёт, но фронт всегда получает пиздюлей первый

Я работал в одной компании на одном проекте, и сейчас в другой на другом проекте, но в обеих компаниях специфика сайта такая, что ебут в первую очередь бек)
Бек проверяет, не у них ли что-то отвалилось и затем уже может на фронт прилететь, если у бека всё ок

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку