Frontend + Веб-разработка

Периодичность:

1. Постоянная работа

2. Работа периодами (например, в рабочее время)

3. Разовая задача

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

При этих вводных все эти "чистые коды" работают и иногда даже хорошо...

!!! НО ТОЛЬКО В ЭТИХ УСЛОВИЯХ !!! Во всех остальных условиях следование этим принципам является идиотизмом. Правда этот идиотизм настолько врос в профессию, что многими он воспринимается как должное и естественное.

Пятница, писать лень, так что 3 примера:

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

Пример - бывает, что госорганы для своих каких-то целей запрашивают данные. Эти данные могут быть довольно сложно структурированы в БД т.е. руками и простым запросом не решить. Такие запросы НИКОГДА не повторяются. Написали код, выполнили и забыли. Все проектирования классов, тесты и прочая шняга - это время потраченное абсолютно впустую.

Крупный хайлоад. Вы должны писать код так, чтобы он работал быстро. В коде 100 if подряд? если это конкретно здесь работает быстрее - делайте именно так. Потому что от качества работы приложения напрямую зависит количество серверов на котором это всё будет работать. Серверов стоимость которых зачастую примерно равна квартире в каком-нибудь региональном центре.

Менеджеры "от бизнеса" эти нюансы очень остро чувствуют. И 90 % неприязни к ИТ как раз и заключается в том, что у них есть понимание, что эта задача должна стоить Х и делаться за У времени, а по факту бюджеты и сроки перекрываются в разы. И в качестве ответа на вопрос "какого хера?" им рассказывают про SOLID, Agile и далее по списку.

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

Просто потому что конкретно этот джун понимает что не все задачи нужно делать "по канону".

Разработчики часто не видят ситуацию "в целом". У бизнеса совершенно другие ценности. Бизнесу нужно прежде всего решать свои задачи. И решать их экономически целесообразно.

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

Могу проиллюстрировать простым примером. Есть "джуновская" булка хлеба, которая "здесь и сейчас" стоит 20 рублей. Купил-съел. Есть "мидловская" хлебопечка, которая делает хлеб получше, но дороже и 4 часа. А есть хлебзавод "сеньора", который хер знает когда построят, стоит дохера и может давать продукт только тоннами.

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

Если компания хочет разок выебнуться, то хлебопечка рулит.

Если нужно просто пожрать, то просто покупается булка хлеба.

А когда "канон должен быть везде", то получается, что в 90 % случаев вы голодный приходите за хлебом, а с вами начинают согласовывать проект хлебзавода...

И менеджер понимает, что ему продают булку хлеба по цене хлебзавода. И самая главная проблема для него в том, что ВСЕ ДОСТУПНЫЕ КАНДИДАТЫ продают именно это. За специалистов, которые могут сопоставлять задачи и способы их решения грамотные HR войны ведут. Потому что найти 50 сеньоров проще, чем 1 такого.

И самое главное - это не уникальная для ИТ ситуация. В других отраслях всё абсолютно то же самое.

Примечание: Мне нравится структура из angular и это не мешает использовать похожий стиль в компонентах. Используйте основную структуру из доков nuxt. Старайтесь не допускать больше трех уровней.

Разработчик сделал 40% проекта и метался от одного UI kit к другому, а я слушал и крутил барабан револьвера. Сделав одну страницу, меня попросили удалиться, попытка разбить вёрстку на компоненты и избавился от ненужных дубликатов html кода смутила разраба фирмы BODUNOV. И тут меня ждала новая не менее амбициозная компания, с 10-ти летним стажем на рынке.

На собеседование в "Стрекозлы в АйТи" я убедился у интервьюера, в отсутствие глуповатого маркетингового приёма, сверстать статический сайт и показать клиенту, сказав: 'Всё готово шеф, дело осталось за малым'. Люди серьёзные, работают с продукцией 1с и считаются в ней экспертами.

Ну хоть хорошо что excell не используется как база данных для бэка. А вместо word не используют markdown. Вот тупые, кто `markdown` придумал.

После ознакомительного диалога ПМ-а по работе со Шмитрикс, я не понял как они ведут разработку. На канбан доске вместо привычных столбцов было несколько столбиков связанных со временем:

