Сделал шортсы на общие темы по JavaScript

История языка JavaScript
https://youtube.com/shorts/lVAUXAu5OLo?feature=share

Достоинства языка JavaScript
https://youtube.com/shorts/1JpcHdp93Rw?feature=share

Недостатки языка JavaScript
https://youtube.com/shorts/qqR9glPyX6w?feature=share

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

Всем привет, никогда не обращался лично, теперь исправляюсь !

В первую очередь нам по-хорошему нужно познакомиться, меня зовут Кирилл и я Тех Лид одной крупной Питерской компании. Так же если без умных слов то full-stack разработчик. Я веду этот канал, канал на Ютубе, бота собеседника @interviewITBot, канал по Python, портал A-LIT с ответами на вопросы на собеседовании.

После того как мы познакомились я бы хотел разнообразить обычные посты, постами о жизни в реальных проектах.
Как первый пост я хочу поднять тему архитектуры и как ее местами недооценивают. Очень часто хорошая архитектура это та архитектура от которой можно хорошо расширять проект. Самое интересное что говоря про архитектуру обычно все говорят про Backend, но и на Фронте так же есть свои подходы, и в базах данных тоже есть свои принципы проектирования. Чтобы не нагружать абилием информации я бы рассмотриел основные подходы и проккоментировал каждый из них кратко.
Рассмотрим Backend:
Чистая архитектура - суть в разграничении, то есть делать так чтобы наши составные были как луковица, нижнии слои не знали о верхних
DDD - все говорят что это страшно и сложно и вы не поверите, но это реально страшно и сложно. Самое главное что вам нужно вынести от сюда это то как вы коммуницируете внутри команды и насколько новым людям будет просто окунуться в текущий проект
Монолит - все просто, одна большая куча. Тут вы можете как раз использовать чистую архетиктуру, SOLID, Kiss и Dry принципы и ваш проект будет вполне себе адекватный.
Микросервисы - звучит как что-то крутое и это реально крутое, потому что система условно децентрализованная и допустим микросервис товары если упадет не затронет микросервис оплат, что очень хорошо будет сказываться на любви пользователей. С помощью такого подхода мы можем очень хорошо дробить наше приложение на более мелкие части
Event sourcing и CQRS - эта штука дружит с микросервисами и условно делает слепки исходя из событий которые приходят от пользователя
Рассмотрим FrontEnd:
Классика - тут главная проблема что все в куче и связи неявные, то есть местами переиспользовать или вычленить компонент реально бывает трудно
Модульная - тут мы уже выделяем логику переиспользуемую в модули, что как раз более менее позволяет выделить атомарные сущности и с ними уже работать
Атомарная - тут принцип от меньше к большему, то есть атомы -> молекулы -> организмы -> шаблоны -> страница. Прикол в том что мы постепенно наращиваем функциональность, что позволяет отдельно взятые участки переиспользовать.
FSD (Feature-Sliced Design) - тут уже все доведено до ума в полном объеме. Разделение Слой/Слайсы/Сегменты. Тут мы по полной применяем слойную архитектуру, нельзя чтобы нижние слои зависели от верхних
Микрофронтенды - подход такой как и с микросервисами, суть в том что мы делим наше приложение на какие-то обособленные приложения. То есть у нас есть блог/админка/магазин и это три разных фронта и этими фронтами уже могу заниматься разные команды.
Рассмотрим БД:
По базам данных тут на самом деле все просто, всего есть 6 нормальных типов БД. Нормальный тип это вид базы данных в котором соблюдены все правила описанные в типе, они направлены на достижение Базой хорошей расширяемости. Процесс нормолизации это привод базы данных хотябы к 3 нормальному виду.

Как видим что во всех частях приложений очень большой акцент делается на двух вещах.
1) Переиспользуемость
2) Расширяемость
Нет правильной и неправильной архитектуры, выбор ее уже зависит конкретно от проекта

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

Завтра будет удачное собеседование на позицию Junior React Developer
Там мы проведем собеседовние у человека, зададим технические вопросы по React

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

Удачное собеседование на позицию Junior React Developer
Тут мы проведем собеседование у человека, зададим технические вопросы по React.

Скидывайте сюда свое резюме и позиция на которую хотели бы попробоваться
Почта: poznkirill1@gmail.com

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

https://www.youtube.com/watch?v=O3grSSHG-x8&t=26s
Смотреть видео

Совсем недавно вышел новый State Manager для React

Очень много технологий выходит каждую неделю и достаточное количество из них остаются обделенными вниманием. Это не касается нового State Manager-a как Zustand. Если говорить про Redux и RTK Query, то там мы обычно взаимодействуем с единым стором, что местами не дает сделать разграничение между модулями явным. Я попробовал Zustand и он неплох, но естественно так как пока этот state manager молодой еще нет никаких хороший практик применения.

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

Хотели бы видое по Zustand ?

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

Я как человек много прошедший собеседований и сам их устраивающий скажу так, врать нагло об опыте не надо. Если вы только начали свой путь, а пишите что вы 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
Смотреть видео