HowProgrammingWorks - JavaScript and Node.js Programming

Отзывы выпускников курса по Patterns Как создавать контракты и архитектуру, работать с менторами и как разрозненные пазлы складываются в общую картину. О получении персонального фидбека, расширении мировоззрения, новой мотивации и повышении эффективности в работе. Студенты сравнивают с другими курсами, рассказывают об изменениях в общении с заказчиками, коллегами и руководством. Раскрыта ценность курса для фронтенда и бэкенда, применения различных отраслей разработки и для разных уровней подготовки на входе, выпускники описывают практическую ценность в проектах. Дейкстра говорил: "Программирование – это искусство, а не наука". Но искусство требует мастерства, а мастерство – понимание принципов. Паттерны – это не магия, а проверенные решения архитектурных проблем. Но со стороны это выглядит как магия. "Любая достаточно развитая технология не отличается от магии" // Артур Кларк. Результаты студентов: как меняется эффективность и скорость разработки уже через 3 месяца примерно на треть, становится меньше багов и переписывания, больше уверенности в решениях, рост зарплат и статуса. В течение года после прохождения курса, если практиковаться и внедряться в живых проектах, эффективность вырастет в 2-3 раза. Вы будете писать меньше и за меньшее время, а толку от этого для бизнеса будет гораздо больше. Посмотреть видео-отзывы на сайте: https://nodeua.com/Patterns-2025

Структура курса Patterns 2025: - короткие лекции — быстрое и точное объяснение теории с примерами; - длинные лекции — дополнительные материалы с глубоким погружением; - примеры кода — применение для backend и frontend; - семинары — еженедельные созвоны с живым обсуждением и ревью кода; - групповая работа — разработка в малых группах с менторами; - сквозной проект — полное от идеи до продакшена. 3 месяца (12 недель) интенсивного обучения: - 📦 Unit 1 (1-4 неделя): Структура кода, парадигмы и модульность - 📦 Unit 2 (5-8 неделя): Контрактное программирование и асинхронность - 📦 Unit 3 (9-12 неделя): Среда исполнения, масштабирование и внедрение - Менторство: консультации, ревью и разбор вашего кода, помощь в карьерном росте. - Результат: глубокое понимание паттернов и их применения. "Хороший код — это не тот, который работает, а тот, который понятен" /Торвальдc. Навык писать просто приходит через практику, реальные проекты, менторство, разбор кейсов и регулярные тренировки. Обзор курса: https://youtu.be/8a9PX12FB9s

Новый набор на курс Patterns 2025! За время второго потока мы не только обучали, но и развивали Local-first подход в оупенсорсе. Что нового: обновленная программа, практические кейсы, реальные проекты, менторство от экспертов. Результат студентов: +30% к скорости разработки, меньше багов и переписываний, больше уверенности в результате, рост уважения и зарплаты. Паттерны GoF (Gang of Four) — это не теория, а кирпичики, из которых вы построите надежные и удобные в поддержке программные системы. Теперь все задачи курса складываются в большой проект. Менторы делают ревью пул-реквестов и отвечают на вопросы, помогая получить комплексное понимание, такое же, как в реальном проекте. Обзор: https://youtu.be/8a9PX12FB9s

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

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

Гранулярность кода (на скриншоте слишком мелко-гранулярный ФП код) Общий инженерный принцип SoC (Separation of concerns) решает большую часть проблем хрупкости и понятности. SoC нравится мне гораздо больше паттерна SOLID:SRP (Single Responsibility Principle), потому что он точнее. SRP утверждает: один класс — одна причина для изменения. Но большинство причин можно декомпозировать. А вот SoC указывает на гранулярность — мы сами выбираем уровень гранулярности. Фактически это выливается в организацию модульности, контрактное программирование, тестирование, управление зацеплением и Protected Variations по GRASP, во многом Open/Closed из SOLID.

