tgindex

Кодовая база

описание

База во фронтенд разработке. Написать в личку: https://t.me/devmargooo

← к каналу@the_codebase
1 332
подписчиков
Охват к подписчикам
99,6%
ERR
Реакции к просмотрам
1,96%
944 на 34 постов
Пересылки к просмотрам
0,91%
436
Постов в день
0,3
всего 34

Где отзываются чаще

доля реакций к просмотрам
  • 10:17Почему вы не можете найти работу даже с сильным резюме На рынок труда в наше время не жалуется только ленивый. Работа ищется месяцами, а отказы приходят даже по вакансиям, по которым метч 146%. Виноваты во всем, разумеется, эйчары. Это они, а не нанимающие лиды, придумали, что на проект нужен сеньор, хотя там и джун левой пяткой справится. Они выставили дурацкие фильтры 3, а то и 5 лет. Как будто этого мало, они еще и стараются найти ребят с опытом в серьезных крупных проектах и максимальным метчем по стеку. Компании абсолютно не хотят выполнять свою социальную функцию — обеспечивать работой людей без опыта — и эйчары, чувствуя свою безнаказанность, режут резюме новичков автофильтрами. Сами понимаете, с такими эйчарами и автофильтрами единственный выход — накрутка опыта. Про накрутку опыта заговорили примерно года 4 назад, когда рынок был переполнен джунами, а опытных ребят не хватало. Тогда в интернете появились советы “просто накрутить годик”. Это работало: резюме сразу переходило из категории “новичков” в категорию “опытных”, а там конкуренции не было. Со временем годик превратился в 4-5 лет накрученного опыта, а ноунейм компании сменились накрученным опытом в бигтехе. Как так вышло? Совершим мысленное путешествие на 5 лет назад. Рынок был заполнен тьмой джунов, сменивших профессию в ковидные времена, а вот миддлов и тем более сеньоров сильно не хватало. Предположим, у нас есть три таких джуна: Вася, Петя, и, допустим, Иннокентий. Все трое закончили курсы и теперь пытаются найти работу, но с пустым резюме их шансы почти нулевые. Пока Вася и Петя жалуются на вселенскую несправедливость, Иннокентий запилил небольшой пет проект, а потом залетел на бесплатное трехмесячное обучение в бигтехе, и все это он гордо указал в своем резюме. Бинго, Иннокентий получает работу. Для тех, кто не верит — я лично помогала ребятам получать свою первую работу именно таким образом и это работало. А что, если дело происходит не в 2021г, а 2023г? Иннокентий пишет в резюме свой пет проект и обучение в бигтехе, а Вася с Петей, послушав айти блоггеров, решают просто накрутить годик коммерческого опыта. Год полноценного опыта в компании, конечно, смотрится солиднее бесплатных курсов Иннокентия, поэтому работу получают Вася и Петя, а Иннокентий остается не у дел. Несмотря на то, что фактического опыта у него больше, чем у компаньонов. А что в наши времена? Оставим часть условий эксперимента теми же. Иннокентий честно указывает в резюме свой пет проект и обучение в бигтехе. Возможно, он еще поднапрягся и попал на стажировку, которую указал в том же резюме. Вася крутит опыт, только не годик, а четыре по актуальной моде, а Петя решает не мелочится, накрутить шесть лет и написать, что он лично руководил миграцией проекта с монолита на микрофронтенды и внедрением строгой типизации. Кроме того, Пете не впадлу перерисовать скаченную с госуслуг справку с подтверждением опыта, на что Вася так и не решился. Рынок нынче жесткий, поэтому работу получает только Петя (если чего-нибудь подобного не случится), а Вася и Иннокентий продолжают заваливать откликами работные сайты. Таким образом, если вы недоумеваете, почему вы энный месяц не можете получить свой долгожданный оффер, несмотря на сильные 4-5 лет опыта и хорошие достижения, открою вам секрет — все дело в том, что кто-то наврал масштабнее, чем все, что описано в вашем резюме. Не готовы крутить шесть лет с нуля? Петя накрутит. Не готовы врать про опыт в бигтехе, которого не было? У Пети будут минимум две компании. Не готовы рисовать выписку пдф? Петя нарисует. Стесняетесь использовать ИИ оверлей? У Пети два разных. Пять лет назад преимущество на рынке получал самый опытный и самый способный, а сейчас — самый беспринципный. И это наша, как сообщества, большая беда.9,52%
  • 13 авг.Как я с React на Svelte перешла Бытует мнение, что фронтенд-фреймворк — как факультет в Хогвартсе, выбирается один раз и на всю жизнь. Потому что разный синтаксис, разная экосистема, и вообще переходить с одного фреймворка на другой якобы очень сложно. Сложность перехода между фрейморками — вредный миф. Подозреваю, что придумали его ребята, которые в 2021 году говорили “я не буду учить JavaScript, я же пишу на React”. Фреймворк — это инструмент, который берет часть задач JavaScript-разработчика на себя, а не отдельная профессия, которую надо месяцами учить. Учить надо программирование и основные концепции разработки, а конкретный фреймворк можно освоить за неделю-две. Я совершала переход между фреймворками дважды. В 2019 я, имея опыт только на Vue, получила оффер в проект на React, а в прошлом году пришла в команду, которая пишет на Svelte. Где-то между делом года четыре назад я немного соприкасалась с Angular, так что, в целом, у меня есть опыт со всеми популярными фронтенд фреймворками. Современные фронтенд-фреймворки имеют схожие концепции: Реактивность. Вы перезаписываете данные, а UI обновляется сам. Не нужно редактировать DOM-элементы. Код делится на переиспользуемые компоненты: кнопки, таблицы, панели, формы и т. д. Внутреннее состояние (state/signal), входные данные (props/input), эффекты. Написание кода на фронтенд фреймворках сводится к следующему: вы разбиваете код на компоненты, в которых храните состояние аналогично проперти классов в ООП, используете эффекты для подписок на изменение состояния (Оbserver), пропсы для передачи данных вниз и события для передачи данных наверх. Интерфейс будет обновляться самостоятельно — таким образом, вам нужно следить только за организацией данных. Когда вы переходите на другой фреймворк, вы не начинаете обучение с нуля, вы используете уже знакомые концепции. Конечно, к фреймворку привыкаешь. Когда я начала писать на Svelte, первые пару недель мне было немного неудобно. Потом я поняла, в чем дело: в React единица реактивности — это компонент, он ререндерится весь целиком. В Svelte единица реактивности — это сигнал. В компоненте может быть много сигналов и они все будут перевычисляться независимо. Поэтому привыкаешь мыслить более мелкими абстракциями. Но каждый раз при смене фреймворка я не училась программировать заново — я всего лишь читала документацию и привыкала к новому инструменту. Кстати, документацию можно прочитать за один вечер 🙂 🔜 Канал в MAX6,80%
  • 6 авг.Ни одна ллм вам не напишет такой шедевр6,28%
  • 29 июл.Досмотрела нашумевшее интервью с CTO Skyeng. Коротко: будущее наступило, мы уволим всех тех, кто не хочет адаптироваться к переменам и делать одновременно 10 задач стаей агентов. Полминуты спустя: операционная система? Ну конечно мак! Я по-другому не умею. Я всю жизнь на маке. Еще чуть ранее она же говорит, что отказалась от использования open claw, потому что оказалось неудобно. То есть, внезапно оказывается, некоторые вещи неудобно делать LLM-кой. Позже напишу о том, что я думаю про то, что “нас всех заменят”.4,92%
  • 21 июн.Вот такую вакансию увидела на канале Леси и хочу немного прокомментировать. За DE не скажу, буду говорить о моей профессиональной сфере — веб-разработке. “Нужен человек полностью соответствующий нашим ожиданиям, а НЕ который учится на ходу.” — довольно популярная мечта у работодателей. Многих раздражает, что новый сотрудник какое-то время онбордится в проект и разбирается во всех его нюансах, и только потом начинает предлагать какие-то здравые идеи. Отчасти пожелания к годам опыта связаны с этим фактором: работодателям кажется, что если придет опытный специалист, он телепатически разберется в нюансах проекта и вытащит его из кризиса прямзавтра (или ещевчера). По этой же причине не очень любят нанимать джунов: “нужен сотрудник, который сразу приносит пользу, а не которого надо обучать” (с). К сожалению, это несбыточные мечты. Основная сложность коммерческой разработки не заключается в самом программировании. Большую часть времени на новом месте занимает изучение проекта: его архитектуры, бизнес-логики, ограничений, процессов и исторически сложившихся решений. Самое сложное в коммерческой разработке — это разобраться в нюансах конкретного проекта. Написать код может кто угодно при условии, что известно, как он должен работать. Проблема в том, что в коммерческой разработке никогда не известно, как именно код должен работать и какие ограничения необходимы. Это зависит от конкретного проекта, то есть от особенностей бизнеса, которые определяются текущим законодательством, экономической ситуацией, решением руководства и отношениями между отделами. Разобраться в этом и есть самое сложное, с чем сталкивается рядовой разработчик, приходя на новое место. Именно поэтому, кстати, для разработчиков имеют такое большое значение документация к проекту и читаемость кода. Неприятная для работодателей новость состоит в том, что при смене проекта все эти знания приходится осваивать заново.Таким образом, вы всегда нанимаете джуна, даже если у него 10 лет опыта. Возможно, для некоторых нанимающих это новость. Придется с этим смириться. Во фронтенде человек, прошедший обучение по современных технологиям (HTML, JavaScript, TypeScript, какой-нибудь фреймворк) с хорошим знанием CS (профильной вышкой) и математическим мышлением (умением выделять абстракции и оперировать ими) становится полноценным бойцом (то есть миддлом) спустя 3-6 месяцев работы. Что касается ребят, которым программирование дается сложнее (ну, скажем условно, “гуманитариев”) и у которых нет профильной вышки, то такой человек станет полноценным миддлом спустя год, максимум полтора года работы. Я видела десятки таких примеров. И не только я: до повсеместной моды на накрутку опыта большинство компаний искали фронтендеров миддлов с опытом от 1 года, потому что большинству моих коллег известно, что после года опыта 99% фронтендеров становятся полноценными бойцами, даже если у них нет вышки и “математического склада ума”. Таким образом, для того, чтобы быстро свитчиться между технологиями и проектами, вам не нужно много опыта. Надеюсь, я смогла проиллюстрировать выше, что в коммерческом программировании нет ничего сложного и набивать “опыт” в этом — это то же самое, что набивать опыт в ходьбе по улице. Мы же не говорим, что 30-летние люди лучше ходят по улице, чем 20-летние? Это абсурд. И те и другие вроде не падают :) Для того, чтобы быстро свитчиться между технологиями и проектами, вам нужна база CS (алгоритмы и структуры данных, паттерны проектирования, операционные системы, сети) и архитектурные навыки. Это научит вас быстро и точно соображать, а это в нашем деле — самое главное.3,81%
  • 20 июн.Составила чек-лист подготовки к собеседованию на позицию frontend-разработчика. Забирайте себе и шерьте друзьям🫶 🔘HTML & CSS - Семантическая верстка - Box Model - Специфичность селекторов - Как отцентрировать div - Position, display, box-sizing - Opacity, visibility - Браузерный рендеринг: layout /paint /composition - Flexbox, grid 🔘 JavaScript - Типы данных - Виды функций (arrow, function declaration, function expression) - Event loop - Промисы, async/await - Замыкания, лексические окружения - This - Область видимости, hoisting - Сборщик мусора - Утечки памяти, способы их обнаружения и устранения 🔘Браузеры - Всплытие и перехват событий - preventDefault, stopPropagation - Хранилища: localStorage, sessionStorage, IndexDB, cookie - Что происходит, когда вы вводите адрес сайта и нажимаете Enter 🔘HTTP - HTTP 1.1 vs HTTP 2.0 - Вебсокеты, SSE - Методы HTTP - Rest API - Статусы HTTP ответов - CORS 🔘Безопасность - XSS - CSRF 🔘 React - Архитектура Fiber, Virtual DOM, Reconciliation - Ключи (key) - Мемоизация - useLayoutEffect, useEffect - useRef - Почему компонент рендерится 🔘TypeScript - Чем отличается type от interface - Утилитарные типы (перечислить несколько) - Type guards 🔘 Git - Merge vs rebase - Git flow - Trunk bases development 🔘Архитектура - Микрофронтенды, module federation - Стейт менеджеры - FSD #чеклист #собеседования3,73%
  • 28 янв.без подписи3,39%
  • 16 июл.❓Что делать, если валят на собесе и как пройти собес, если вы не помните всю спеку наизусть Ситуации, когда разработчики с хорошим опытом и сильными навыками не проходят собеседование, встречаются гораздо чаще, чем кажется. Обычно проблема заключается в коммуникации. Кандидаты почему-то думают, что на собеседовании они должны поразить интервьюера своими энциклопедическими знаниями и феноменальной памятью. Из-за этого, забыв какую-нибудь мелочь, вроде порядка аргументов у стандартной функции или точное название метода, начинают паниковать и надолго застревают. В итоге получают фидбек “застрял на мелочи и не смог продвинуться дальше”. В большинстве случаев интервьюер оценивает совсем не это. Ему важно увидеть, что вы умеете программировать, рассуждать и решать технические задачи. Ниже опишу некоторые сложности, с которыми часто сталкиваются кандидаты: 1️⃣Вы не поняли смысл задачи и что от вас хотят Проговорите условие устно: “я правильно понимаю, что в этой задаче требуется сделать текстовый инпут, получать данные с сервера по поисковой строке и отображать их в списке ниже”? Вы синхронизируетесь с интервьюером, поймете лучше, чего от вас хотят, а интервьюер, в свою очередь, поймет, что вы смогли понять задание и это ваш плюсик в карму 🙂 2️⃣Вы забыли стандартный метод, порядок аргументов в нем или возвращаемое значение Спросите у интервьюера! Прямо говорите: блин, есть метод, который позволяет свернуть массив в одно значение-аккумулятор, не помню, как называется… Интервьюер подскажет, а если не подскажет, смело просите погуглить. И гуглите. Только экран шарьте, чтобы интервьюер понимал, что вы делаете. 3️⃣ В задании что-то сделано не так, как вы привыкли, и вы не можете сообразить, как использовать это новое и непривычное Например, вы привыкли, что запросы на сервер вынесены в хук, а тут обычная функция. Или наоборот. Решение: просто скажите интервьюеру, что вас смущает! Вроде: хм, я вижу, тут запрос сделан функцией, а я обычно использую хук, сейчас попробую понять, как использовать функцию, а не хук… Так интервьюер по крайней мере поймет, что у вас происходит в данный момент, с какой сложностью вы столкнулись и на чем застряли. 📌 Как видите, все сводится к тому, что с интервьюером надо коммуницировать. Интервьюеры часто реджектят не слабых, а непонятных кандидатов: пришел, потупил, помолчал, на чем-то застрял, ничего не сделал, хз что за чел. Или пришел, помолчал, все решил, но ничего не объяснил, мутный какой-то, наверное списал все. Что происходит? Что именно не получается? Он вообще знает или нет? Затащит продакшн таски? Может да, а может нет. Непонятно. Ваша задача — быть ПОНЯТНЫМ на собеседовании. Интервьюер должен понять, что вы делаете и как вы делаете. Для этого надо коммуницировать и быть искренним. Всем удачных собеседований!❤️ #собеседования 🔜 Канал в MAX2,88%
  • 8 июн.Как я на go в продакшн писала История была год назад. Нашей команде достался проект с жестким дедлайном. Я уже заканчивала фронтенд, а бекендеры все сдвигали свои сроки и, в конце концов, признались, что не успевают — слишком много задач помимо этого проекта. Тогда я сказала, что я все сделаю сама, только дайте доступ. Лид удивился и возразил мне тем, что в моем резюме написано “frontend-разработчик”. Как вы, наверное, помните, мне в целом не очень импонируют все эти надуманные ограничения вроде “фронтендер не может закрывать таски на бекенде”, тем более я не на лиспе писать собралась, а на еще одном c-like языке. Доступ мне дали. Бекенд оказался на go. В выходные я потыкала курс по базовому синтаксису go на хекслете и почитала книгу, которую мне посоветовала подруга. Работа над проектом началась непросто: я никак не могла скачать корпоративные модули, несмотря на (вроде бы) правильную настройку конфигов и переменных окружения. Пришлось мучать лида (кажется, он был не очень доволен). Мы провозились пару часов, и в конце концов оно как-то заработало (я точно не поняла, что именно помогло с этой проблемой). После этого меня ждал новый сюрприз: абсолютно пустой readme и огромный makefile с богатым разнообразием команд. Я решила не гадать на кофейной гуще и спросить у лида, как стартануть проект. А никак, — ответил лид, — он локально не запускается, в CI можно стенд собрать. На этом моменте я на все плюнула и пошла в спортзал тягать железки. День два. Я решила, что даже если я не могу проверить свой код, написать-то я его все равно могу, логично? Начала читать таску и обнаружила, что аналитик любезно все описал, включая таблицы БД, которые нужно добавить/изменить, и какие поля добавить в эндпойнты. Осталось всего лишь перевести это все в код, что, как вы понимаете, изян задача. Еще несколько дней я убила на миграции и тесты. Стало понятно, почему ребята не парились из-за невозможности локального запуска — тесты и CI/CD проверки хорошо покрывали кодовую базу, и у меня несколько дней реально ушло на то, чтобы добиться прохождения тестов и пайплайна. Попутно я разобралась, как это правильно делать. По итогу выяснилось, что я использовала неправильные строковые константы для сообщений об ошибках и накосячила в одном месте из-за плохого знания домена (надо было фильтровать сущности по определенному полю, кто ж знал). Но в целом нормально. Ну а потом я перешла в другую команду и моя славная карьера go-разработчика закончилась. В новой команде я уже больше полугода пишу на Svelte. Позже расскажу, с какими сложностями я столкнулась после того, как перешла с React на Svelte (спойлер: ни с какими, две недели немножко неудобно, а потом привыкаешь).2,87%
  • 26 июл.Дядюшка Боб не читает код AI-агентов. Я тоже. В сети хайпит твит дядюшки Боба, в котором он признается, что вовсе не читает код, который пишут его агенты. Многие пишут, что таким образом он теряет контроль над кодом. Это не так: в том же твите он пишет, что использует много тестов и другие quality gates. Таким образом, он просто меняет способ контроля: автоматические проверки вместо привычного “метода пристального взгляда”. Я тоже не читаю код, который пишут мои агенты. Сразу уточню, что далеко не весь код я пишу при помощи агентов и довольно много кода пишу руками. Но если уж я решила отдать задачу агенту, то не читаю каждую строчку, иначе во всем этом нет никакого смысла. Строго говоря, использование кода, написанного агентом, мало чем отличается от использования сторонней библиотеки. Вы же не читаете исходники библиотеки, которую добавляете в свой проект? (Я, по правде, иногда читаю, но только тогда, когда что-то странно работает, и только ту часть, с которой проблемы). Такой подход использует идеи ООП: код, написанный агентом, является черным ящиком, а нас интересует его контракт (делает то, что заявлено), а не внутренняя реализация. Ниже опишу воркфлоу и ограничения, которые я использую. 1️⃣ Только задачи с уже принятыми решениями Я отдаю агенту только те задачи, с которыми нет неопределенности: я абсолютно точно знаю, что я сама бы написала, если бы писала это руками. Если я сама точно не знаю, что конкретно надо сделать и нужно решать по ходу, то это не тот случай. 2️⃣ Только мой стек Агент пишет код только в том стеке, которым я хорошо владею, в моем случае это фронтенд. Мои навыки в бекенд разработке у меня гораздо слабее, поэтому бекенд я пишу самостоятельно, осмысляя каждую строчку. 3️⃣ Не отдаю core часть Основные части системы я пишу вручную. Агент хорошо подходит для изолированных утилит, плагинов, вспомогательных модулей и прочих локальных задач. 4️⃣ Спецификацию пишу в виде тестов Для меня это оказалось более удобным, чем md файлы. В тестах я на естественном языке определяю, как должна работать та часть кода, которую я делаю. 5️⃣ Тесты генерирую агентом Код тестов генерирую при помощи агентов. Затем читаю и убеждаюсь, что он меня устраивает. 6️⃣ Генерирую код После генерации тестов я приступаю непосредственно к генерации самого кода. Затем запускаю тесты, сборку и автоматические проверки (линтер, etc). Если все ок, тогда смотрю, какие конкретно файлы изменил агент (git status). Смотрю общий объем сгенерированного кода при помощи git diff. Если выглядит ок, то делаю commit и push. Этот воркфлоу, конечно, не идеален, но удобен для меня. Кроме того, как я уже сказала, большую часть кода я по-прежнему пишу руками (там, где нужно по ходу понять, что именно нужно сделать, и core часть). Всем удачного вайб-кодинга 🥹 🔜 Канал в MAX2,57%
  • 9 маяОдин принцип, который делает разработчика middle+ Заголовок кликбейтный, но я собираюсь его оправдать. В разработке самое главное понимание касается не того, как написать код, а того, как он должен работать. То есть — нужно понять, как должна работать система в целом и на корнер кейсах, и как она будет развиваться дальше. Чтобы разобраться в сложных кейсах, разработчики обычно смотрят, как сделано в других местах или ориентируются на лучшие практики, но самый правильный путь — понять, какова бизнес цель ваших действий, тогда сразу станет понятно, как следует сделать. Приведу пример. Недавно мой менти делал Input с ограничением длины ввода и задал максимальную длину ввода пропсом max?: number | string На вопрос, зачем здесь string, он ответил, что где-то читал, что так лучше. Давайте подумаем. Мы делаем компонент, который будут использовать другие разработчики нашей системы. В таком случае мы можем потребовать, чтобы строка конвертировалась в число до передачи в компонент. Таким образом мы делаем нашу границу более строгой. Что нам это дает? 1. В Input меньше кода => легче поддержка 2. Меньше потенциальных багов и возможностей ошибиться 3. Унификация кода Получится, что мы должны затипизировать так: max?: number. Если развить эту мысль, то мы можем прийти к выводу, что ограничение длины должно быть обязательным. Например, для расчета ширины. И тогда получится max: number. Следует ли из этого, что нам всегда следует типизировать пропс именно так? Нет. Можно легко найти сценарии, где решение моего менти будет более подходящим. Например, если вы делаете библиотеку для JavaScript-разработчиков. JS не подскажет корректный тип, и им слишком легко ошибиться — с нашей стороны логично будет их подстраховать. 📌 Таким образом, когда вы принимаете решения, ориентируйтесь на целесообразность и бизнес-потребность. Не бывает никакого “хорошего” и “плохого” кода в вакууме, бывает хорошее решение конкретной задачи и плохое.2,42%
  • 21 мар. 2025 г.без подписи2,38%