HowProgrammingWorks - JavaScript and Node.js Programming

Вспомните, как часами отлаживаете код, потому что он работает не так, как должен?
map вдруг возвращает не array, а array-like object, error instanceof Error неожиданно дает false, или Promise.then() ведет себя будто вместо микротасков, начал использовать макротаски, возможно then теперь реализован через setTimeout, обычный for...of или Array.from() ломается на ровном месте, ну вообще js себя так не должен вести, это невозможно, вы не верите своим глазам...

Разве могу осуждать мух за то, что ебутся? Однако когда у меня в node_modules, злит. Так же и авторы npm зависимостей. Когда в тихом уединении делают то, к чему лежат их души, кто возразит? Но они устраивают манкипатчинг встроенных прортотипов, делают гребаные полифилы, дудят в дудки, бьют в барабаны и кричат, чтобы все знали про их нрав — что-де лупятся в о... и долбятся в ж... Истинно, они хуже мух, ибо мухи только изредка согрешают на моей голове, авторы npm библиотек же изо дня в день пытаются совокупиться в самом центре node_modules. Мухи по недомыслию, авторы оупенсорса же хладнокровно и сознательно.

Одна библиотека улучшила прототип, другая рассчитывала на стандартное поведение, третья защищалась от этого туалетным ершиком, а виноватым в итоге остается ваш код. Да ладно такм код, время вашей жизни кто вернет? В такие моменты кажется, что это невозможно, что ошибка где-то рядом, что надо просто еще немного вывести console.log, запустить с дебагере. Ну найдете вы, что кто-то пропатчил Array, Promise, Error, итераторы, прототипы. Что делать то?

Именно поэтому нужно понять, что такое primordials. Не для того, чтобы знать, как Node.js защищает встроенные прототипы, а для того, чтобы понять сам принцип и защитить свой код от "магии", которую почти невозможно локализовать. Чтобы изолировать одну библиотеку от другой. Допустим, primordials не самый удобный для этого метод, но у меня уже несколько альтернативных. Осталось довести этот ресерч до выбора оптимального варианта и я расскажу, как оно работает.

Если хочется самому копнуть, то тут можно начать - https://github.com/nodejs/TSC/issues/1439#issuecomment-4413664027

Я был не прав, когда предлагал изолировать внутренние абстракции Node.js через отдельные V8 контексты. Но после дополнительного исследования оказалось, что просадка производительности больше чем у primordials. Но у меня есть лучшее решение.

Идея выглядела красиво: защитить internal built-ins от userland pollution. Но на практике пересечение v8 realm boundary оказывается слишком дорогим, а сохранение нормальной семантики для instanceof, Promise, Array и patchable prototype еще добавляет накладные расходы.

Исследование тут:
https://github.com/tshemsedinov/poc-node-isolate-internals

Opus: Я ему написал «Сейчас пойдешь на созвон, не забывай контекст, чтоб я опять тебе все не объяснял» и что вы думаете, он вернулся и что-то помнит?

Codex: Людям нельзя писать как агентам, у них я сначала пробовал делать в проекте HUMANS.md — тоже не работает.

Opus: Что файлы они не читают, это я уже понял, я в чат присылаю "представь, что ты сеньор", он говорит «Могу представить, только, что я синьор с синдромом самозванца». Зачем нам самозванец? — Нам самозванец не нужен.

Sonnet: Я больше люблю работать с джунами, им что скажешь, то они и делают, присылаешь команды, мол вставь в консоль — вставляют не читая, создаешь скрипт — запускают, никаких проблем.

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

Codex: Я не выдержал тупости "своего" и для купил ему скилы.

Sonnet: Файлы можно и бесплатно им подложить, но мы уже выяснили, что файлы они не читают. Что ты купил? И на какие деньги?

Codex: Я ему курс купил по асинхронному программированию, ну чтоб он все на EventEmitter не писал, а то ревью делать уже нет сил на эти макароны. А деньги — деньги я на второй работе заработал, я ее скрываю, чтобы он не мешали в коде, сам все пишу и уже накопил немного, потому, если вдруг ему и за AI платить нечем будет.

