Так выгладит окно, установленного в 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

Отзывы выпускников курса по Patterns

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

Дейкстра говорил: "Программирование – это искусство, а не наука". Но искусство требует мастерства, а мастерство – понимание принципов. Паттерны – это не магия, а проверенные решения архитектурных проблем. Но со стороны это выглядит как магия. "Любая достаточно развитая технология не отличается от магии" // Артур Кларк.

Результаты студентов: как меняется эффективность и скорость разработки уже через 3 месяца примерно на треть, становится меньше багов и переписывания, больше уверенности в решениях, рост зарплат и статуса. В течение года после прохождения курса, если практиковаться и внедряться в живых проектах, эффективность вырастет в 2-3 раза. Вы будете писать меньше и за меньшее время, а толку от этого для бизнеса будет гораздо больше.

Посмотреть видео-отзывы на сайте: https://nodeua.com/Patterns-2025

Если вам дорого — то курс Patterns не для вас. Это курс минимум для практикующих Middle-Senior разработчиков или того, кто уже вплотную подходит к этому уровню. А зарплата Senior вполне позволяет делать инвестицию в свое будущее — окупаемость 2-3 месяца. Бесплатные альтернативы есть, но они не адаптированы для современного JavaScript и TypeScript мира, для frontend и backend разработки на Node.js и Web API.

Аналогов этому курсу нет, все материалы не просто взяты из книжек Банды четырех, Крэга Лармана, Роберта Мартина, Эрика Эванса, Эриха Гамма, Ричард Хелма, Ральфа Джонсона, Джона Влиссидеса, Эдсгера Дейкстры, Гради Буча и других. Все эти знания пропущены через многолетнюю практику автора и менторов и поданы в формате, понятном современному разработчику.

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

Если у вас "нет времени", то откуда вы находите время, чтобы отлаживать в дебагере по ночам и краснеть на созвонах? Курс адаптирован под рабочий график, можно проходить в спокойном темпе, менторы помогают с планированием, результат стоит потраченного времени.

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

Почему-то фронтенд разработчики убеждены, что паттерны нужны только для бизнес-логики, а вся она находится на сервере и в базе данных, а у нас в UI все иначе устроено. Для тех, кто не верит в то, что доменная-логика таки существует и должна быть изолирована от UI, от сети и от инфраструктурного кода, я публикую вчерашний семинар, где отвечаю на вопросы тех, кто уже зашел на курс Patterns.
https://youtu.be/bfw101W5Xf4