Тут пример того, как на курсах я описываю парадигмы, конечно с примерами, и обсуждением, какие эффекты мы можем получить, благодаря этим характеристикам и как их комбинировать. Императивное программирование + Характеристики: явные команды, циклы, ветвление, пошаговый контроль, изменяемые данные, экономия памяти, риск "гонок", повышение производительности, сложность поддержки и отладки. + Влияние на архитектуру: сложность масштабирования, оптимизация отклика (latency) + Хорошо для: системный код близкий к железу, сценарная бизнес-логика, оптимизация hot-paths. + Плохо для: абстракций среднего уровня, вычислений, кода с сильной конкуррентностью. + Синтез: императивная "оболочка" + ФП или ООП "ядро" Конечные автоматы + Характеристики: явное состояние, надежные переходы, события, детерминрованное поведение (предсказуемое), декларативность моделирования. + Влияние на архитектуру: повышает прозрачность жизненных циклов, верификация процессов. + Хорошо для: моделирование воркфлоу, оркестрация, парсинг, сетевые протоколы, геймдев. + Плохо для: много состояний и переходов, сложные домены, "туманные" доменные модели без четких фаз. + Синтез: FSM на границах + сценарии/SAGA для длительных процессов. Прототипное программирование + Характеристики: динамическое изменение наследования, экономия памяти, гибкость модели. + Влияние на архитектуру: нативная поддержка для JavaScript, высокая эффективность и гибкость, меньше ритуалов для результата. + Хорошо для: расширяемые платформы, Web-программирование, метапрограммирование. + Плохо для: для сложных доменов риск непредсказуемых состояний. + Синтез: прототипы для frontend и UI + строгий домен на ООП, ФП, процедурном. По ссылке можно посмотреть примеров кода, тут 46 стилей с разными парадигмами и разными эффектами, про которые я говорил на стриме: https://github.com/HowProgrammingWorks/Paradigms

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

Сегодня мы обсудим парадигмы программирования, различия и связь между ними, их реальное влияние на наш код каждый день, войны парадигм, концептуальный экстимизм, синтаксические и семантические особенности, а также эффекты, которые ими достигаются. Виталий Николаевич Брагилевский, Тимур ибн Джафар и Деми Мурыч https://www.youtube.com/watch?v=ES2NPqlDnek

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

Вы все время пилите окошки, апишки и модельки? Ничего по настоящему интересного и сложного? Кому-то это подходит, а вы чувствуете себя некомфортно. Что это, застой, выгорание? Признаки кризиса: - в почте нет предложений о работе, не зовут на собесы - вы не едите в карьерном лифте и ЗП не растет - страшно уволиться, остаться без работы - нет радости от работы На самом деле, и выгорания то не существует — это миф, такое состояние безвыходности вы сами себе обеспечили и убедили себя, что работа бессмысленна, но не в работе проблема. Если заапгрейдить себя, то вы или работу почините или уйдете на нормальную. Когда вы чувствуете деградацию, первое, что нужно исправить, это самоуважение, а тут без наращивания хард-скиллов никак. Если вы профессионал и любите свою работу, то никакого застоя и выгорания не будет. А если нет экспертизы, тут не с выгоранием нужно бороться, а наращивать знания и опыт. Хоть я не искал работы целенаправленно уже около 20 лет, но я понимаю, что если бы в мою почту не приходило десяток оферов уровня CTO и архитектора каждую неделю, то уверенности бы у меня поубавилось.

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

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

Код не стоит ничего! Ценно владение кодом, а владение — это не авторские права, а возможность внести в код изменения в предсказуемые сроки. Изменять код без страха, что он рассыпется в руках, и понимание, как он работает, — не так просто. Для надежного владения нужно перекрестное владение кодом нескольких разработчиков, которые чувствуют код, помнят, где что находится, и, получая задачу на фичу, могут выдать эстимейт и придерживаться его с разумной погрешностью. Если нет владения кодом, то нет продукта. Непредсказуемый код ничего не стоит и только тянет компанию на дно. Но проблема не только в коде — владение это процесс. Если ревью тянется неделями, каждое изменение рождает новые баги, как снежный ком — это системная проблема: отсутствие владения кодом, а скорее всего, и инженерной культуры. Как следствие — ужасная кодовая база. Как она стала такой — вы знаете. А что делать? Вместо переписываний нужен рефакторинг, покрытие тестами, понижение зацепления, внедрение практик перекрестного ревью, работа малыми правками, никаких незакоммиченных изменений, оставленных на завтра. Не подгонять тесты под код, а исправлять код до тех пор, пока он не пройдет тесты. Изменения должны стать предсказуемыми, малыми и атомарными. 👉 https://youtu.be/klqyAb5owCY

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

🧩 Обновлен пример проекта PWA https://github.com/HowProgrammingWorks/PWA ⭐️ Кроме функциональности, которая была раньше - Чат на websocket (node.js + web application) - Service worker и PWA с прокси и кешом статики - Работа в online и в offline mode ⭐️ Реализованы еще: - Реакции на сообщения со счетчиками - Синхронизация с использованием CRDT - Рефакторинг: лучше структура кода - Добавлены задачи для тренировки паттернов - Задачи по разделению UI и Domain кода 🖼 Если Вы хотите увидеть решение задач, это будет в сообществе: https://www.patreon.com/tshemsedinov/membership

Сегодня Деми Мурыч с Виталием Брагилевским Виталий Николаевич Брагилевский: В прошлом член двух комитетов языка Haskell Более 20 лет опыта преподавания Автор книжки haskell in depth Участник десятка конференций Волшебник из НИИЧаВо Ну а Мурыча вы знаете https://www.youtube.com/watch?v=iQ_PRQPBEgQ