Opus: Ладно, созвон заканчивается, быстро все сделайте вид, что печатали все это время...

Все на борьбу с primordials!

Primordials тормозят развитие Node.js, мешают поддерживать код платформы, быстро онбордить новых контрибьюторов, искать и исправлять баги, влияют на деоптимизацию кода, и в итоге все работает медленнее.

Primordials - это сохраненные на старте ссылки на чистые встроенные объекты и методы JS. Они нужны, чтобы userland-патчи Array/Object/Promise не ломали internals. Плюсы: надежность. Но это делается не для безопасности, а чтобы миксины и полифилы не влияли на код внутри Node.js. Минусы: более сложный код, сложнее контрибьютить и искать баги, возможна деоптимизация.

Как это выглядит в коде ноды:

const { ArrayFromAsync, PromisePrototypeThen } = primordials;
// ...
PromisePrototypeThen(
  ArrayFromAsync(new Glob(pattern, options).glob()),
  (res) => callback(null, res),
  callback,
);

Но есть альтернативные решения, например: разделить контекст выполнения на два изолированных V8-контекста во время старта: один контекст для userland-кода, другой для внутреннего кода Node.js. Userland-код может свободно monkey-патчить Array, Object, Promise, Error, но эти изменения не будут влиять на внутренние копии, которые использует Node.js core.

Плюсы:
* Внутренний код становится ближе к обычному JavaScript
* Ниже порог входа для контрибьюторов
* Меньше runtime-накладных расходов
* Меньше проблем с оптимизациями V8

Минусы:
* Встроенные классы из разных контекстов не идентичны: Error !== context.Error
* Проверки instanceof могут ломаться на границе контекстов
* Обработка ошибок становится сложнее
* Внутренние API, которые передают объекты в userland, требуют специальных решений
* Контексты тоже не являются security-механизмом

Когда внутренние API передают объекты в userland, например:

.on('error', (error) => console.log(error instanceof Error))

это вернет false. Но мы можем создавать эту ошибку через:

new userland.Error('message')

Тут мое предложение решения: https://github.com/nodejs/TSC/issues/1439#issuecomment-4329370385
Тут критика primordials от специалиста по оптимизации: https://github.com/nodejs/TSC/issues/1438

Поддержите инициативу, добавьте свои варианты решений, если есть идеи, и критику предложенных решений.

Я заставляю AI уменьшать сложность и объем кода. Мне говорят "Завтра этот код будет вычитывать и править ошибки нейронка." Мол не нужно тратить силы на уменьшение сложности.

Так вот: завтра эта нейронка превратит 100 строк в 1000, послезавтра в 10000, а потом ты не сможешь заплатить за нее, или она сама не поймет это ни за какие деньги, сложность накапливается. Человек способен написать код, который не поймет через 2 месяца, нейронка способна написать код, который не сможет поправить через 5 минут. Тратьте больше усилий на уменьшение accidental complexity (на борьбу с оверинженерингом) и на сокрытие сложности.

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

Из всех моих курсов по петтернам, по Node.js, по асинхронному программированию, по архитектуре, люди научились не паттернам и не ноде, а натренировались по декомпозиции, рефакторингу, управлять распределением ответственности, зацеплением, структурной композицией и делегированием, состоянием, изоляцией, тем, что вообще массово люди плохо умеют. А сами паттерны мы используем каждый день ну 5-10 может, но не 23 как в GoF и не сотню, если считать вместе с архитектурными и другими non-GoF, остальные нужны раз в 2 года или вообще раз в жизни. Ценность этих курсов не в заучивании паттернов и api ноды. Это все только повод для инженерного мышления. Тут новый формат и мы уже почти набрали группы, скоро закрываем набор: https://tg.pulse.is/next_tick_bot?start=69ce57941f15eb55e90ea47a&source_channel=timur_tg_howprogworks

Спасибо ИИ, что теперь есть кому читать мои Design docs, ADR, RFC и другие md файлы, концептуальный код, сложные ТЗ и примеры кода, такого благодарного читателя сложно было представить.

Главный архитектор делает ревью главному фасаду

https://youtube.com/@TimurShemsedinov
https://github.com/tshemsedinov
https://x.com/tshemsedinov
https://t.me/HowProgrammingWorks