// Без срока // Запланированные // Сделаю сегодня // Сделаю на недели //

Хмм... наверное для перевода на тест нужно делегировать тестировщику, а потом...

А нееее... кроме менеджера, разработчиков и дизайнера больше никого нету. То есть нет тестировщиков, контент-менеджеров, seo, devops и т.д.

Менеджер сказал (не дословно, почти): "Всех кого-ты перечислил сомнительные личности и результат их работы не ясен. У нас было много SEO специалистов, целых 3, ой, 2 человека. Ну руководство не поняло их трудов и уволило."

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

Three Days Later...

Прошло 3 дня, а я ничего не сделал. Нет, вина не в моём титуле Капитан Улитка, просто задач нет! Как объяснил менеджер, он болеет, неделя очень тяжелая, задачу выдать не могу. (На самом деле было ещё 2 менеджера которые могли его подменить, но заставлять работать больного сотрудника веселее)

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

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

Мне дали доступ по ssh и попросили поставить сайт с сертификатом на nginx. В принципе окей, но в вакансии про эти скилы не слова.

One Day Later...

Разговор с дизом и ПМ. Дизайн находится под слоём черновик, каждый макет не имеет статуса готового к разработке.

Примечание: кнопка фигмы Ready For Dev, некоторые дизайнеры делают свой компонент для статусов макета или используют цветовые зоны, т.к. макет может иметь много статусов (прототип / в процессе доработки / на утверждение / готов)

Даже без матёрого глаза можно приметить множество огрехов в дизайне. Отсутствие модалок, элементы не интерактивные, нет статусов элементов форм. В некоторых местах много воздуха, неравномерные отступы... В общем полный комплект ошибок ждуна. Дизайнер пытается скрыть смущение, намекая на сроки, мол времени на UX и полировку UI не было. Удивительный факт, разработчикам всегда представляют диза так: "А это наш UI/UX дизайнер". Вот только времени на UX исследования у него нет.

И теперь работа? Нет. Доступа к гитлабу нет, задач в шмитриксе нет.

На следущий день получил доступ к гитлабу, сразу начал создавать проект, хотя задачи не было, есть интуиция и особая минтайная связь. ПМ захлебывался соплями и издавал предсмертный хрип, получить инфу по проекту было нельзя.

А инфы по проекту не было / LOL / Редизайн предполагалось делать на основе нового диза и поглядывая на старый сайт. Только новый дизайн сильно отличался. Не было к примеру локализации (был выбор региона) и ПМ сказал твёрдо её НЕ БУДЕТ! Вот тут и была первая подстава.

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

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

Благо старый сайт не имел минификации и обфускации.

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

Ладно с дизайном всё ясно, ну мне нужно делать динамический сайт похожий по типу на интернет магазин, где взять бэкенд? Старый сайт был выполнен в php шаблонизаторе и имел мобильное приложение (отличается по функционалу от сайта), теперь предстояло сделать его на nuxt, а значит старое api не подходило.

Угадайте кто должен был придумать дизайн API? Бэкенд! Не угадали. Конечно же фронтенд (по факту vue SSR это уже fullstack)

Примечание: Бэкенд разработчики могут разработать API самостоятельно, а значит они могут приступить к работе сразу без верстки. После одобрения прототипа, уже можно предположить какие данные будут выводится. Прототип дазайна уже определяет базовое расположение блоков и медиаконтента

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

- А покажи что ты сделал.

Я отправляю ему ссылку на сайт.

- Скажи, то что сделал Рыжий, тебе как-то помогло?

- Как я говорил на собесе, всю эту вёрстку все равно нужно переделывать, к тому же там было много косяков, вёрстка была абсолютная не валидна по w3c. Я начал с начала.

- Ну ты же понимаешь я не могу показать это?

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

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

Менеджер посмотрел на меня как на шарлатана. Почему кадровик ведет переговоры по проекту с клиентом? А может он, вовсе и не кадровик?

Два месяца спустя или 44 раб дня

Бэкендер выходит из долгожданного отпуска...

