Можно ли привирать об опыте в резюме ?

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

Почему работодатели так делают ?
Первое: Зачастую требования могут писаться некомпетентными людьми, которые реально не знают откуда формируется логичная цифра по опыту для определенного уровня разработчика
Второе: Так можно отсечь неуверенных в себе разработчиков. Неуверенный в себе разработчик это тоже проблема в каком-то роде, так как такой разработчик будет бояться брать задачи наподобие которых он раньше не решал.
Третье: Берут цифру с потолка, никто не раздумывает о том 3 или 4 нужно опыта для этой вакансии, берут цифру больше (то есть 4). Хороший программист по мнению работодателя - это тот который пишет код как Senior, а зарабатывает как Junior.

Привирать можно (особенно если ищите свое первое место работы), потому что зачастую в вакансии просто все полотно что есть в компании сгружают и ждут с неба погоды

На этой неделе будет что-то крутое

на этой неделе выйдет ролик где мы с полного 0 на чистом JS напишем простой аналог React-а.

Накидайте реакций чтобы поддержать меня 😊

СОЗДАЕМ АНАЛОГ REACT ЗА 20 МИН
Тут мы с полного 0 сделаем похожий алгоритм который реализует React у себя под капотом. Простой аналог React-a на чистом JavaScript

Накидайте реакций чтобы поддержать меня 😊

https://www.youtube.com/watch?v=qwb-GyMSvQM
Смотреть видео

Нужно ли вообще тестирование ?

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

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

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

Тесты есть трех видов:
e2e - самые приближенные к человеческому поведению, но ограничены тем что не могут как раз протестировать внутри как будут обстоять дела после тех или иных изменений
unit - когда атамарные части или области кода тестируются внезависомости от других составных частей
интеграционные - тесты которые смотрят на то как все компоненты/функции будут жить вместе

Есть даже пирамида тестирования, которая как раз и говорит о том каких тестов в каком количество нужно
Обычно лично я использую тесты на больших проектов, так как там как раз есть логика ( достаточно сложная ) , которую проверить тестировщику составит время. На маленьких проектов можно и без них на самом деле ( тут большое но какая логика там будет, если сложная то можно и рассмотреть )

Если хотите пост про BDD и TDD, накидайте реакций

Как упростить себе жизнь с помощью Vite ?

Обычно любое FrontEnd приложение мы начинали с настройки Webpack, так как это немного лучше чем использовать CLI для любого из фреймворков/библиотек. Таким образом мы можем настроить конкретно то что нам надо и не раздувать бандл. Все было хорошо пока я не наткнулся на такую интересную вещь как Vite и то как он подошел к тому чтобы собирать приложения.

Важно сказать что Vite это сборщик агностик, то есть подоходит абсолютно к любому фреймворку. Разберемся изнутри в чем вообще отличие подхода Vite от Webpack.

Начнем с того что Webpack тупо собирает ваше приложение, а при изменении файла он просто его пересобирает. Vite понял что ваши зависимости не так часто меняются во время разработки, поэтому он один раз связывает их с помощью esbuild, который быстрее Webpack или Parcel. Дальше же Vite запрашивает ваши модули как ES или ESM, что позволяет браузеру обрабатывать фактический бандл. Ну и как вишенка на торте, Vite поддерживает Hot Module Replacment и так как он запрашивает ваши модули как ES, он пересобирает только конкретно взятый кусок, а не все в целом.

Именно поэтому использовать сейчас Webpack на новых проектах я стал в разы реже
Если хотите полный курс по Vite, накидайте огней

Завтра выйдет экспресс-курс по React Native

Там мы рассмотрим как работает сам React Native под капотом. Старую архитектуру и новую архитектуру.
Рассмотрим все основные компоненты в React Native. Разработаем многостраничное приложение калькулятора.

Поддержи меня пожалуйста своей реакцией

ВЕСЬ REACT NATIVE ЗА 45 МИН
Тут мы рассмотрим как работает сам React Native под капотом. Старую и новую архитектуру. Рассмотрим все основные компоненты в React Native. Разработаем многостраничное приложение калькулятора.