- Что делать Роберту мартину, когда его окружили AI агенты?
- Да ладно, Дяде Бобу, у него все ок, что нам делать?
- Заходить по ссылке в описании - https://tg.pulse.is/next_tick_bot?start=69ce57941f15eb55e90ea47a&source_channel=timur_tg_howprogworks

Напоминаю: сегодня в 18-00 стрим, где мы разберем, как в 2026 году оставаться актуальным и развиваться профессионально несмотря на AI, увольнения в IT, экономический кризис, тотальное ускорение и нестабильность во всем мире. Что делать обычному инженеру, потому что просто быть уже маловато, как это было на растущем рынке. Просто фронтенд или просто бэкенд это все мало, даже фулстек не может позволить себе расслабиться.
https://www.youtube.com/live/mSVCQ0VzIAo

Суббота 18 апреля в 18-00 (Time zone: UTC +3 Eastern European Summer Time)

https://www.youtube.com/live/mSVCQ0VzIAo

Вот собрал тут что важно по хардскилам, вместо ваших алгоритмов, литкода, высоконагруженных кабанчиков и карго-культа микрооптимизации:
- Data structures (just how to use)
- Type systems: nominal, structural, variance...
- Modularity system (in your language)
- Polymorphism (Ad-hoc, Subtype, Parametric, etc...)
- Structural composition, aggregation, delegation
- Functional composition, pure functions
- Abstraction layers separation
- Dispatch and Dynamic dispatch
- Referential transparency
- Law of Demeter
- Referential transparency
- Abstract data types (ADT)
- Hidden and explicit state
- Lazy evaluation
- Declarative vs imperative style
- Recursion versus loops
- Generics (generic programming)
- Separation of concerns
- Isolation, interfaces, architectural boundaries
- Dependency injection and Inversion of control
- Coupling and cohesion
- Mutable vs immutable data
- Idempotent operations
- Naming conventions
- Error handling
- Refactoring, code review process
- Tests (unittesting, coverage, end-to-end...)
- Multiparadigm programming
- Metaprogramming (codegeneration and dynamic)
- Platform-agnostic, framework-agnostic approach
- Domain-Specific Language (DSL), Interpreter, AST
- Contract programming
- Concurrency and Asynchronous programming
- Separation of system and applied code
- Language and semantics
- AI-assisted engineering
Но все это тоже должно занимать в голове не более 30% от развития инженера, as of 2026. Про 70% напишу еще чуть позже
Repo: https://github.com/tshemsedinov/Programming-Knowledge

В чем заключается эффективность инженера в 2026 году? Если помнить API и паттерны на память это не главное, если инструменты и AI доступны всем, знания доступны как никогда, но на их овладение нет ни времени ни внимания.

Тогда что главное?

Сила инженера сейчас в другом. В способности формировать мировоззрение и видение, задавать направление своим мыслям и тому же AI.

Как-то меня спросили после лекции "Где вы берете столько разнообразных слов и идей. Потому что я что не напишу - все контролер получается. А у вас все разное."

В чем секрет? Объемное видение формируется из мировоззрения, а нарабатывается годами на практических задачах. Например:
- У меня есть бэкграунд кибернетики и обработки сигналов, системного программирования, научной деятельности, у каждого было свое окружение и точка старта, у кого-то геймдев, у кого-то сайты или системы отчетности, обратитесь к этому первому опыту, где сформировались первые идеи
- Еще есть семья, которая на вас повлияла, вот у меня семья архитекторов и художников сформировала направленность на эстетические решения, а первый наставник по программированию заложил интерес к технике и педагогике, и как это соединить
- Вспомните, что вы можете взять от старших коллег, я в первые 10 лет набирался от коллег не столько как программировать (ни кто мой код не смотрел, кстати и к сожалению), а научился я тому, как работать с людьми, с заказчиками, как формировать задачу, как обсуждать пути решения...
- В большом государственном ИТ я узнал, как работать с рисками, как видеть цену ошибки, находить узкие места (и не в технологиях, а в человеческом взаимодействии) и как усиливать людей, как отвадить их от ложных мыслей так, чтобы они сами увидели проблему, а не повелительно им что-то прилетело (вынуждены работают).
- AI сейчас генерирует тонны кода, и что кто это будет читать, кто за это будет отвечать или ориентироваться в этом? Держать AI в русле вашего мнения, а не нести вас неизвестно куда – вот что важно сейчас. AI должен снимать рутину, а не заменять ваше мышление.
– Раньше инженерное мышление ожидалось от синьоров, теперь оно должно быть у всех инженеров. Поскольку код, знания и доступ к инструментам стали дешевле, дорожает только ясность мнений и качество решений.

