Все библиотеки Metarhia обновлены, ни одна из них не была заражена во время сентябрьских атак на NPM.

👉 https://github.com/metarhia/Docs

ℹ️ Официально: Metarhia не имеет ни малейшего отношения к этим атакам

Сегодня Деми Мурыч с Виталием Брагилевским

Виталий Николаевич Брагилевский:
В прошлом член двух комитетов языка Haskell
Более 20 лет опыта преподавания
Автор книжки haskell in depth
Участник десятка конференций
Волшебник из НИИЧаВо

Ну а Мурыча вы знаете

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

Так выгладит окно, установленного в Chrome PWA из примера https://github.com/HowProgrammingWorks/PWA

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

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

Если нет владения кодом, то нет продукта. Непредсказуемый код ничего не стоит и только тянет компанию на дно. Но проблема не только в коде — владение это процесс.

Если ревью тянется неделями, каждое изменение рождает новые баги, как снежный ком — это системная проблема: отсутствие владения кодом, а скорее всего, и инженерной культуры. Как следствие — ужасная кодовая база. Как она стала такой — вы знаете.

А что делать? Вместо переписываний нужен рефакторинг, покрытие тестами, понижение зацепления, внедрение практик перекрестного ревью, работа малыми правками, никаких незакоммиченных изменений, оставленных на завтра. Не подгонять тесты под код, а исправлять код до тех пор, пока он не пройдет тесты. Изменения должны стать предсказуемыми, малыми и атомарными.

Что задерживает разработку и как?
Куда уходит время, которое можно было бы потратить на новые фичи?

🐢 долгое согласование — вопросы или задачи сформулированы так, что люди подсознательно их игнорируют, уходят от ответа, не отвечают на сообщения, не приходят на созвоны; процесс принятия решений затягивается.
🔗 высокое зацепление — части программы слишком тесно связаны: много обращений к чужим свойствам и методам, из-за чего изменения в одном месте ломают другое, и модули невозможно исправлять независимо.
🤯 недооценка сложности — задача кажется простой, но в процессе реализации выясняется, что есть скрытые зависимости, то же зацепление, обновление зависимостей, исключения и дополнительные условия.
🔥 тушение пожара — вместо планомерной работы, новой функциональности, приходится срочно чинить критические баги или решать кризисные ситуации, у пользователей работа встала, теряем клиентов, разрушаются данные.
🧩 нет типовых решений — похожие задачи есть всегда, но для них не всегда подготовлены типовые решения, каждый раз разработчик выделяет решение из сторого кода, нет единого переиспользуемого подхода.
📦 плохая декомпозиция — код разделен на модули не по смыслу и не по зацеплению, а по непонятному признаку, слишком крупно или нелогично; "ось изменений" проходит по нескольким классам или модулям.
🙈 непонятный код — сложно читается, не подходящая гранулярность (слишком мелкие или крупные части); именование даже не намекает на что-то известное; оверинжиниринг: использованы лишние абстракции, паттерны, слои.
⚖️ противоречивые требования — разные руководители и представители заказчика присылают разные противоречивые требования или команды хотят разное, требования конфликтуют между собой или даже противоречивы внутри.
🛑 ручные процессы — отсутствие автоматизации: нет или мало тестов, ручной деплой, воспроизведение багов делаются вручную, не соблюдается semver и не отслеживаются версии зависимостей, вызывающих проблемы.
🌀 изменение приоритетов — задачи и цели постоянно «прыгают», фокус команды рассеивается, людей дергают на созвоны, на которых политика опять меняется и ничего не доводится до конца, ответственных не найти.
🚧 технический долг — старые и успешно замаскированные проблемы никуда не исчезли, костыли и временные решения, когда-то введённые для ускорения результата, замедляют развитие новых возможностей.
🔒 блокеры от внешних команд — выполнение задачи упирается во внешнюю зависимость и все всех ждут (например, API другой команды, решение смежного отдела, партнеров, безопасности), и прогресс стоит на месте.

Вечером попробуем проголосовать, чтоб собрать статистику, как у вас на проектах. Набросайте, что вас задерживает.

Хрупкий код — это когда каждое изменение ломает что-то еще, а вы сидите в дебагере, а потом откатываете до рабочего коммита, иначе проект не собирается. Дебагер в проекте — это зло, его место — исследование рантайма, можно лучше понять инструмент ­— да, но в разработке, дебагер — это просто слив времени в никуда.

Это обычное состояние проектов, когда код хрупкий, иначе это намного дороже для компании. Новое портит старое, вы ковыряетесь в легаси, рефакторите без цели. Такой код — это техдолг, который растет экспоненциально, как снежный ком. Ваше время уходит не на создание ценности для продукта, а на тушение пожаров. И тут вы со своим дебагером. Давайте тушить пожар бензином. Отличное решение.

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

