HowProgrammingWorks - JavaScript and Node.js Programming

✅ План стримов по паттернам: 08 августа - четверг - ITBeard 09 августа - пятница - Деми Мурыч 10 августа - суббота - Илья Климов

🙊 The Law of Demeter (LoD): Don’t talk to strangers If you see something like this: 👉 connection.parent.service.storage.db.saveRecord 👉 this.action.scenario.bot.telegram.sendMessage 👉 service.find('logger').kind('error').stream.write You have technical debt! It's time to plan refactoring. Each entity (unit/instance) should have only limited knowledge about others (only "closely" related to the current one). Each entity should only talk to its friends (immediate friends): don’t talk to strangers! Вut don't do it in a panic and do not mix refactoring with other issues (like new features implementation). Just note that and plan resource allocation.

Почему нужно избегать union-тайпов? 1. Каждый раз, когда юнион куда-то приходит аргументом, нужно делать if, чтобы понимать, как с ним работать, кроме случая, когда все классы/типы, входящие в юнион имплементируют один и тот же интерфейс и нас интересует обращение именно через этот интерфейс, зачем тогда юнион, используйте этот интерфейс вместо него, ну если в юнион не входит undefined, null, unknown и т.д. 2. Юнионы приводят к мегаморфной форме обращения к объектам в V8, и это замедляет код, не сметртельно, но это неприятно и проще всего всего забыть их. Но для чего же они тогда вообще нужны? Для совместимости с JS, если в нем можно передать что-угодно аргуметом, то это нужно меть возможность как-то выразить. Это не значит, что это хорошо и так нужно писать кода, это добавили как возможность, а не как обязанность ) 3. Это часто ведет к нарушению SOLID:SRP (принципа единственной ответственности), потому, что как может метод, например, получать сокеты или таймеры на выбор и делать разные вещи в зависимости от этого, это же маразм, нарушает SOLID:LSP (принцип подстановки), иногда нарушает GRASP:InformationExpert, явно повышает Coupling. Вместо этого нужно всегда использовать маленькие интерфейсы, заточенные под узкую задачу, помним про SOLID:ISP (принцип разделения интерфейсов) и могут быть optional аргументы, для этого не нужно делать union с null.

Sync and async code

Программирование, как и любая человеческая деятельность насквозь мифологично, более того, мы решительно ни о чем не можем поговорить, чтобы не опереться на тот или иной миф, то у нас Node.js однопоточный (хоть никогда не был), то мы говорим о нетипизированном языке программирования (хоть таких не бывает), то переменные иммутабельные (хоть это оксюморон), то микросервисы ускоряют ответ (хоть могут только замедлять), и даже, если мы понимаем неточность терминов, и пытаемся говорить точнее, то рассказ растягивается на бесконечность, потому, что все нужно уточнять, а уточнения тоже уточнять, и к каждому факту в уточнениях можно придраться и оспорить. Так что, быстро общаться можно, но только понимая друг друга между строк. Выйти за рамки мифа можно, но только создавая новый миф. Ошибки исправить можно, но только делая новые и новые ошибки. Да и учиться сразу правильно не выйдет, мы осваиваем частично ложные знания еще и плохо осваиваем, сталкиваемся с опытом и благодаря ошибкам, можем делать следующий шаг.

🧩 Пока я готовлю курс по паттернам GoF, SOLID, GRASP с адаптацией для Node.js и JavaScript, собрал тут ссылки на все старые материалы, видео, примеры кода, задачи, если по ссылке github репозиторий, то часто там и примеры и видео: https://github.com/tshemsedinov/Patterns-JavaScript

Если кто хочет лучше понять о чем был ШОК-контент про конец TypeScript: тут лекция в академическом виде, без стеба https://youtu.be/9JUY3prnCQ4

💡 Начиная Chrome 119 и Node.js 22 у нас есть Promise.withResolvers(); Для чего оно нужно? Представьте, что у нас есть какое-то callback-returning API или EventEmitter/EventTarget или другие абстракции, поведения которых нужно подождать. И вот нужно сделать адаптер, обертку с внешним Promise-returning интерфейсом. Пример:

const sumAsync = (a, b, callback) => {
  if (typeof a !== 'number') return;
  if (typeof b !== 'number') return;
  setImmediate(() => {
    callback(a + b);
  });
};

Раньше это могло выглядеть так:

let resolve, reject;
const promise = new Promise((resolved, rejected) => {
  resolve = resolved;
  reject = rejected;
});
setTimeout(reject, 1000, new Error('Timed out'));
sumAsync(2, 3, resolve);
const result = await promise;
console.log({ result });

Или так:

const promise = new Promise((resolve, reject) => {
  sumAsync(4, 5, resolve);
  setTimeout(reject, 1000, new Error('Timed out'));
});
const result = await promise;
console.log({ result });

Но теперь withResolvers позволяют это написать проще

