Metarhia Chief Level

https://youtube.com/live/vTMf21FG6wg

https://youtu.be/IDxb5eLx2b4

Проблема сложности, которую решают микросервисы, на самом деле решается проектированием структуры кода на среднем уровне, т.е. люди от функций и классов хотят перескочить сразу к архитектуре, минуя модули, слои, подсистемы. Если код хорошо структурирован на среднем уровне благодаря:
- системам модульности,
- внедрению зависимостей и инверсии управления,
- архитектурным границам и слоям,
- декомпозиции абстракций,
- separation of concerns,
- information expert,
- контрактному программированию,
- управлению, сокрытию и изоляции сложности,
- разделению прикладного и системного кода,
то такое приложение можно в течении нескольких часов собрать в 2, 3, 5, 105 инстансов, заменив взаимодействие между их структурными компонентами на RPC и трансляцию событий. Так, что модули и подсистемы знать не будут, что они запущены не в одном процессе. А если код «рыхлый», то его и микросервисом не изолировать, у такого сервиса будет большой внешний трафик, потому, что зацепление на чужие данные и чужую логику высоки. Так что, «распиливание» это только распиливание бюджета команд и бюджета на инфраструктуру. Обойти вопрос хаоса на среднем уровне при помощи чуда не выйдет. Чтобы построить Application архитектуру, нужна качественная структура, а чтобы перейти к Solution и Enterprise архитектуре, нужна качественная Application архитектура. Попытки перескочить от функции, цикла и массива к Solution архитектуре приводят к появлению монстров типа облачных функций, микролитов, моносервисов и скоро мы увидим Variable as a Service, а потом гору этих абстракций, вываленных на уровень Solution, не сгруппированных и не изолированных в структурные единицы управления сложностью. Чуда не будет, ни кто не решит за нас вопрос перехода от отдельного кирпича к небоскребу, нужны промежуточные структурные единицы.

🧩 Тарифные планы тренинга с наставниками Patterns 2024

∙ Minimal: обучение в общей группе без наставника, но с групповыми семинарами
∙ Standard: обучение с наставником в небольших группах (10 человек)
∙ Professional: обучение с наставником, индивидуально и в группах, дополнительные материалы
∙ Exclusive: персонализированный учебный трек с автором курса и приглашенными экспертами

👉 Подробности: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Patterns-2024-ru.md

Формат тренинга

🗓 12 недель (3 месяца) + онбординг (1 неделя) + секретный модуль
👍 Доступ к материалам курса дается навсегда
🕑 Каждую неделю обязательно: 1 час лекций + 2 часа семинаров + 2 часа самостоятельной работы
🥋 Тренировки и групповая работа с наставниками, а не только смотрение видосов и чтение
🙋‍♂️ По желанию: для глубокого погружения +3 часа дополнительных материалов на старших тарифах
🏅 По завершению курса Вы получаете сертификат
⚠️ Входные требования: базовый JavaScript + рекомендуется опыт практического программирования
🙅 Для кого не подойдет: не для начинающих, бесплатные материалы для начинающих ищите у Тимура
💳 Рассрочка: помесячная оплата для всех тарифов кроме минимального
🗺 После курса участие в комьюнити выпускников, где уже тысячи людей по всему миру

👉 Купить: https://nodeua.com/Patterns-2024-buy.html

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

— Интеграция систем гораздо сложнее, чем их разработка.
— Но мы же не можем сами написать все! Что же делать?
— В общем случае нет решения! Но мы это сделаем.

🎓 IT образование: для себя определил, что неприемлемо брать деньги с начинающих, с людей, которые еще не знают что им нужно, которые вообще слабо ориентируются в отрасли. Обратите внимание, большинство трешевых ИТ-школ и "инфобизнесменов" специализируются именно на начинающих, им же можно рассказывать про циклы месяц, про переменные разжевывать и про операторы еще месяц, массивы учить и уже через полгода написать какой-то несчастный тудулист или чатбот, в виде простыни кода, и они рады, у них есть результаты, ну вот реально что-то получилось. А попробуйте продать что-то мидлам и синьорам, у них уже сформировалось мировоззрение, есть свое видение, им доказать ценность вашего курса на порядки сложнее. А потом они будут требовательными в процессе обучения, окажется, что нужно быть специалистом высокого уровня, тратить много времени, чтобы удовлетворить их, ответить на вопросы, не засыпаться от реальных продуктовых примеров кода, которые они приносят на занятия для разбора. А начинающих, ну я готов допустить, что можно брать с них деньги за наставничество, за проверку работ, за ревью кода, но не за учебный материал, которого и так море в интернете. Но такое наставничество, это удел джунов, которые еще год назад сами были такими же, и не может быть бизнесом, оно так же полезно этим наставникам для их роста, как и для начинающих. По-хорошому, вообще непонятно, кто кому платить должен. В идеале, сам процесс должен выходить в ноль по затратам сил и пользе с обоих сторон и может идти как взаимозачет. Посмотрите на всех приличных людей, которых вы знаете в ИТ-образовании, они концентрируются на обучении людей, которые уже работают и могут заработать на свое образование. Ни в коем случае не учите начинающих, которые берут кредиты на обучение, которые одалживаются или тратят последние деньги на то, ценность чего еще сами не понимают. Они еще 100 раз передумают, бросят, опять начнут, переметнутся на другой язык, поймут, что душа лежит к какой-то третьей экосистеме, и главное, что первые полгода они не могут определить качество обучения. И вот тут из кустов появляются создатели "образовательного контента", высокохудожественные читатели документации и прочие мошенники. Люди, учите друг-друга, не давайте этой нечисти парить голову начинающим, помогите им проложить роадмап в профессии, материала море, до первой работы можно вполне на нулевом бюджете доучиться, вкладывая только время и силу воли.

