Comments 69
Я помню времена когда под постом на хабре были обсуждения в 600+ комментов
И сейчас такие есть, но эти посты и новости частично или полностью про политику. Под текущим постом трудно повестку отработать.
Ну почему ? :)
Почему приходится писать на веб-технологиях там где им не место? А потому что из аппстора и плейстора поперли а в русторе обновления хуже автоматизированы. А кто виноват что поперли? Все же знают кто на самом деле виноват? (вот только находятся отдельные несознательные элементы кто думает иначе)
Создается впечатление, что ты такой рыцарь на белом коне, готовый делать все правильно с покрытием тестами и пр. красотой из учебников. Вот только до тебя эту дичь сделали точно такие же, если не более профессиональные ребята. Да что говорить, собственный код через год уже видится чушью и руки чешутся переписать.
Да и у бэкендеров точно такие же проблемы.
Мне кажется что столько боли и радости может принести только программирование...
И линукс)
Не только, разработка устройств может ещё пуще голову сломать, причём там даже загуглить может быть банально негде, всё упрётся в понимание электроники и законов физики. Причём бывает так, что вот вроде всё хорошо ты понимаешь и оно ДОЛЖНО работать... но не работает. И все более опытные, с кем ты пообщался, тоже говорят, что должно. А оно нет... И так может продолжаться не один месяц. А дедлайн тоже существует, как и везде, если это не какая-нибудь гос.контора.
не потому, что тебе это нравится каждый день. Не потому, что тебе платят бешеные деньги. Ты здесь, потому что —
не умеешь ничего другого
Если заменить дизайнера на аналитика, UI на структуру БД то получиться ровно тоже самое только на бекэнде.
Потратил день собирая проект? Напиши инструкцию. Пока ты еще в контексте. Твой преемник будет эффективнее. 5 минут на инструкцию сейчас экономят день потом.
Дизайнеры творят что-то странное? Проконсультируй их. Покажи им, как система на самом деле работает. Может им контекста не хватает. А может ты и сам чего-то не знаешь, и там есть простая логика, но ты ее за своими пикселями упустил. Поделись ей с соседом. Неси свет знаний во все стороны. С просветленными коллегами всегда спокойнее работать.
Если работу можно сделать на порядок быстрее и проще, приняв техническое решение - донеси его до менеджера. Одним выстрелом ты можешь сэкономить деньги бизнесу, а своих коллег избавишь от головной боли.
Старый код попахивает? Изолируй его. В новых модулях не наступай на те же самые грабли.
Разобрался с багом с долгой историей? Задокументируй суть бага и решения. Вдруг опять всплывет.
Недооценил задачу? Уведоми лида. Сразу. Постфактум запишите, что там за контекст, чтобы на будущее знать и не ошибаться дважды в одном месте.
Менеджер меняет приоритеты задач? Это его работа. Он несет ответственность за это. Если видишь технически невозможное - уведоми его. Это ты здесь - технический специалист, ты вносишь технический контекст в его восприятие проекта, а не наоборот. Впихивая невпихуемое ты повышаешь риски возгорания и делаешь подлянку всем вокруг.
Если ты не сделаешь мир лучше - никто не сделает. Нытье не решает проблем.
При условии, если команда видит в тебе человека - то ... может быть.... эти совету сработают
Плюсую - своим падаванам тоже всегда говорю - ты сам не сделаешь - считай никто не сделает. Только беря на себя ответственность за проект, ты начинаешь по-настоящему работать над проектом. И если каждый в команде взялся и делает, тогда и проект движется, и люди растут.
Короче, нужно освободить лидов, манагеров, дизайнеров от части их работы. Взять на себя управление проектом и обломаться с повышением з/п потому, что тебя, как потом оказывается, никто не просил делать. Держите плохих специалистов, которых должен скомпенсировать разраб? Ну тогда выдержите еще одного, не сломаетесь. Разраб тоже не хочет за всех работать за оклад разраба. Главное не ныть - нытье не решает проблем. Так и передайте заказчику. Работа менеджера в управлении, то есть в осуществлении всех его функций. Всегда прошу пустить меня на собесы с манагерами и лидами пообщаться за управление. А то меня наизнанку выворачивают вопросами из глубин документации и литкода на собесах. У них же беседа типа скажи что-нибудь на манагерском. "Мы - команда! Василий, очень нуна успеть. Обязательно повысим з/п и дадим премию! <мем с лицом обманщика> Ты же профессионал! Кто, если не ты?" Если менеджер не может управлять, то разработчик в его команде может не знать язык программирования. Ведь какая в таком случае разница - сколько неквалифицированных дилетантов на проекте?
Позвольте спросить, а как вы смогли посылы "записывай, не повторяй одну ошибку дважды" и "дай коллегам контекст, чтобы они эффективно выполняли свою часть работы" смогли перевернуть в то, что нужно делать работу людей с другими специальностями и еще привязали к этому квалификацию? Это абсолютно перпендикулярные друг другу вещи.
Да боже, ну зачем так преувеличивать то! Ковыряешься в коде, видишь, что сроки нереальные - скажи сразу, объясни почему. Потрать минуту. Как это у вас в голове превращается в "нужно освободить лидов, манагеров, дизайнеров от части их работы "???
Про изолирование кода - в далеком 2015 мне достался проект на ExtJS, который писало 35 разных человек 7 лет. И там на фронте было сразу три версии фреймворка в формате SPA, при этом старая версия была виртуализированна в эдаком сандбоксе чтобы не влиять на код в других местах. Но влияла, потому что протекали стили и когда подгружалась старая версия - в микро-моментах это становилось заметно. А подгружалаось там всё на лету модульно потому что были очень толстые бандлы с логикой и стартовым кодом, не на каждой странице тебе это было надо, к тому же могло не быть прав. И если всё грузить, то бут-код после загрузки время старта занимал. Грузилось модулями из рееста модулей, некоторые были запакованы чтобы логика легаси не протекала. При этом часть кода была статичной, а часть генерилась на конфигах что приходили с бекенда - приходит здоровенный JSON и по нему ты рендеришь интерфейс, подгружаешь скрипты, генерируешь исполняемый код. Но такое только для части кода. При этом было хорошо заметно в какие из годов среди 7 лет в команде был архитектор. А ещё там было всё на эвент-системе и ты слал сигнал, который ретранслировался и роутился по пути и на этот сигнал могло быть много что подписано и ты мог не знать что, потому менять было опасно, а трейсинг сигналов был интересным квестом. Ну и конечно взаимодействия между виртуализированной старой версией фреймворка и новой. Сверху ещё глобальная либа с именем js.js, благодаря которой я узнал что у объектов бывают методы с именем в виде пустой строки. Ну и сверху система локализации на разные языки, которая пронизывала весь интерфейс. Про то как там билдилось это всё с помощью Java и о слоях логики… разнообразно в общем.
Вот ЭТО было легаси. С большой буквой ЛЕГАСИ. Которое я полтора года в одного поддерживал. И получил грейд сеньёра. А про то как пишут что аж целый день на настройку было потрачено… эх, не видел автор большого энтерпрайза.
Статья бэкендера - "как я проходил собеседование в 8 этапов, с жонглированием на моноколесе".
Статья фронтендера - "меня взяли на работу, а я ничего не могу, и никто не помогает".
p.s.
Не в обиду фронтендерам, знаю там есть профессионалы.
По первому пункту рекомендую использовать докер и docker-compose.yml для рабочего окружения хранить в репе. Забудете про ошибки совместимости node.js раз и навсегда.
Опять же, когда начинаешь работать с каким-то старым проектом, проще узнать какая нужна нода и поднять её в докере. Если не у кого узнать, смотришь дату изменений в проекте, когда основная работа велась и ставишь ту ноду, которая была LTS в том году, когда это делалось.
Буквально неделю назад в новом проекте битый час промудохался с докером. Спросил в чате - оказывается он нафиг не нужен)) Через npm всё поднимается (с красной консолью, но без ошибок).
Докер не нужен, пока ты работаешь с одним-двумя проектами. Когда их у тебя десятки и надо жонглировать разными версиями, а ещё бэкенд, эластик какой-нибудь, мэйл-кэтчер. Ставить всё это в систему очень увлекательно, особенно, если твоя система - это винда или мак.
Обычно фронтендеры не разворачивают бекенд у себя, а используют удалённо развёрнутый.
Обычно
Не обычно, а в тех случаях, когда фронтенд отделён от бэкенда. Большинство сайтов всё ещё работает по старой схеме, где всё вместе.
Судя по тексту автора, у них используются webpack, react и redux. Я скорее склоняюсь к тому, что в этом случае фронтенд отделён от бэка.
Вы про меня? Это был nginx, webpack и vue. Там правда в зависимостях ещё были vite и pinia, но они не использовались - наверное vue cli по дефолту собирался))
Ну и да, в подавляющем большинстве случаев (я фрилансю - поэтому выборка у меня приличная) бэк действительно удалённо работает. Но не всегда! И вот в этом засада - пока самостоятельно расковыряешь "что тут и как?"... Зачем вот во фронтовую репу тогда класть утилиты для бэкенда, если он юзается отдельно?..
А как быть, если моя самооценка зависит напрямую от количества одновременно применяемых технологий на проекте?
Я мимокрокодил из java бекенда. И там у нас тоже есть разные зависимости. Но самое страшное что я делал - просто разные пути к разным Java указывал при билде проекта. И этого хватало для всех проектов. Обычно даже хватало билдится на последней версии jvm, но указывать версию старше - типа jvm 17, но говорю чтобы сбилдил под 11. И это работает.
Но когда я пробовал кодить typescript с npm, у меня так просто это не вышло - оказываемся в некоторых либах прописаны shell script которые вызываются при их установке. Я хз - стандартная это практика или нет, но в мире java это даже теоретически нельзя сделать - чтобы Gradle или Maven запустил какой-то кастомный код при скачивание jar файла. Собственно эти shell script у меня под виндой в cmd и не заработали.
Не могли бы вы подробнее рассказать, в чём проблемы иметь разные версии npm и всего остального? И почему вообще эти проблемы в возникли? Мне интересно, так как на момент изобретения npm уже существовали примеры хороших систем сборки, типа maven. Вот и Rust, который сделали позже, тоже хорошо сделан, нам мой не опытный взгляд - модули, поддержка разных версий компилятора. Всё из коробки.
Не могли бы вы подробнее рассказать, в чём проблемы иметь разные версии npm и всего остального? И почему вообще эти проблемы в возникли?
Огромный зоопарк пакетов. Плюс очень динамично развиваемый es/ts. Какая-нибудь либа требует пакет, который уже depacated, а какая-то ссылается на то, чего твоя версия npm ещё не понимает.
Наиболее часто встречаемая мной ошибка при сборке - это старые проекты с sass/scss, которые требуют node-sass, который deprecated... Альтернативные решения есть и решается эта проблема довольно просто. Но в первый раз, по незнанке, можно и затупить))
И да, такого достаточно. Я никогда не знаю заранее - соберётся ли у меня проект локально. Это всегда лотерея)) Я первым делом, ещё до разговора о задачах, всегда пробую собрать проект. Если он билдится с ошибками - надо смотреть, а стоит ли вообще овчинка выделки (стоит ли тратить время на их фикс)... И да, приходилось и даунгрейдиться, и апгрейдиться...
С другой стороны, у меня сейчас на винде в окружении прописаны три версии питона (2.7, 3.10, 3.11) - хотя я вообще ни разу не бекендер...
Вот мне недавно надо было перебилдить проект 2018 года, там как раз была node-sass, да ещё и Gulp 3. Поднял в докере 14-ю ноду и всё сразу завелось.
Наиболее часто встречаемая мной ошибка при сборке - это старые проекты с sass/scss, которые требуют node-sass, который deprecated
О-о-о-о-ох, сейчас как вспомню эти вьетнамские флешбеки с компиляцией каких-то питоновских сорцов через какие-то библиотеки C++ с такими лютыми ошибками компиляции... причём сразу после установки node-sass, который даже не объявлен у тебя в package.json... Аж остатки волос на голове вздыбаются. Четыре года с этой ошибкой то в одном проекте, то в другом сталкивался, lock-файлы не помогали.
Так в итоге и не понял, кто был виноват: корпоративный VPN со своим сертификатом, даунскость какого-то SCSS-пакета, общая дичь в архитектуре node-sass и/или его несовместимость с Виндой?
В общем, проблему решил временной сменой проектов с Angular на Vue, а потом перескок на обновленный Angular через пару лет.
У меня как то был случай когда мне надо было отучить одну программу от подписки.
Программа на 90+% на TypeScript хотя выглядит клиентским приложением, под AGPL3(а вот так, с комментами даже), предложение про подписку автор сам предложил в ответ на вопрос как ему из России то платить.
Ушло примерно 2 вечера, ах да TypeScript я не знаю (в работе более другие языки использую)
Человек не может одну кнопку покрасить неделю (предполагаю, что за 300кк в наносек), а кто-то пишет, что порог входа увеличивается...
Приходи в игрострой, мы тебе ещё рендера и математики отсыпем.
Главная боль фронтенда, это JavaScript... Надеюсь TypeScript однажды заработает из коробки, либо webAssembly научится работать с dom.
А в чем проблема? Сейчас все фреймворки умеют в TS. Другое дело, что его не хотят молодые. Это же так сложно!)
TS превратился в отдельный объект фапа. Тип извлеченный из типа объединённый с другим типом, извлеченным из какого-то объекта со своим интерфейсом. Зачем это? Чтобы можно было поменять в одном месте. Ага, если я смогу в итоге найти это место. Новый вид современного искусства - ts как самоцель. Берем четыре закона логики и идем к такому аффтору за объяснениями. Десяток вопросов и человек уже пишет не как графоман от кодинга.
О, ts решает все проблемы, да?
JavaScript прекрасный язык) Просто его не все понимают, особенно с колокольни джавы или шарпа)
TS решает только часть проблем. Если тащить его всюду оголтело, использовать всякую дичь типа шаблонов и т.п. - это ничего кроме новых проблем не создаст.
Заключение: Почему мы всё ещё здесь?
Потому что когда ты начинаешь новый [pet] проект, берешь любимый фреймворк/библиотеки и делаешь офигительную штуку, это приносит огромное удовольствие
Первая задача для новичка в проекте это - поднять окружение, поправить документацию как поднять окружение.
Самый главный минус, и в целом обобщающий - нужно работать
А потом придет какой-нибудь озлобленный пафосный гейткипер и скажет, что ты ненастоящий, потому что математику не знаешь)
Хорошая статья, спасибо. Отработала первую неделю в компании, всё примерно так и есть. У нас ещё безумное количество созвонов. В среднем, 2ч в день. Не понимаю, зачем джунам сидеть на созвонах с заказчиком😪😪
Спасибо за статью!
Улыбнулся)
Новичок на проекте приходит в чат разработчиков и спрашивает - у меня тут основной тестовый стенд не работает нормально, а мне фичу писать - заявку уже создали? Как быть?
Ему отвечают в том числе что надо радоваться тому что этот стенд хоть пускает и вообще у тебя что - набора моков чтобы пройти флоу от старта до твоей фичи нет? Может ты и про песочницу не знаешь?
Работа с legacy‑кодом — это как встреча с духом прошлого
Легаси не прошлого, легаси может быть родом из вчера. Когда возникает совокупность таких факторов, как:
сделать нужно быстро-быстро
непонятно что делать и что мы хотим получить в итоге
всем на всё пофиг
поэтому напишу по-быстрому и пойду заниматься своими делами
то тогда и возникает легаси. Он не привязан к прошлому, это вполне нормальное явление, когда нет смысла думать о высоких материях. Да и не весь код нужно держать в соответствии со стандартами и кучей абстракций, иногда просто нужно сделать так, что бы работало и забыть об этом участке кода на следующие полгода.
Легаси - это дословно "наследие", то есть старый код. А то привыкли всё, что сразу непонятно, называть легаси
Где в слове "наследие" хоть какая-то отсылка к возрасту? Этот лишь означает, что вам (вам лично или команде, в зависимости от контекста) этот код незнаком, но поддержка теперь на вас. А написан он мог быть хоть сегодня до обеда.
Так это чё ещё, не только получать зарплату надо, но ещё и работать? Ну новости!..
По некоторым кулстори даже промелькнуло подозрение, что мы в одной конторе работали =)
Есть конечно отдельные вопросы к этому мировоззрению.
Ты открываешь файл и понимаешь, что переделывать нужно не одну кнопку, а абсолютно все экраны. Эта кнопка часть корпоративной UI библиотеки. Тебе надо менять StoryBook.
Так а я не понял в чём трагедия, если "эта кнопка" действительно "часть корпоративной UI библиотеки", то она просто меняется в самой библиотеке, а сторибук обновляется одной командой и деплоится.
Вместо стандартных 20 пикселей отступа теперь стало 15, а то и 25. И вот ты начинаешь искать, где этот отступ по всему коду, пытаясь не сломать остальные части интерфейса.
Почти во всех проектах, где довелось работать последние несколько лет, гэпы заданы переменными и всё всегда строго по сетке, оч странно что кто-то ещё не знает про переменные в SASS и LESS. Или дизайнер не знает про сетку? Тогда этому дизайнеру место во фрилансе в лучшем случае. Если же дизайнер где-то ошибся в макете и сделал 21 вместо 20, ты знаешь, что подразумевается стандартный отступ в 20px. Если же дизайнер ВДРУГ решил, что теперь у него в макетах сетка какая-то сетка будет 3/5/8, а какая-то старая это значит дизайнер олень и его надо учить, это не боль фронтендера. Ну либо, если он хочет всё перевести на другую сетку, договариваться как это будет происходить в несколько этапов, это опять же не боль, а необходимость коммуникации.
const data = someData || []; // на всякий случай, потому что иногда someData == undefined
Ну это нормальное выставление граничных условий, так-то. Не всегда есть возможность вообще как-либо менять код из которого someData может прийти ундефом. Я даже сам такое делал и мне не стыдно, ккк.
Так бывает, когда нужно починить баг, а причина по которой someData бывает пустой - либо тоже где-то в дебрях легаси, либо просто вытекает из всей архитектуры, которую писал не ты и поменять ты не можешь по объективным причинам. Тебе надо добавить что-то новое в этот же чудесный код и таких мест может быть с пяток, а ты сидишь фиксишь всё это говно в поту, потому что продакт уже сам на нервном срыве. Конечно в итоге заткнёшь таким вот, потому что не всегда можно остальное исправить, но то что у клиента оно крэшиться не будет это уже плюс так или иначе.
И всё, что ты можешь — это писать тесты самостоятельно, а это требует времени.
Ммм... ну как бы, писать тесты самостоятельно это не то чтобы плохо. Это собсна главная проблема всей индустрии — писать хороший код это не то же самое, что дебилоидные задачки на собесах решать. Там думать надо. А думать это надо время. А бизнесу нужно быстро. Чем быстрее все сраные манагеры поймут этот баланс, тем быстрее у всех нас наступит взаимопонимание и гармония.
Но заказчик видит только конечный результат, а ты погружаешься в дебри, где нужно не только добавить фичу, но и рефакторить десятки файлов.
Лол... Я помню ещё в начале своей карьеры, мне дали примерно такое же задание. Но я был ещё не опытным разработчиком и разобраться не сумел. Временами тупо залипал в код и пытался понять как он работает, чуть не поехал кукухой и в итоге поправил какой-то минимум, хотя надо было ваще на всё это говно плюнуть и переделать. А в итоге меня и вовсе уволили.
Иногда разработка фичи по расписанию — это вообще отдельная трагедия.
Ну, опять же, это классическая проблема всей индустрии всё-таки. Тут два момента: во-первых, сама по себе разработка любых сложных систем подразумевает отличную квалификацию всех участников процесса, какой-то минимальный профессионализм и соблюдение всех обязательств. А когда тебе сначала говорят одно, а потом требуют другое, ничего удивительного, что ты потом оказываешься виноват. Эту проблему либо не могут решить и спокойно работают, подбирая людей, которые всё делают срок и закладывая для них запас по времени, либо решают с помощью скрама, про который можно целую статью отдельную написать почему он говно (хотя местная аудитория это и сама уже начала понимать, но сделать ничо не может).
...
Вообще, по существу с большей частью боли я даже согласен, особенно много проблем с дизайнерами, которые даже близко не понимают как интерфейс работает, но при этом зачастую фронтам никак не дают им объяснять почему то они делают дичь.
О чем плачет Frontend-developer