const { promise, resolve, reject } = Promise.withResolvers();
setTimeout(reject, 1000, new Error('Timed out'));
sumAsync(6, 7, resolve);
const result = await promise;
console.log({ result });

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

💥 Шок! Названа возможная дата КОНЦА Node.js, JavaScript и С++, эксперты раскрыли тайну TypeScript ☠️ https://youtu.be/bRlUtzQPOhA Скандал в твиттере, все, что вы знали про программирование — скоро не будет стоить ничего!!! Когда наш CTO узнал это, то он три раза сбросился с унитаза и съел свою копию "Книжки с кабанчиком". Но я вас полюбил и я вас научу — тут статья «Самые важные знания для программиста» https://x.com/tshemsedinov/status/1809633457754034433

🧩 Паттерн Adapter может быть реализован в JavaScript множеством разных способов, на примерах для Node.js и браузеров. Все они имеют одну главную идею - обертка абстракции и связывание обернутого интерфейса с внешним. Но для враперы для реализации адаптера можно делать на базе разных идей: - Расширение адаптирруемого класса при помощи extends - Боксирование адаптирруемого класса или функции - Обертка адаптирруемого класса или функции в замыкание - Использование композиции для боксинга адаптирруемого класса - Использование аггрегации для боксинга адаптирруемого класса - Реализаци обертки как широко известного контракта или интерфейса - Применение открытого конструктора вместо наследования Я думаю, что из примеров кода это проще понять, чем из текста, но после кода все же хорошо вернуься к обобщению. Примеры кода тут: https://github.com/HowProgrammingWorks/Adapter

Считаю плохой идеей учиться программированию на базе: 🙅🏻 Алгоритмы - они уже давно есть готовые в языках и платформах, менее 1% программистов будут их реализовывать в работе, а если будут, то их нужно за это наказывать. Вот что действительно нужно, так это краткий обзор алгоритмов и использование структур данных, именно с упором на применение, а не разработку. 🙅🏻 leetcode и аналоги - это задачи которые не должны встречаться в жизни никогда, 🙅🏻 Олимпиадное программирование - это простыни быстрого, нечитаемого кода, условия такие, пишем быстро и write-only, к чему хорошему это может привести? 🙅🏻 System design и highload - большинство людей пишут системы совсем не для миллионов пользователей, а те, кто пишут для миллионов, могут просто посмеяться, как эту тему любят обсуждать на собеседованиях, на курсах, в свободное время между программистами, об этом приятно мечтать, да... но люди пишут на работе обычно апишки, модельки, формочки, бизнес-логику и интеграции. Мы не говорим про 100% людей, но массово именно так. 🙅🏻 Треш-головоломки, типа как сделать await [promise1, promise2] - я сам их использую но это только для привлечения внимания, они реально возбуждают фантазии программистов, но я всегда делаю оговорку, что так писать нельзя и даже такую задачу ставить нельзя.

💡 На кого можно подписаться в Github: 1. Маттео Калина https://github.com/mcollina 2. Джеймс Снелл https://github.com/jasnell 3. Ден Абрамов https://github.com/gaearon 4. Анна Хеннингсен https://github.com/addaleax 5. Рик Тротт https://github.com/Trott 6. Илья Климов https://github.com/xanf 7. Андрей Ситник https://github.com/ai 8. Федор Индутный https://github.com/indutny 9. Линус Торвальдс https://github.com/torvalds 10. Дуглас Крокфорд https://github.com/douglascrockford 11. Брендон Эйх https://github.com/BrendanEich 12. Андерс Хейлсберг https://github.com/ahejlsberg 🖼 А тут еще профили контрибьторов, менторов и выпускников Метархии: 1. Алексей Орленко https://github.com/aqrln 2. Дмитрий Нечай https://github.com/nechaido 3. Денис Отришко https://github.com/lundibundi 4. Николай Белочуб https://github.com/belochub 5. Георг Ольденбургер https://github.com/georgolden 6. Владислав Духин https://github.com/primeare 7. Иван Тимошенко https://github.com/ivan-tymoshenko 8. Лидия Иванова https://github.com/lidaamber 9. Алексей Голиков https://github.com/agil 10. Артем Черненький https://github.com/GYFK 11. Андрей Высоцкий https://github.com/Gagnant 12. Сергей Нановский https://github.com/snanovskyi 13. Влад Дзюба https://github.com/DzyubSpirit 14. Роман Огиевич https://github.com/rohiievych 15. Диана Болотенюк https://github.com/mille-nium 16. Дмитрий Михайлов https://github.com/Tariod 17. Илья Федорович https://github.com/Kowalski0805 18. Алина Листунова https://github.com/alinkedd 19. Даниил Гуськов https://github.com/imnetcat 20. Алексей Румянцев https://github.com/o-rumiantsev 21. Виталий Кухар https://github.com/vkukh И если кто еще не подписан на меня, то вот мой профиль: 👉 Тимур Шемсединов https://github.com/tshemsedinov