🔤🔤🔤🔤🔤🔤🔤🔤🔤🔤
🔤🔤🔤🅰️🔤🔤🔤🔤🔤🔤
🔤🔤🔤🔤🔤🔤🔤🔤🔤🔤
🅰️🔤🔤🔤🔤🔤🔤🔤🔤🔤
🔤🔤🔤🔤🔤🔤🔤🔤🔤🔤

✔️ Как в JavaScript/TypeScript реализуется SoC (separation of concerns) и для чего он нам?

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

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

🧩 Mediator - снижает зацепление и подойдет нам для изоляции базы от транспорта.
🧩 Strategy - реализация стратегии для JavaScript это Map<PropertyKey, Implementation> что позволяет абстрагироваться от Implementation, находя его по ключу и работая по обобщенному интерфейсу.
🧩 Bridge - позволяет разделять абстракции и снижать зацепление, но не характерен для JavaScriot.
🧩 Abstract factory - для JavaScript абстрактная фабрика сводится к стратегии инстанциирования: Map<PropertyKey, Creator> и применяется как и стратегия, но в том месте, где нам нужно создавать инстансы (тут Creator это любой порождающий паттерн).

Признаки проблемы:
• Если вы не можете модифицировать работу с базой не трогая транспорт или бизнес-логику, не задевая базу, то нужно начинать внедрять разделение ответственности (separation of concerns).
• Если сложно написать юниттесты, а что-то протестировать можно только все целиком - ну вот оно, вы нашли проблему.
• Если код невозможно переиспользовать и вы чувствуете, что одно и то же пишете уже много раз.

Примеры на курсе по паттернам 👉 https://nodeua.com/Patterns-2024-buy.html

🖼 [email protected] - released

📦 [email protected]
📦 [email protected]
📦 [email protected]
📦 [email protected]
📦 [email protected]

👉 Example updated: https://github.com/metarhia/Example

🖼 Готовимся к выпуску impress 3.0.16 - пуру дней и все соберем
Основные изменения:
- Переход на eslint 9.x
- Поддержка node.js 22

📦 [email protected]
📦 [email protected]
📦 [email protected]
📦 [email protected]
📦 [email protected]
📦 [email protected]
📦 [email protected]
📦 [email protected]

https://youtu.be/sm9FVEa9P9Y?t=0

Открыта предварительная регистрация на курс Patterns 2024 — я уже изучил всю доступную литературу и конкурентов и теперь уверен — аналогов нет, ни кто так и не смог сделать приличной адаптации паттернов к JavaScript, TypeScript, Async, Node.js миру — https://nodeua.com/Patterns-2024-buy.html

В субботу будет мастер-класс «Middle to Senior in 2024» в 15.00 (GMT+3) 👉 https://t.me/JavaScriptPatternsBot?start=TIMUR

https://youtube.com/live/Jru7q-OjWX8

https://www.youtube.com/watch?v=LJJpbFcmKQs

✅ План стримов по паттернам:
08 августа - четверг - ITBeard
09 августа - пятница - Деми Мурыч
10 августа - суббота - Илья Климов

Почему нужно избегать union-тайпов?

1. Каждый раз, когда юнион куда-то приходит аргументом, нужно делать if, чтобы понимать, как с ним работать, кроме случая, когда все классы/типы, входящие в юнион имплементируют один и тот же интерфейс и нас интересует обращение именно через этот интерфейс, зачем тогда юнион, используйте этот интерфейс вместо него, ну если в юнион не входит undefined, null, unknown и т.д.

2. Юнионы приводят к мегаморфной форме обращения к объектам в V8, и это замедляет код, не сметртельно, но это неприятно и проще всего всего забыть их. Но для чего же они тогда вообще нужны? Для совместимости с JS, если в нем можно передать что-угодно аргуметом, то это нужно меть возможность как-то выразить. Это не значит, что это хорошо и так нужно писать кода, это добавили как возможность, а не как обязанность )

3. Это часто ведет к нарушению SOLID:SRP (принципа единственной отвественности), потому, что как может метод, например, получать сокеты или таймеры на выбор и делать разные вещи в зависимости от этого, это же маразм, нарушает SOLID:LSP (принцип подстановки), иногда нарушает GRASP:InformationExpert, явно повышает Coupling.

Вместо этого нужно всегда использовать маленькие интерфейсы, заточенные под узкую задачу, помним про SOLID:ISP (принцип разделения интерфейсов) и могут быть optional аргументы, для этого не нужно делать union с null.

https://youtu.be/aJGB7TLwiig

🧩 Пока я готовлю курс по паттернам GoF, SOLID, GRASP с адаптацией для Node.js и JavaScript, собрал тут ссылки на все старые материалы, видео, примеры кода, задачи, если по ссылке github репозиторий, то часто там и примеры и видео: https://github.com/tshemsedinov/Patterns-JavaScript