HowProgrammingWorks - JavaScript and Node.js Programming

Инсайты по парадигмам, паттернам и стилям по мотивам стрима - Код может быть и быстрым и понятным одновременно, если не доводить концептуальность и оптимизацию до фанатизма. - Более 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

Все библиотеки Metarhia обновлены, ни одна из них не была заражена во время сентябрьских атак на NPM. 👉 https://github.com/metarhia/Docs ℹ️ Официально: Metarhia не имеет ни малейшего отношения к этим атакам

Самораспространяющийся вирус заразил более 180 пакетов npm, и тырит учетные данные https://thehackernews.com/2025/09/40-npm-packages-compromised-in-supply.html

AI научился говорить "ну шо там?" и теперь может делать 98% работы менеджмента

Кто там кричит «AI заменит программистов»? Тут в github тысячи issues есть в самых популярных репозиториях. Когда вы их собираетесь закрывать с помощью AI? Node.js 1.7k, Next.js 2.3k, TypeScript 5k, React 811, Redis 2.2k, Angular 1.2k, Go 5k, Deno 2.3k, Rust 5k, Kubernetes 1.9k Я вот делаю 1 раза в неделю лайвкод с парным программированием на AI: Cursor, Copilot, Claude code и т.д. https://www.patreon.com/cw/tshemsedinov

Программисты пугают, друг-друга, что их заменит AI, но почему такого не происходит в IT менеджменте? Ведь составлять наполеоновские планы и писать таски AI умеет лучше, они даже не должны запускаться, могут быть сколь угодно противоречивыми и туманными...

👩‍💻 @demimurych ходил на интервью к Макевнину, объяснял за перепменные... и вот опять - https://x.com/tshemsedinov/status/1960228555293376839

Конкурс «Code with AI» Призы: 2 места на один из моих курсов: - Architecture 2025 - Async 2025 for JS/TS - Patterns 2025 for JS/TS - Node.js 2024 Задача: https://github.com/tshemsedinov/code-with-ai-contest