Признаки кризиса:
- в почте нет предложений о работе, не зовут на собесы
- вы не едите в карьерном лифте и ЗП не растет
- страшно уволиться, остаться без работы
- нет радости от работы

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

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

Хоть я не искал работы целенаправленно уже около 20 лет, но я понимаю, что если бы в мою почту не приходило десяток оферов уровня CTO и архитектора каждую неделю, то уверенности бы у меня поубавилось.

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

Корень проблеми — отсутствие системного подхода и воли к глубокому изучению специальности. Можно 10 лет проработать, но так и не понять, почему плохо менять тип поля в рантайме или выражение req.user.profile.contacts.email совершенно недопустимо. Можно построить десяток API на NestJS, но так и не понять, почему middleware это плохо, всю жизнь верить, что в JavaScript нельзя сделать race condition и Node.js однопоточный.

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

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

Виталий Николаевич Брагилевский, Тимур ибн Джафар и Деми Мурыч

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

Инсайты по парадигмам, паттернам и стилям по мотивам стрима

- Код может быть и быстрым и понятным одновременно, если не доводить концептуальность и оптимизацию до фанатизма.
- Более 90% оптимизации под виртуальные машины может выполняться интуитивно, если запомнить всего несколько простых правил.
- Нет "лучшей" парадигмы программирования, и лучшего стиля, можно выбирать любую машинерию, чтобы получать желаемые характеристики кода.
- Паттерны Prototype и Proxy в GoF путаются с возможностями языка JavaScript, а паттерны Iterator и Decorator встроены в язык.
- Паттерн Strategy можно реализовать через Map<string, Function> или Map<string, Constructor> и много такого...
- Паттерн Observer породил в JavaScript сразу много: EventEmitter, EventTerget, Signals, MessagePort API, BroadcastChannel и др...
- Нужно разделять синтаксис и парадигму, может быть монада в синтаксисе класса, а может быть ООП на замыканиях.
- Паттерны готовят почву для построения архитектуры, без них код рыхлый и неуправляемый, из которого хорошей архитектуры не построить.
- Паттерны - это не теория, а практика, каждый паттерн дает типовое решение для распространенных проблем, которые встречаются везде.

Тут пример того, как на курсах я описываю парадигмы, конечно с примерами, и обсуждением, какие эффекты мы можем получить, благодаря этим характеристикам и как их комбинировать.

Императивное программирование
+ Характеристики: явные команды, циклы, ветвление, пошаговый контроль, изменяемые данные, экономия памяти, риск "гонок", повышение производительности, сложность поддержки и отладки.
+ Влияние на архитектуру: сложность масштабирования, оптимизация отклика (latency)
+ Хорошо для: системный код близкий к железу, сценарная бизнес-логика, оптимизация hot-paths.
+ Плохо для: абстракций среднего уровня, вычислений, кода с сильной конкуррентностью.
+ Синтез: императивная "оболочка" + ФП или ООП "ядро"

Конечные автоматы
+ Характеристики: явное состояние, надежные переходы, события, детерминрованное поведение (предсказуемое), декларативность моделирования.
+ Влияние на архитектуру: повышает прозрачность жизненных циклов, верификация процессов.
+ Хорошо для: моделирование воркфлоу, оркестрация, парсинг, сетевые протоколы, геймдев.
+ Плохо для: много состояний и переходов, сложные домены, "туманные" доменные модели без четких фаз.
+ Синтез: FSM на границах + сценарии/SAGA для длительных процессов.

Прототипное программирование
+ Характеристики: динамическое изменение наследования, экономия памяти, гибкость модели.
+ Влияние на архитектуру: нативная поддержка для JavaScript, высокая эффективность и гибкость, меньше ритуалов для результата.
+ Хорошо для: расширяемые платформы, Web-программирование, метапрограммирование.
+ Плохо для: для сложных доменов риск непредсказуемых состояний.
+ Синтез: прототипы для frontend и UI + строгий домен на ООП, ФП, процедурном.

По ссылке можно посмотреть примеров кода, тут 46 стилей с разными парадигмами и разными эффектами, про которые я говорил на стриме: https://github.com/HowProgrammingWorks/Paradigms

Гранулярность кода
(на скриншоте слишком мелко-гранулярный ФП код)

Общий инженерный принцип SoC (Separation of concerns) решает большую часть проблем хрупкости и понятности. SoC нравится мне гораздо больше паттерна SOLID:SRP (Single Responsibility Principle), потому что он точнее.

SRP утверждает: один класс — одна причина для изменения. Но большинство причин можно декомпозировать. А вот SoC указывает на гранулярность — мы сами выбираем уровень гранулярности. Фактически это выливается в организацию модульности, контрактное программирование, тестирование, управление зацеплением и Protected Variations по GRASP, во многом Open/Closed из SOLID.

