Please open Telegram to view this post
VIEW IN TELEGRAM
Кто говорит, что программист должен обязательно учить алгоритмы, тренироваться на литкоде и читать книжку с кабанчиком? Вы тоже не шарите, потому, что не понимаете переходных процессов в полупроводниках, не знаете как возникает диффузионный ток на pn-переходе. Нет у вас базы )))) Так вот, не нужно быть инженером по двигателям внутреннего сгорания, чтобы водить автомобиль. 99999 из 100тыс. программистов на работе не напишут поворот АВЛ-дерева, это не нужно знать, чтобы писать сложные программные системы для медицины, логистики или банка. Это спрашивают на собесах — правда, но только потому, что найм сломан и в галерах и в фаангах, там вообще началась брежневизация руководства, полный отрыв от реальности и загнивание, как в позднем совке. Это все возможно только потому, что они уже набрали вес и скорость и теперь могут сидеть на палубе титаника, слушать музыку, пить шампанское и жевать сопли, пока он тонет. Есть очень много тем сложных и очень нужных в работе программиста, которые будут 100 раз в день использоваться на любой работе инженерной: навыки декомпозиции абстракций, управления зацеплением абстракций, т.е. усилять и снижать зацепление и понимать для чего это делаешь, навыки разделения ответственности между программными компонентами (separation of concerns), внедрение зависимостей, инверсия управления, системы модульности, это все из чего строится структура приложения. А мы видим, что люди цикл с массивом выучили и сразу переходят к архитектуре.
Вот вы говорите, алгоритмы, алгоритмы, а тут открываешь ноду и видишь такое: https://github.com/nodejs/node/blob/7014e50ca32d39b94d04e04a5e6498e5c2f4346f/lib/path.js#L249-L274
🧩 Patterns 2024: The mentoring program is ready, I'll prepare translations tomorrow )))
🗓 Start: 1 October; Duration: 12 weeks
👉 Training description: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Patterns-2024.md
👉 Registration for the course: https://forms.gle/wuJ3nvSeF2apgUESA
🗓 Start: 1 October; Duration: 12 weeks
👉 Training description: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Patterns-2024.md
👉 Registration for the course: https://forms.gle/wuJ3nvSeF2apgUESA
🚀 Patterns 2024 Тренинг с наставниками
Перевод готов, советую его прочитать даже тем, кто не берет курс, потому что это почти статья и там много идей как усовершенствовать свои знания и структурировать их: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Patterns-2024-ru.md
Автор утверждает, что это самые важные вещи, которые следует учить и практиковать:
📂 Системы модульности, внедрение зависимостей (DI) и инверсия управления (IoC)
📦 Декомпозиция абстракций и принципы GRASP с современной интерпретацией
🧩 Паттерны «Банды четырех» (GoF) переосмысленные для JavaScript и TypeScript
🔮 Принципы изоляции и SoC (Разделение ответственностей)
👷🏻♂️ Разделение прикладного и системного кода (разные специальности)
🧩 Принципы SOLID: SRP, OCP, ISP, DIP, LSP с адаптацией для разных парадигм
🌟 Мультипарадигменное программирование и создание доменных языков (DSL)
🧩 Контрактное программирование и декларативное моделирование через схемы
🏛 Чистая архитектура (Clean) и слоеная архитектура (Onion или Layered)
(читать дальше...)
Перевод готов, советую его прочитать даже тем, кто не берет курс, потому что это почти статья и там много идей как усовершенствовать свои знания и структурировать их: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Patterns-2024-ru.md
Автор утверждает, что это самые важные вещи, которые следует учить и практиковать:
📂 Системы модульности, внедрение зависимостей (DI) и инверсия управления (IoC)
📦 Декомпозиция абстракций и принципы GRASP с современной интерпретацией
🧩 Паттерны «Банды четырех» (GoF) переосмысленные для JavaScript и TypeScript
🔮 Принципы изоляции и SoC (Разделение ответственностей)
👷🏻♂️ Разделение прикладного и системного кода (разные специальности)
🧩 Принципы SOLID: SRP, OCP, ISP, DIP, LSP с адаптацией для разных парадигм
🌟 Мультипарадигменное программирование и создание доменных языков (DSL)
🧩 Контрактное программирование и декларативное моделирование через схемы
🏛 Чистая архитектура (Clean) и слоеная архитектура (Onion или Layered)
(читать дальше...)
🧩 Тарифные планы тренинга с наставниками Patterns 2024
∙ Minimal: обучение в общей группе без наставника, но с групповыми семинарами
∙ Standard: обучение с наставником в небольших группах (10 человек)
∙ Professional: обучение с наставником, индивидуально и в группах, дополнительные материалы
∙ Exclusive: персонализированный учебный трек с автором курса и приглашенными экспертами
👉 Подробности: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Patterns-2024-ru.md
Формат тренинга
🗓 12 недель (3 месяца) + онбординг (1 неделя) + секретный модуль
👍 Доступ к материалам курса дается навсегда
🕑 Каждую неделю обязательно: 1 час лекций + 2 часа семинаров + 2 часа самостоятельной работы
🥋 Тренировки и групповая работа с наставниками, а не только смотрение видосов и чтение
🙋♂️ По желанию: для глубокого погружения +3 часа дополнительных материалов на старших тарифах
🏅 По завершению курса Вы получаете сертификат
⚠️ Входные требования: базовый JavaScript + рекомендуется опыт практического программирования
🙅 Для кого не подойдет: не для начинающих, бесплатные материалы для начинающих ищите у Тимура
💳 Рассрочка: помесячная оплата для всех тарифов кроме минимального
🗺 После курса участие в комьюнити выпускников, где уже тысячи людей по всему миру
👉 Купить: https://nodeua.com/Patterns-2024-buy.html
∙ Minimal: обучение в общей группе без наставника, но с групповыми семинарами
∙ Standard: обучение с наставником в небольших группах (10 человек)
∙ Professional: обучение с наставником, индивидуально и в группах, дополнительные материалы
∙ Exclusive: персонализированный учебный трек с автором курса и приглашенными экспертами
👉 Подробности: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Patterns-2024-ru.md
Формат тренинга
🗓 12 недель (3 месяца) + онбординг (1 неделя) + секретный модуль
👍 Доступ к материалам курса дается навсегда
🕑 Каждую неделю обязательно: 1 час лекций + 2 часа семинаров + 2 часа самостоятельной работы
🥋 Тренировки и групповая работа с наставниками, а не только смотрение видосов и чтение
🙋♂️ По желанию: для глубокого погружения +3 часа дополнительных материалов на старших тарифах
🏅 По завершению курса Вы получаете сертификат
⚠️ Входные требования: базовый JavaScript + рекомендуется опыт практического программирования
🙅 Для кого не подойдет: не для начинающих, бесплатные материалы для начинающих ищите у Тимура
💳 Рассрочка: помесячная оплата для всех тарифов кроме минимального
🗺 После курса участие в комьюнити выпускников, где уже тысячи людей по всему миру
👉 Купить: https://nodeua.com/Patterns-2024-buy.html
Проблема сложности, которую решают микросервисы, на самом деле решается проектированием структуры кода на среднем уровне, т.е. люди от функций и классов хотят перескочить сразу к архитектуре, минуя модули, слои, подсистемы. Если код хорошо структурирован на среднем уровне благодаря:
- системам модульности,
- внедрению зависимостей и инверсии управления,
- архитектурным границам и слоям,
- декомпозиции абстракций,
- separation of concerns,
- information expert,
- контрактному программированию,
- управлению, сокрытию и изоляции сложности,
- разделению прикладного и системного кода,
то такое приложение можно в течении нескольких часов собрать в 2, 3, 5, 105 инстансов, заменив взаимодействие между их структурными компонентами на RPC и трансляцию событий. Так, что модули и подсистемы знать не будут, что они запущены не в одном процессе. А если код «рыхлый», то его и микросервисом не изолировать, у такого сервиса будет большой внешний трафик, потому, что зацепление на чужие данные и чужую логику высоки. Так что, «распиливание» это только распиливание бюджета команд и бюджета на инфраструктуру. Обойти вопрос хаоса на среднем уровне при помощи чуда не выйдет. Чтобы построить Application архитектуру, нужна качественная структура, а чтобы перейти к Solution и Enterprise архитектуре, нужна качественная Application архитектура. Попытки перескочить от функции, цикла и массива к Solution архитектуре приводят к появлению монстров типа облачных функций, микролитов, моносервисов и скоро мы увидим Variable as a Service, а потом гору этих абстракций, вываленных на уровень Solution, не сгруппированных и не изолированных в структурные единицы управления сложностью. Чуда не будет, ни кто не решит за нас вопрос перехода от отдельного кирпича к небоскребу, нужны промежуточные структурные единицы.
- системам модульности,
- внедрению зависимостей и инверсии управления,
- архитектурным границам и слоям,
- декомпозиции абстракций,
- separation of concerns,
- information expert,
- контрактному программированию,
- управлению, сокрытию и изоляции сложности,
- разделению прикладного и системного кода,
то такое приложение можно в течении нескольких часов собрать в 2, 3, 5, 105 инстансов, заменив взаимодействие между их структурными компонентами на RPC и трансляцию событий. Так, что модули и подсистемы знать не будут, что они запущены не в одном процессе. А если код «рыхлый», то его и микросервисом не изолировать, у такого сервиса будет большой внешний трафик, потому, что зацепление на чужие данные и чужую логику высоки. Так что, «распиливание» это только распиливание бюджета команд и бюджета на инфраструктуру. Обойти вопрос хаоса на среднем уровне при помощи чуда не выйдет. Чтобы построить Application архитектуру, нужна качественная структура, а чтобы перейти к Solution и Enterprise архитектуре, нужна качественная Application архитектура. Попытки перескочить от функции, цикла и массива к Solution архитектуре приводят к появлению монстров типа облачных функций, микролитов, моносервисов и скоро мы увидим Variable as a Service, а потом гору этих абстракций, вываленных на уровень Solution, не сгруппированных и не изолированных в структурные единицы управления сложностью. Чуда не будет, ни кто не решит за нас вопрос перехода от отдельного кирпича к небоскребу, нужны промежуточные структурные единицы.
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
Which techniques do you use to control state within software abstractions? (multiselect or add in comments)
Anonymous Poll
43%
Pure Functions
13%
Idempotent Functions
12%
State Hiding Primitives
23%
Functional Techniques
52%
OOP Techniques
23%
Flags
9%
Critical Sections and Locks
29%
Shared State
10%
Conflict-Free Data Structures
10%
Conflict-Free Flow Control
⚠️ Завтра первый день онбординга на Patterns 2024.
Это нулевая неделя, формируются группы и назначаются менторы. Процесс оказался не таким простым организационно. Всем, кто зарегистрировался - прошу спокойно подождать до вечера и если вам на почту не придет приглашение, то утром обратиться в нашу поддержку, там отдельные люди занимаются вопросами платежей, рассрочкой, потерянными контактами (часть людей везде указывает разные почты и телефоны, вводят "Юра" или "EA 00 00 FF FF" в поле фамилии и невозможно понять, кто это).
∙ Поддержка по платежам: https://t.me/patterns2024 или на почту javascript.patterns.2024@gmail.com
∙ Кто зарегистрировался но не оплатил, то платить тут https://nodeua.com/Patterns-2024-buy.html
∙ Кто оплатил, но не заполнил форму, это тут: https://forms.gle/wuJ3nvSeF2apgUESA
∙ Кто и зарегистрировлся и оплатил, но не полял куда попал, то можно посмотреть описание тренинговой программы на трех языках тут https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Patterns-2024.md
∙ Курсы по ноде и по асинхронному программированию тут: https://www.patreon.com/tshemsedinov
Пишу это потому, что есть люди, которые пишут, что хотели попасть на курс по ноде и уже где-то оплатили, а оказалось, что они на паттерны попали.
Это нулевая неделя, формируются группы и назначаются менторы. Процесс оказался не таким простым организационно. Всем, кто зарегистрировался - прошу спокойно подождать до вечера и если вам на почту не придет приглашение, то утром обратиться в нашу поддержку, там отдельные люди занимаются вопросами платежей, рассрочкой, потерянными контактами (часть людей везде указывает разные почты и телефоны, вводят "Юра" или "EA 00 00 FF FF" в поле фамилии и невозможно понять, кто это).
∙ Поддержка по платежам: https://t.me/patterns2024 или на почту javascript.patterns.2024@gmail.com
∙ Кто зарегистрировался но не оплатил, то платить тут https://nodeua.com/Patterns-2024-buy.html
∙ Кто оплатил, но не заполнил форму, это тут: https://forms.gle/wuJ3nvSeF2apgUESA
∙ Кто и зарегистрировлся и оплатил, но не полял куда попал, то можно посмотреть описание тренинговой программы на трех языках тут https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Patterns-2024.md
∙ Курсы по ноде и по асинхронному программированию тут: https://www.patreon.com/tshemsedinov
Пишу это потому, что есть люди, которые пишут, что хотели попасть на курс по ноде и уже где-то оплатили, а оказалось, что они на паттерны попали.
«выкладывайте код из вашей повседневной разработки в сторис, это легко и весело, и через 24 часа они исчезнут»
Начинающий программист совершенно уверен в том, как все должно быть, но не знает как и шагу ступить в конкретной ситуации. А опытный программист не уверен в том, как все на самом деле, но точно знает, как действовать в конкретной ситуации.
Концепции, парадигмы, паттерны и принципы, построены как мифы и верования. И самое парадоксальное в мифе, что он работает, дает хорошие результаты в ежедневной практике. Не нужно думать о нем, как о чем-то мистическом, выдуманном, отвлеченном. Если программист избавится от мифологического сознания, например перестанет верить в микросервисы, в nodejsоднопоточный, в скалярные типы данных, перестанет писать на примесях и мидлварах, то картина мира рассыпается и он не может ничего написать. Чтобы опять начать что-то создавать, нужно построить другой миф. Только ощущение, что у тебя сложилась картина мира, позволяет перейти от теории к практике. Но любая картина мира состоит из разрозненных фактов, которые переклеены мифом, иначе, бы мы утонули в зазорах между знаниями, как в пустотах между электронами и атомами. Без мифа мир страшен, непредсказуем и неуправляем. Опытный программист просто имеет несколько мифов в голове и может между ними переходить, некоторые могут даже конструировать свои, и такое конструирование может быть только интуитивное, если его начать логически строить, то никто не поверит. В мифе должны быть нестыковки, странности, даже противоречия, вот это заходит в голову идеально. Это инструмент, который позволяет действовать эффективно, скрывать сложность, давать целостную картину мира, но не слишком идеальную, чтобы было место для развития.
Концепции, парадигмы, паттерны и принципы, построены как мифы и верования. И самое парадоксальное в мифе, что он работает, дает хорошие результаты в ежедневной практике. Не нужно думать о нем, как о чем-то мистическом, выдуманном, отвлеченном. Если программист избавится от мифологического сознания, например перестанет верить в микросервисы, в nodejsоднопоточный, в скалярные типы данных, перестанет писать на примесях и мидлварах, то картина мира рассыпается и он не может ничего написать. Чтобы опять начать что-то создавать, нужно построить другой миф. Только ощущение, что у тебя сложилась картина мира, позволяет перейти от теории к практике. Но любая картина мира состоит из разрозненных фактов, которые переклеены мифом, иначе, бы мы утонули в зазорах между знаниями, как в пустотах между электронами и атомами. Без мифа мир страшен, непредсказуем и неуправляем. Опытный программист просто имеет несколько мифов в голове и может между ними переходить, некоторые могут даже конструировать свои, и такое конструирование может быть только интуитивное, если его начать логически строить, то никто не поверит. В мифе должны быть нестыковки, странности, даже противоречия, вот это заходит в голову идеально. Это инструмент, который позволяет действовать эффективно, скрывать сложность, давать целостную картину мира, но не слишком идеальную, чтобы было место для развития.
⭐️ Good and bad cases for TypeScript union types based on JavaScript V8 optimizations
👍 Good cases for union types:
- Union of strings instead of enum:
- Union of numeric as status or result code: type
- Union with shared properties:
- Union with common method:
👎 Bad cases for union types:
- Polymorphic object shapes causing depots:
- Requiring extensive "if"-logic and type checking:
- Inconsistent return types:
- Mixed primitives and objects:
- Сontradictory members:
- Union types that include any:
- Incompatible contracts:
🎁 Empty value for primitive types and reference types:
- Use
- Use
- Avoid mixing symbols with other types in unions
👍 Good cases for union types:
- Union of strings instead of enum:
type Direction = 'north' | 'south' | 'east' | 'west';- Union of numeric as status or result code: type
StatusCode = 200 | 201 | 204 | 400 | 500;- Union with shared properties:
type MailTarget = User | Company; (both with email)- Union with common method:
type Thenable = Promise | Query; (both with then method)👎 Bad cases for union types:
- Polymorphic object shapes causing depots:
type Something = User | Socket | string;- Requiring extensive "if"-logic and type checking:
type Input = string | number | boolean;- Inconsistent return types:
function getData(id: number): string | string[];- Mixed primitives and objects:
type Value = number | { value: number };- Сontradictory members:
type Person = { name: string; } | { name: number[] };- Union types that include any:
type FlexibleType = number | any;- Incompatible contracts:
type Handler = (() => string) | ((event: Event, data: any) => void);🎁 Empty value for primitive types and reference types:
- Use
null for empty reference types: Object, Function, Array, etc...- Use
undefined for empty primitive types: string, number, boolean, bigint- Avoid mixing symbols with other types in unions
💡 Способы создания более сложных абстракций из простых в ООП и функциональном программировании сильно пересекаются:
∙ Наследование - для ООП кажется, что все понятно, но применять наследование нужно не для расширения абстракции, а для сужения, что в ФП достигается типами, а для построения более сложных абстракций из более простых в ФП используют композицию, замыкания, функции высшего порядка (обертки, декораторы).
∙ Композиция - в ФП композиция везде, а вот в ООП обычно недооценена, реализуется через создание экземпляра одного класса внутри конструктора другого, композиция создает меньше зацепления и зависимости, проще тестировать, когнитивная нагрузка меньше.
∙ Агрегация - похожа на композицию, но ответственность за инстанцирование не на классе-владельце, т.е. создание экземпляров, вынесено в другие абстракции, а агрегирующий класс получает их уже готовые, чаще всего через конструктор и объединяет.
∙ Миксины - примешивать к готовым экземплярам ссылки на другие, это хаос, в ФП такого нет, и три предыдущие способа гораздо предпочтительнее, но если нет никакого более красивого выхода, то можно применить, как временное решение, создающее техдолг.
∙ Ассоциация - иногда под этим термином понимают взаимодействие абстракций, это нормально, но иногда это значит внешнюю агрегацию, в худшем случае - через миксин, в лучшем - через сеттер, так что, это тоже создает зацепление и технический долг.
∙ Делегирование - это подвид композиции, когда интерфейс внутренней абстракции полностью реализуется наружной, по сути это прямая замена наследования, без использования наследования и проблем, связанных с ним.
∙ Наследование - для ООП кажется, что все понятно, но применять наследование нужно не для расширения абстракции, а для сужения, что в ФП достигается типами, а для построения более сложных абстракций из более простых в ФП используют композицию, замыкания, функции высшего порядка (обертки, декораторы).
∙ Композиция - в ФП композиция везде, а вот в ООП обычно недооценена, реализуется через создание экземпляра одного класса внутри конструктора другого, композиция создает меньше зацепления и зависимости, проще тестировать, когнитивная нагрузка меньше.
∙ Агрегация - похожа на композицию, но ответственность за инстанцирование не на классе-владельце, т.е. создание экземпляров, вынесено в другие абстракции, а агрегирующий класс получает их уже готовые, чаще всего через конструктор и объединяет.
∙ Миксины - примешивать к готовым экземплярам ссылки на другие, это хаос, в ФП такого нет, и три предыдущие способа гораздо предпочтительнее, но если нет никакого более красивого выхода, то можно применить, как временное решение, создающее техдолг.
∙ Ассоциация - иногда под этим термином понимают взаимодействие абстракций, это нормально, но иногда это значит внешнюю агрегацию, в худшем случае - через миксин, в лучшем - через сеттер, так что, это тоже создает зацепление и технический долг.
∙ Делегирование - это подвид композиции, когда интерфейс внутренней абстракции полностью реализуется наружной, по сути это прямая замена наследования, без использования наследования и проблем, связанных с ним.