4-5 остальных видимо были очень заняты. Я лично работал с двумя, но официально в штате их должно быть больше. Да и как-то на созвоне созвали толпу, которой объяснили как сделать 1 эндпойнт с получением данных из firebase. Результат: я поднял nuxt и сделал сам. Ну что сказать команда профессионалов, умеют убеждать.

Ах, да... Бэкенд выходит из отпуска и заходит в шмитрикс. Бэкендер плачет ПМ: "Там слишком много! Апи уже почти готово, там всё есть"

Конечно же там много чего не было, апи первой версии сделано не по REST, которому далеко до стандартов JSON:API.

Swagger-а нету, есть postman, апи которое написано ручками (тока шайтаны пишут доки в аннотациях и используют модуль автодокументации)

Примечание: Незнаю как в Yii, но в Symfony генерировать коллекции с готовыми Rest Api эндпоинтами милое дело. По идее мы один раз заморачиваемся пишем ядро, а далее используем от проекта к проекту. Документацию легко можно импортировать в postman. Если у вас будет фронтенд SPA/SSR в виде отдельного приложения, задумайтесь, а нужно ли его писать на php? Бэкенд на nodejs может сэкономить время. Низкой порог вхождения !== выгода. Nodejs может быть serverless, а php это танцы с бубном в плане деплоя. А там типизация от бэка почти готовая

Меня попросили переделать для бэка документ с api запросами и как вы думаете он приступил к правкам сразу? Конечно же нет. Рабочий день начинался в 9 часов, точнее так было у удалёнщиков, офисные планктоны почти всегда приезжали на работу после обеда. Оказывается часть сотрудников работают во вторую смену, а бэкендер на протяжения дня занимается бумажками от шефа, сам шеф со спокойной душой уезжал в командировку. По более сложному проекту с картами, мне приходилось ждать фидбека от шефа компании каждый вечер, а днём по указаниям из аудиосообщения я пилил приложение.

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

Хороший мальчик Бобби

Не курит, не пьёт. Деньги в копилку кладёт. Большая часть рынка разработки это ждуняшки ожидающие маны небесной. В один прекрасный день армию ждунов без тимлида, мидлов или сеньоров, только ждуны, только харкор. Банда маркетологов оказывается чаще всего во главе малого бизнеса (будем честны в крупных компаниях, тоже не всегда руководители инженеры), это приводит к печальным последствиям для IT рынка. Сначала нанимают партию разработчиков, через год или два, шеф проходит специальные курсы по бизнесу и открывает новые слова: "B2B" и "B2C". Он смотрит в собственное отражение и видит гениального человека, способного открыть свой телеграм канал и продовать свои собственные курсы. Увольняем 90% разрабов, получаем чистый профит с курсов. \ STONKS /

Судная ночь

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

-- Эту кнопку убрать! Батюшки, я ведь всё ни так! Клиент? Какой клиент! Я так вижу! Сделать по моему! Клиент потом посмотрит и скажет. В смысле, конечно макет утвержден! Видишь дизайнер тока что стрелочки в дизайне дорисовал, а у тебя их нет! А ну быстро отсеките голову этому халопу! Стража! Стража!

Титры

Нет повести печальней, чем история о Shaltier и потерянном времени. Почему никто не плачет? Не забываем купить мои курсы "Как открыть IT стартап для ...". Продолжение пишем в комменты.

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

Привет, пикабу! Решил написать серию небольших постов про Frontend в которых постараюсь рассказать о свойствах CSS, которые мало кто знает или не знает всех возможностей.

Итак, сегодня рассмотрим такое свойство как content. Уверен многие frontend-разработчики используют его каждый день для псевдоэлементов. Ну как-то так:

Мало кто знает, что это свойство может принимать не только текст, но и attr(), counter(), url() и градиенты. А еще это свойство можно использовать и для обычных элементов. То есть мы можем поместить картинку внутрь псевдоэлемента или даже превратить <div /> в <img /> всего одной строчкой в CSS:

К сожалению градиенты не поддерживаются в Safari, поэтому не советую их использовать. А вот url() поддерживается всеми браузерами (даже IE8 !!!).

Еще можно указывать в content сразу несколько значений, но это работает только для псевдоэлементов:

На этом пока всё. Если зайдет, то буду писать еще. И не только про CSS.