HowProgrammingWorks - JavaScript and Node.js Programming

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

Что задерживает разработку и как? Куда уходит время, которое можно было бы потратить на новые фичи? - 🐢 долгое согласование — вопросы или задачи сформулированы так, что люди подсознательно их игнорируют, уходят от ответа, не отвечают на сообщения, не приходят на созвоны; процесс принятия решений затягивается. - 🔗 высокое зацепление — части программы слишком тесно связаны: много обращений к чужим свойствам и методам, из-за чего изменения в одном месте ломают другое, и модули невозможно исправлять независимо. - 🤯 недооценка сложности — задача кажется простой, но в процессе реализации выясняется, что есть скрытые зависимости, то же зацепление, обновление зависимостей, исключения и дополнительные условия. - 🔥 тушение пожара — вместо планомерной работы, новой функциональности, приходится срочно чинить критические баги или решать кризисные ситуации, у пользователей работа встала, теряем клиентов, разрушаются данные. - 🧩 нет типовых решений — похожие задачи есть всегда, но для них не всегда подготовлены типовые решения, каждый раз разработчик выделяет решение из сторого кода, нет единого переиспользуемого подхода. - 📦 плохая декомпозиция — код разделен на модули не по смыслу и не по зацеплению, а по непонятному признаку, слишком крупно или нелогично; "ось изменений" проходит по нескольким классам или модулям. - 🙈 непонятный код — сложно читается, не подходящая гранулярность (слишком мелкие или крупные части); именование даже не намекает на что-то известное; оверинжиниринг: использованы лишние абстракции, паттерны, слои. - ⚖️ противоречивые требования — разные руководители и представители заказчика присылают разные противоречивые требования или команды хотят разное, требования конфликтуют между собой или даже противоречивы внутри. - 🛑 ручные процессы — отсутствие автоматизации: нет или мало тестов, ручной деплой, воспроизведение багов делаются вручную, не соблюдается 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

⚡️ Предварительная регистрация на интенсив: Превращение существующего проекта в «local-first» 1. Обзор основных отличий подхода «local-first» 2. Практическое руководство: Как быстро создать PWA «local-first» из существующего приложения 3. Анализ кода: как добавлять новые сущности, операции, бизнес-логику 👉 Регистрация на мастер-класс по local-first https://forms.gle/ENXGB84bRY4fCiYZ8

Если еще не посмотрели - смотрим запись стрима https://youtube.com/live/cSWOOVh7xkU

Тем, кто накручивает опыт: когда у вас слишком много опыта, то это становится проблемой. Сколько знаю людей с 20-30 лет опыта, то вы в каждой задаче видите столько подводных камней и в каждом проекте столько сложностей, что разработка становится очень проблематичной. Но открутить опыт, который вы накрутили гораздо сложнее...

Конкурс для получения 2 мест на один из моих курсов 1 место может выиграть любой человек, а второе только один из выпускников https://github.com/tshemsedinov/code-with-ai-contest