Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
По паттерну Middleware нужно отдельно пояснить, он не только приводит нас к race condition, а точнее и к конфликтам по данным и к конфликтам по control flow, но еще и всячески усиливает зацепление (coupling) кода:
⚠️ Провоцирует практику примесей (mixins), например: res.sessionStarted = true; и потов в куче мест if res.sessionStarted или res.userName = 'idiot';
⚠️ Провоцирует протекание абстракций - когда мы залезаем во внутренности req и res и правим их состояние, а также состояние их частей, сокетов, заголовков и т.д. не через внешний интерфейс, т.е. методы, не по контракту, а патчами, обертками, в общем, таким образов, например, ws (библиотека вебсокетов) патчит http сервер и внедряется в его середину для перехвата апгрейда до вебсокетов. Очень хорошо, что так можно сделать в JavaScript, это позволяет быстро решить любую проблему, но такое решение нужно хорошо продумать, покрыть тестами, и вероятность, что оно развалится все же велика. В системном коде это еще ок, а вот в продуктовом нужно максимально снижать протекание, полностью, конечно, его вообще невозможно уничтожить, см. "Закон дырявых абстракций".
⚠️ Провоцирует reference pollution и использование шаренного состояния: ссылки на req и res расползаются по разным частям программы, например: serviceName.method(req, res, ...); или на части req и res, пример: serviceName.method(req.socket, ...); или так: outside.emit('request', req); много есть способов: const f1 = method.bind(req); или const f2 = method(req)(res); и еще сотни.
⚠️ Провоцирует состояние гонки (race condition): через использование структуры данных за пределами middleware и потом использование такой структуры внутри нескольких middleware сразу или за счет того, что ссылки на req и res попали в другие части программы и оттуда меняется их состояние уже без привязки к next, например по setTimeout кто-то сделал таймаут отправки результатов или на по приходу какого-то события из стримов req и res кто-то хеадеры пишет, а потом другой мидлвар уже не может хеадеры записать. Это только самые частые проблемы, вы разве не сталкивались, когда мидлвары переставляют местами, чтобы найти такую последовательность, чтобы оно таки запустилось, так вот это плохая практика, она только скрывает гонку, но при нагрузке она может вылезти.
⚠️ Провоцирует писать толстые контроллеры и смешивать в них разные слои, ну мы видели все, такой эндпоинт, в котором все сразу, и работа с http протоколом, и бизнес-логика и обращение к базе данных через SQL и запись кеша в redis и отправка задачи в очередь и работа с файловой системой, да что угодно, все простыней... нет, конечно, никто так писать не заставляет, просто не все в курсе, что нужно делать слои, и выделять работу с базой в репозиторий и т.д., точнее, знают многие, но мало кто может так делать.
⚠️ Повышает зацепление (code coupling) - все части кода становятся более зависимы друг от друга благодаря всему вышеописанному, и пошевелишь одно, а ломается в другом месте.
⚠️ Провоцирует практику примесей (mixins), например: res.sessionStarted = true; и потов в куче мест if res.sessionStarted или res.userName = 'idiot';
⚠️ Провоцирует протекание абстракций - когда мы залезаем во внутренности req и res и правим их состояние, а также состояние их частей, сокетов, заголовков и т.д. не через внешний интерфейс, т.е. методы, не по контракту, а патчами, обертками, в общем, таким образов, например, ws (библиотека вебсокетов) патчит http сервер и внедряется в его середину для перехвата апгрейда до вебсокетов. Очень хорошо, что так можно сделать в JavaScript, это позволяет быстро решить любую проблему, но такое решение нужно хорошо продумать, покрыть тестами, и вероятность, что оно развалится все же велика. В системном коде это еще ок, а вот в продуктовом нужно максимально снижать протекание, полностью, конечно, его вообще невозможно уничтожить, см. "Закон дырявых абстракций".
⚠️ Провоцирует reference pollution и использование шаренного состояния: ссылки на req и res расползаются по разным частям программы, например: serviceName.method(req, res, ...); или на части req и res, пример: serviceName.method(req.socket, ...); или так: outside.emit('request', req); много есть способов: const f1 = method.bind(req); или const f2 = method(req)(res); и еще сотни.
⚠️ Провоцирует состояние гонки (race condition): через использование структуры данных за пределами middleware и потом использование такой структуры внутри нескольких middleware сразу или за счет того, что ссылки на req и res попали в другие части программы и оттуда меняется их состояние уже без привязки к next, например по setTimeout кто-то сделал таймаут отправки результатов или на по приходу какого-то события из стримов req и res кто-то хеадеры пишет, а потом другой мидлвар уже не может хеадеры записать. Это только самые частые проблемы, вы разве не сталкивались, когда мидлвары переставляют местами, чтобы найти такую последовательность, чтобы оно таки запустилось, так вот это плохая практика, она только скрывает гонку, но при нагрузке она может вылезти.
⚠️ Провоцирует писать толстые контроллеры и смешивать в них разные слои, ну мы видели все, такой эндпоинт, в котором все сразу, и работа с http протоколом, и бизнес-логика и обращение к базе данных через SQL и запись кеша в redis и отправка задачи в очередь и работа с файловой системой, да что угодно, все простыней... нет, конечно, никто так писать не заставляет, просто не все в курсе, что нужно делать слои, и выделять работу с базой в репозиторий и т.д., точнее, знают многие, но мало кто может так делать.
⚠️ Повышает зацепление (code coupling) - все части кода становятся более зависимы друг от друга благодаря всему вышеописанному, и пошевелишь одно, а ломается в другом месте.
🙊🙈🙉 Ещё остались люди, которые думают, что у middleware есть правильное и неправильное использование и при правильном все хорошо. Отличие мидлваров от цепочки ответственности в том, что в цепочке только одно звено берет всю ответственность, а в мидлварах в случае его правильного использовния все по очереди мутируют состояние, ну это тоже небезопасная практика. Это как взять сделать объект parameters и передавать его из функции в функцию по цепочке, каждая функция будет из объекта читать параметры, изменять и удалять, а потом передавать этот объект дальше. Если вы думаете, что никто в здравом уме так не сделает, то посмотрите в Node-RED это обычная практика программирования.
В кодовой базе Метархии теперь будем использовать void для консистентности возврата. Это системный код, в прикладном я не советую использовать void, он непривычен людям, лучше пишите длинный вариант.
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
Хорошее запоминание знаний, сигнатур методов, паттернов, алгоритмов, не делает вас автоматически профессионалом. Знания в современном мире под ногами валяются и что... значение знаний сильно преувеличено, а чем же тогда отличаются профессионалы? Только опытом и гибкостью ума, т.е. способностью переносить опыт из одной области в другую, проще в смежную, а чем выше профессионализм, тем более дальние области он может связывать. Например, перенос знаний между языками программирования — просто, между парадигмами — чуть сложнее, а вот брать из механики и электроники в программирование и обратно — это уже существенно сложнее, связывать архитектуру зданий и программ — еще сложнее, но гораздо более плодотворно, а ведь есть общие принципы у мифологии и эстетики, которые хорошо применимы в программной инженерии. Вот как вы отличаете красивый код? Как вы строите свой рассказ о шаблоне проектирования? Вас поймут и поверят только если вы обратитесь к символам и архетипам, человек так устроен, он не понимает явления иначе как через сказку, историю, миф о явлении, пусть даже в форме рационального, инженерного и научного повествования. Например, мы слышим про "блокировки" (locking api) и сразу возникают ассоциации, даже без зная теории, мы уже начинаем как-то думать про "объект" перекрывающий путь к "цели" (ресурсу), а слыша "конкурентность", "параллельность", "асинхронность" мы уже подсознательно начинаем представлять себе это в пространстве, в динамике, прям иллюстрации возникают, думать про это, как про электроны в полупроводниках совершенно непродуктивно, а как про конкретные вызовы api в платформе — слабо переносимо в другие проекты, вот мы и думаем про это единственным универсальным способом — разделяя общее на части, давая названия, создавая классификацию (объединяя в группы) и устанавливая связи между этими именами.
— Предлагаете переписать все с нуля?
— Просто переписывание не решит проблему, предлагаю переписать все два раза
— А можно делать это параллельно?
— Нет, только последовательно, первый раз мы поймем в чем проблема, а второй — уже сделаем хорошо
— Просто переписывание не решит проблему, предлагаю переписать все два раза
— А можно делать это параллельно?
— Нет, только последовательно, первый раз мы поймем в чем проблема, а второй — уже сделаем хорошо
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
🧑💻 Миф про разделение учебы, работы и жизни — максимально деструктивная позиция для вас, как профессионала и человека. Например, сначала обучился, а потом работаешь, но работаешь только на работе, а живешь только вне работы. Нет, дорогие мои, так не работает, это рецепт — как плохо учиться, а потом застыть в знаниях и ненавидеть работу, стараясь сбежать из нее в жизнь, и обкрадывать жизнь, вырезая из нее время работы. Я за то, чтобы все это максимально объединить, учишься всегда, работаешь всегда, живешь всегда. Никак не разорвать.
Каким должен быть хороший учебный проект? Для разработчиков информационных систем или data-aware (а это большинство программистов), систем где есть базы данных, пользовательский интерфейс, сервер приложений и взаимодействие по сети, модель предметной области и бизнес-процессы. Сюда прекрасно ложится и веб и энтерпрайз. Так вот, учебный проект лучше начинать не позднее чем через полгода после начала обучения и он должен быть сложный и желательно групповой, делаться несколько лет, постепенно с усложнением, включать не менее половины из: логирование, конфигурация, аутентификация и система прав, отложенные задачи, роутинг запросов, генерация отчетов, миграции, юнит-тесты, интеграционные и системные тесты, автоматическая сборка, телеметрия и сбор статистики, потоковое вещание, очереди, балансировка или оркестрация, интеграция с другими системами, интернационализация, резервное копирование и восстановление, распределенное хранение и обработка данных, коллаборативное редактирование, парсинг, система плагинов, многопоточность или асинхронность, многоуровневое кэширование, сессии, несколько разнотипных СУБД (например postgresql и redis), кодогенерация, обработка метаданных и метапрограммирование, многослойность, изоляция (запросов, пользователей, модулей и т.д.), межпроцессное взаимодействие и удаленный вызов процедур, транзакции и блокировки, рассылка почты и прочих нотификаций.
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
Если вы в чем-то уверены, то все вокруг вам подтверждает правильность вашей концепции, любой опыт и любое общение, будут только усиливать вашу веру. Посмотрите на ООПшников, функциональщиков, приверженцев статической типизации, противников статической типизации, любителей параллельного программирования с блокировками и адептов иммутабильных структур данных. Очень велик соблазн свести все к одному, но не просто к одному, а к своему, любимому способу, думайте...
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
Некоторые товарищи душнят и придираются к концептуальным примерам кода, поэтому буду показывать вам примеры кода, к которым сложно придраться, это одновременно и то, что я используюю в работе, достаточно концептуальные, интересные по приемам, простые и умещающиеся в слайды, но необычные штуки. Начинаем смотреть с примеров использования, они же тесты. Код тут: https://github.com/metarhia/metasql
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
💚 Активно использую стиль кода на базе следующих парадигм (не просто знаю или слышал, а предпочитаю в написании кода каждый день)
Anonymous Poll
3%
🖤 Неструктурное
24%
❤️ Процедурное
42%
💚 ООП и прототипное
38%
💛 Функциональное
15%
💙 Реактивное
3%
🤍 Автоматное
6%
💜 Метапрограммирование
3%
🧡 DSL языки
50%
❤️🩹 Пишу как попало
Forwarded from Metaeducation
— Учишься в ВУЗе на программиста? На какой специальности?
— Я специалист в области обхода двумерных матриц, сортировки массива пузырьком, могу выводить на экран коэффициентов многочлена любым способом: через std::cout, при помощи модуля crt, и даже через alert(), отлично знаю типы всех моих переменных
— Я специалист в области обхода двумерных матриц, сортировки массива пузырьком, могу выводить на экран коэффициентов многочлена любым способом: через std::cout, при помощи модуля crt, и даже через alert(), отлично знаю типы всех моих переменных
Я сторонник того, чтобы давать людям на собесах возможность листать доки, гуглить и даже спрашивать у нейронок. Что должен проверять собес? Эффективность, способность решать задачи, а не задротство, зубрежку и феноменальную память. Если вы начнете это делать, то внезапно для себя выявите, что даже при этом многие люди не справляются, полный интернет шедевров говнокода, оверинженеринга и архитектурного маразма. Еще мне важно, чтобы человек показал свое субъективное мнение, даже эмоциональную позицию по отношению к конкретным решениям и технологиям, именно это он будет проявлять в работе. А что сейчас на собесах происходит: эффект ивентлупа — люди вызубрили и могут наизусть рассказать фазы и красиво объяснить, а применить для принятия решений в коде не смогут, т.е. оно ничего не дает им в каждодневной работе.
Forwarded from Metaeducation
Please open Telegram to view this post
VIEW IN TELEGRAM
✨ Нужно всегда разделять прикладной и системный код (это минимум два слоя реальности), как и роли программистов, описал подробнее.
🧑💻 Прикладной программист пишет продуктовый код, занимается моделированием предметной области и автоматизацией процессов в ней. Прикладному программисту нужно знать node.js как инструмент, его возможности, концепции, преимущества и недостатки, но не нужно глубоко погружаться в код платформы, не нужно строить прослойку между node.js и прикладным кодом, не нужно изобретать фреймворки (внутри продукта), изобретать обобщенные инструменты и библиотеки, не имеющие отношение к предметной области. Если это происходит, то он выполняет две роли - системную и прикладную, они должны быть максимально отделены: отдельные репозитории, отдельное рабочее время и должность, отдельные цели и задачи. Чтобы писать системные вещи смотри вопросы в следующем разделе.
👨🔧 Системный (платформенный) программист пишет код, не связанный с предметной областью: фреймворки, сетевые протоколы, транслятор, компиляторы, интерпретаторы, библиотеки, занимается вещами, которые могут быть переиспользованы в сотнях и тысячах разных проектов. Это называется производство средств производства. Систем программисту нужно знать node.js гораздо глубже, не только, его возможности, концепции, преимущества и недостатки, но и недокументированные возможности и даже баги, особенности платформы, которые очень редко используются, потому, что он строит прослойку между node.js и прикладным кодом, а прослойка эта позволяет делать прикладной код более абстрактным и приближенным к предметной области.
🧑💻 Прикладной программист пишет продуктовый код, занимается моделированием предметной области и автоматизацией процессов в ней. Прикладному программисту нужно знать node.js как инструмент, его возможности, концепции, преимущества и недостатки, но не нужно глубоко погружаться в код платформы, не нужно строить прослойку между node.js и прикладным кодом, не нужно изобретать фреймворки (внутри продукта), изобретать обобщенные инструменты и библиотеки, не имеющие отношение к предметной области. Если это происходит, то он выполняет две роли - системную и прикладную, они должны быть максимально отделены: отдельные репозитории, отдельное рабочее время и должность, отдельные цели и задачи. Чтобы писать системные вещи смотри вопросы в следующем разделе.
👨🔧 Системный (платформенный) программист пишет код, не связанный с предметной областью: фреймворки, сетевые протоколы, транслятор, компиляторы, интерпретаторы, библиотеки, занимается вещами, которые могут быть переиспользованы в сотнях и тысячах разных проектов. Это называется производство средств производства. Систем программисту нужно знать node.js гораздо глубже, не только, его возможности, концепции, преимущества и недостатки, но и недокументированные возможности и даже баги, особенности платформы, которые очень редко используются, потому, что он строит прослойку между node.js и прикладным кодом, а прослойка эта позволяет делать прикладной код более абстрактным и приближенным к предметной области.
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
✨ К вопросам на собес по 🐢 #NodeJS 🚀 добавил еще 30 и их уже 100 там ✨ https://github.com/tshemsedinov/NodeJS-Interview-Questions
GitHub
GitHub - tshemsedinov/NodeJS-Interview-Questions: NodeJS ✨🐢🚀✨ вопросы для собеседований
NodeJS ✨🐢🚀✨ вопросы для собеседований. Contribute to tshemsedinov/NodeJS-Interview-Questions development by creating an account on GitHub.