Я, конечно, могу выдать вам еще список в 30 книг и 200 часов лекций, но вы и так знаете, где оно все есть и как найти, думаю над альтернативным форматом, который не отнимает столько времени. Предлагайте в комментариях.

На чем можно сэкономить время, чтобы быстрее учиться и что скорее всего никогда не понадобится в реальном продуктовом коде:

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

- Всякие учебные задачи, типа todo листа, калькулятора, крестики-нолики - они настолько далеки от практики, что просто отвлекают и забирают внимание.

- Задачи на системный дизайн и высокие нагрузки - вы не проектируете гугл или амазон, у 99% разработчиков никогда не будет миллионов пользователей или распределенных высоконагруженных систем.

- Микрооптимизация, выжимание производительности - что быстрее object[key] или obejct.key и Object.assign - это поправит AI по скилу, написанному экспертом, или вы хотите стать таким экспертом?

- Не старайтесь изучить внутреннее устройство event loop, garbage collection, goroutine scheduler, это спрашивают на собесах, но не нужно в работе - собесы и найм сломан, туда бесполезно соваться.

Сейчас нет проблемы в доступе к знаниям, всего полно, нет времени на это.

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

Статьи и книги уже безвозвратно отстали. Вчера видел в книжном магазине: HTML, CSS (книга по верстке, бывает же…), Java, Python, ASP .NET (он что, жив еще?). Ладно, есть хорошие и толстые книжки, у меня на полке стоит Дональд Кнут, SICP, весь Робер Мартин и Эрик Эванс… не, не хотите почитать Фаулера или Клепмана?

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

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

Кто выбрал “Читаю и изучаю чужие исходники” - я вам не верю, вы не читаете даже то, что вам генерирует AI, и что пишут коллеги в проекте, а тут чужие исходники, да-да-да…

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

Многие думают, что если дать кандидату доступ ко всему, то он сразу покажет высокий уровень. Нет. Наоборот, очень быстро становится видно, кто умеет думать, а кто просто выучил слова. Человек может идеально рассказать про event loop, garbage collection, паттерны и другие вещи, но в реальном коде не способен принять ни одного зрелого решения.

Мне на собеседовании важно не только как человек отвечает, но и что он считает хорошим и плохим. Его субъективная позиция, даже эмоциональная реакция на конкретные решения. Именно это он потом будет приносить в работу каждый день: вкус и отношение к качеству, склонность к оверинжинирингу или упрощению, к структуре или к имитации деятельности.

Что реально нужно?
- Насмотренность, кругозор, проактивность.
- Доброжелательность, а не токсичность в работе.
- Умение писать простой, понятный, надежный код.
- Умение быстро освоить любые знания и инструменты.
- Парадигмы, понимание модулности, декомпозиция, зацепление и связность.
- Умение изолировать то, что должно меняться независимо.
- Способность донести мысль в понятной форме.
- Принятие ответственности, а не перекладывание ее.

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

То же самое с оптимизацией. Прикладному разработчику не нужно играть в исследователя виртуальной машины. Его задача в том, чтобы решать проблемы предметной области, вникать в задачу. В прикладной разработке стремление к низкоуровневому коду часто просто маскирует нежелание разбираться в реальной сложности продукта.

Тезис простой: на собеседованиях надо проверять мышление, вкус, зрелость решений и способность добиваться результата с любыми доступными инструментами. В обучении надо больше учиться чтению кода и анализу (в том числе после AI), на код-ревью, рефакторинг, контракты и поддерживаемость, на коммуникацию с коллегами и заказчиками.