Поддержи меня свой подпиской и лайком
https://www.youtube.com/watch?v=uGlQ9HXb6e8
Смотреть видео

Чем микросервисы на backend хороши в больших проектах ?

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

Микросервисы в этом же случае помогает распределить ответcтвенность и уже если какой-то сегмент приложения упадет, он не затронет другой. Это очень хороший способ снять отвественность с единой точки.

Это что касается того что будет видно сразу и понятно сразу же. Но есть еще момент из-за которого на больших проектах микросервисы предпочтительней нежели монолит

Как-то когда работал, прилетел мне один проект, проект был легаси, честно говоря и к тому же большой. Такие проекты это головная боль, рефакторить их это дело то еще. Если изначально начинать разработку микросервисов, вы обезопасите себя тем что вы можете кусками просматривать/разрабатывать ваше приложение. Вы можете отдавать эти куски разным командам, которые даже не будут предполагать о других составных частях.

Теперь более технически: Для разработки микросервисов я использовал как брокер rabbitmq (недавно узнал что этот брокер самый медленный), оборачивал это все в докер и пулял на сервер. Если же были разные сервера, то там связь была просто по http. Важно понимать что базы у микросервисов должны быть отдельные иначе это не микросервисы. Так же еще важно понимать что передача сообщений должно быть защищенным, чтобы никакой залетный пассажир не получил важную информацию.

По литературе посоветую: Микросервисы (Крис Ричардсон).
Если интересно могу накидать оттуда интересных моментов, поддержи меня только реакцией

Вышел недавно новый ролик, очень нуждается в ваших лайках и просмотрах

Если вы его как-то пропустили, то помогите в продвижении бустаните его своим просмотром и лайком
Всем спасибо 😊

https://www.youtube.com/watch?v=uGlQ9HXb6e8
Смотреть видео

Как превратить проект в легаси и вытащить оттуда его ?)

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

Я как раз начал изучать тему как все это привести в нужный вид, то есть сам того непонимая окунулся в тему архитектуры. Там уже понял что в начале нужно обезопасить себя в структуре и раздлении от хаотичных зависимостей. В папке components не должно быть такого чтобы компоненты зависят от других компонентов. Самое простое что можно сделать это папке компонентов, в котором будут лежать атомарные компоненты и папку виджетов, в котором будут уже более сложные компоненты состоящие из других, но в виджете не должно быть других виджетов. Уже сама страница должно состоять из виджетов. Такая ахритектура называется atomic design. Это самое просто что может быть для frontend проекта. Есть множество других подходов, но под рефакторинг именно она более просто решает проблему.

Но этим же не ограничивается вопрос, нужно выделять функциональность, по-хорошему нужно выделять атомарные функциии - фильтры/валидаторы/обработчики ошибок в папку utils. Взаимодействие с сервером выделить в папку services/api там должна быть вся логика по запросам.
В компонентах не должно быть обработчиков бизнес логики

Касаемо сторов и производительности это уже стоит выделить в отдельный пост, потому что там много чего делали.

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

Используй TypeScipt везде
Поддержи меня реакцией

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

Курс будет рассчитан на специалистов уровня Трейни/Junior/Middle. Там мы подробно рассмотрим все аспекты конкретно JS. Сейчас от вас важна поддержка и будет ли такой продвинутый курс актуален

В курсе мы рассмотрим продвинутые темы подробно: Асинхронность, Promise, Proxy, Reflect, Переменные, Генераторы, ООП, Замыкакания, Каррирование,Прототипное насследование, Функции и контекст, Парадигмы программирования, SOLID, шаблоны проектирования, вебворкеры, сервисворкеры, рассмотрим протокол http и как передаются данные, RestAPI, работа с DOM API, Безопастность и лучшие практики и многое другое

Поддержи реакцией

Так же каждый купивший получит 1 часовую консультацию лично со мной
По времени: курс будет на 10+ часов
По цене: ~1980₽