Вчера перезаписал 2 лекции по метапрограммированию. Там про техники, позволяющие программно изменять поведение программ с использованием метаданных:
* Introspection - чтение структур и программных абстракций: типы, поля, методы, наследование и т.д.
* Reflection - динамическое изменение поведения и структуры программы.
* Scaffolding - автоматическая генерация кода/структур для ускорения разработки.
* Code Generation - программная генерация кода из метаданных.
* Macros - расширение синтаксиса языка через шаблоны или скрипты.
* Decorators - добавление к коду метаданных, влияющих на выполнение.
* Dynamic Invocation - вызов методов, функций, конструкторов и классов по имени во время исполнения.
* Monkey Patching - изменение кода в рантайме, добавлением и удалением свойств и методов.
* Generics - унификация и параметризация типов и алгоритмов если в коде изменяются только типы.
* DSL - доменно-специализируемые и встраиваемые языки для выразительности синтаксиса под задачу.
* Self-Modification - программы, изменяющие собственный код, байткод или бинарник.
* Polyfilling - вмешательство в поведение языка и платформы, перехват и подмена стандартного API.
* Homoiconic code - использование одинаковых структур для данных для исполняемого кода программы, как в LISP.

Функциональное программирование, все равно имеет дело с coupling и cohesion, с дженериками и интерфейсами, с адаптерами и фасадами. Хоть паттерны и появились в среде ООП, но они полностью пронизаны идеями из ФП, а ФП должно использовать приемы распределения ответственностьи и изоляции сложности, которые развились в ООП. Синтаксическая разница между парадигмами не так существенна, как мы уже говорили, можно делать монады на классах и инкапсуляцию на замыканиях. На самом деле, между парадигмами не так много разницы. Главное различие - это иммутабельность, но не сложно представить себе такое ООП, в котором каждый матод отображает экземпляр в новый объект. Какие еще существенные отличия? Выражения в ФП против пошагового исполнения в разных императивных стилях. Да, но это не влияет на применимость GRASP и SOLID. Работа в данными важнее способа исполнения кода. Композиция и там и там предпочтительнее, а наследования нужно избегать, хоть и там и там оно реализуется. Сокрытие и делегирование везде используются. Изоляция и расширяемость везде достигаются, да, немного разными способами, но это не так существенно. Так что, большинство принципов GRASP и SOLID вполне применимы во всех парадигмах. Более того, эти принципы работают даже в самом ужасном коде, который плох с позиции любой парадигмы. Если код выполняет то, что нужно и делает это надежно, тесты проходят не от случая к случаю, а всегда, то на каких-то принципах он же основан, пусть в нем может быть путаница в понятиях или плохая декомпозиция, чрезмерная сложность или запутанность, но базовые принципы работают даже там, где нам сложно это осознать сквозь дебри кода.

Тут пример хороших и плохих реализаций на ФП и простом императивном процедурном программировании для той же задачи, которую я публиковал на этой неделе, в слишком гранулярной реализации https://github.com/HowProgrammingWorks/Abstractions/tree/master/JavaScript

Новый набор на курс Patterns 2025!
За время второго потока мы не только обучали, но и развивали Local-first подход в оупенсорсе.

Что нового: обновленная программа, практические кейсы, реальные проекты, менторство от экспертов. Результат студентов: +30% к скорости разработки, меньше багов и переписываний, больше уверенности в результате, рост уважения и зарплаты.

Паттерны GoF (Gang of Four) — это не теория, а кирпичики, из которых вы построите надежные и удобные в поддержке программные системы. Теперь все задачи курса складываются в большой проект. Менторы делают ревью пул-реквестов и отвечают на вопросы, помогая получить комплексное понимание, такое же, как в реальном проекте.

Обзор: https://youtu.be/8a9PX12FB9s

Структура курса Patterns 2025:
- короткие лекции — быстрое и точное объяснение теории с примерами;
- длинные лекции — дополнительные материалы с глубоким погружением;
- примеры кода — применение для backend и frontend;
- семинары — еженедельные созвоны с живым обсуждением и ревью кода;
- групповая работа — разработка в малых группах с менторами;
- сквозной проект — полное от идеи до продакшена.

3 месяца (12 недель) интенсивного обучения:
- 📦 Unit 1 (1-4 неделя): Структура кода, парадигмы и модульность
- 📦 Unit 2 (5-8 неделя): Контрактное программирование и асинхронность
- 📦 Unit 3 (9-12 неделя): Среда исполнения, масштабирование и внедрение

- Менторство: консультации, ревью и разбор вашего кода, помощь в карьерном росте.
- Результат: глубокое понимание паттернов и их применения.

"Хороший код — это не тот, который работает, а тот, который понятен" /Торвальдc. Навык писать просто приходит через практику, реальные проекты, менторство, разбор кейсов и регулярные тренировки.

Обзор курса: https://youtu.be/8a9PX12FB9s