💡 ЧЕКПОИНТ №1: Погружение в Java и ООП
Прошёл месяц активного изучения Java, и это отличный повод зафиксировать прогресс! С самого начала заметил, что, хотя синтаксис Java и JavaScript схож, сама парадигма кодирования кардинально отличается. Java — классический ООП-язык, в то время как JS — мультипарадигменный.
За это время удалось углубить понимание типов данных, структур данных и основ ООП
💾 Типы данных: Главные сходства и различия
Главное различие кроется в типизации: Java использует статическую типизацию (проверка на этапе компиляции), а JS — динамическую (проверка в Run-time).
Целые числа - byte, short, int, long
JS -number, BigInt
Плавающая точка - float, double
JS -number
В JS все числа, включая целые, хранятся как double (64-бит IEEE 754) под капотом.
Символ: char
JavaScript
Логический:boolean
⚠️ Уточнение по float и double в Java: Разница в точности не просто в количестве цифр, а в объеме памяти и соответственно, числе значащих цифр. float (32-бит) имеет около 7 значащих десятичных цифр, а double (64-бит) — около 15.
Ссылочные типы (Reference Types)
Ссылочные типы хранят не само значение, а адрес объекта в памяти.
String (Строки):Java: Ссылочный тип (String — это класс)
JS: Примитивный тип.
В обоих языках строки неизменяемы (immutable). Это значит, что любая операция, которая кажется "изменением" строки (например, .substring() или конкатенация), на самом деле создаёт новый объект String в памяти. Это и объясняет, почему, несмотря на различия в типизации, они имеют схожие методы (length, indexOf и т.д.).
Массивы и Объекты: Массивы имеют фиксированный размер (например, int[] array = new int[10];), если не используется ArrayList (коллекция).
JS: Массивы динамические. Объекты в JS используются гораздо шире (в том числе как ассоциативные массивы/хеш-таблицы).
🧱 Основы ООП в Java
Java заставил глубже разобраться в ООП, так как в JS эти концепции часто скрыты или реализованы через прототипы
———Продолжение в комментириях————
#Java #javavsjavascript #чекпоинт
Прошёл месяц активного изучения Java, и это отличный повод зафиксировать прогресс! С самого начала заметил, что, хотя синтаксис Java и JavaScript схож, сама парадигма кодирования кардинально отличается. Java — классический ООП-язык, в то время как JS — мультипарадигменный.
За это время удалось углубить понимание типов данных, структур данных и основ ООП
💾 Типы данных: Главные сходства и различия
Главное различие кроется в типизации: Java использует статическую типизацию (проверка на этапе компиляции), а JS — динамическую (проверка в Run-time).
Целые числа - byte, short, int, long
JS -number, BigInt
Плавающая точка - float, double
JS -number
В JS все числа, включая целые, хранятся как double (64-бит IEEE 754) под капотом.
Символ: char
Логический:boolean
⚠️ Уточнение по float и double в Java: Разница в точности не просто в количестве цифр, а в объеме памяти и соответственно, числе значащих цифр. float (32-бит) имеет около 7 значащих десятичных цифр, а double (64-бит) — около 15.
Ссылочные типы (Reference Types)
Ссылочные типы хранят не само значение, а адрес объекта в памяти.
String (Строки):Java: Ссылочный тип (String — это класс)
JS: Примитивный тип.
В обоих языках строки неизменяемы (immutable). Это значит, что любая операция, которая кажется "изменением" строки (например, .substring() или конкатенация), на самом деле создаёт новый объект String в памяти. Это и объясняет, почему, несмотря на различия в типизации, они имеют схожие методы (length, indexOf и т.д.).
Массивы и Объекты: Массивы имеют фиксированный размер (например, int[] array = new int[10];), если не используется ArrayList (коллекция).
JS: Массивы динамические. Объекты в JS используются гораздо шире (в том числе как ассоциативные массивы/хеш-таблицы).
🧱 Основы ООП в Java
Java заставил глубже разобраться в ООП, так как в JS эти концепции часто скрыты или реализованы через прототипы
———Продолжение в комментириях————
#Java #javavsjavascript #чекпоинт
📢 DI в JS: Не ты ищешь, тебя находят! 🚀
Dependency Injection (DI) – паттерн, который делает наш код чище и удобнее для тестирования.
Внедрение зависимостей — это когда класс или функция не создает объекты (зависимости), которые ему нужны, а получает их извне (внедряет).
Это как в ресторане: ты не идешь на кухню готовить себе стейк, а просто заказываешь его. "Повар" (или, в нашем случае, инжектор/контейнер) предоставляет тебе готовый продукт.
в JavaScript мы можем реализовать DI довольно просто:
1️⃣Внедрение через конструктор (Constructor Injection): Самый распространенный способ. Передаем зависимости как аргументы в конструктор класса.
2️⃣Внедрение через функцию (Higher-Order Functions): В функциональном JS мы можем использовать функции высшего порядка. Зависимость передается как аргумент внешней функции.
🌟 Зачем это нужно? Топ-3 преимуществ
1️⃣ Свобода от Связей (Decoupling):
Код становится менее связанным. UserService знает, что ему нужен объект с методом find(), но ему неважно, как именно он создается. Это позволяет легко заменять реализации.
2️⃣ Удобство Тестирования (Testability):
Самый большой плюс! При юнит-тестировании мы можем легко "подменить" настоящую базу данных (или API-клиента) на моковый (Mock) объект. Это гарантирует, что мы тестируем только логику нашего сервиса, а не внешние системы.
3️⃣ Гибкость и Переиспользование:
Если завтра ты решишь перейти с MySQL на MongoDB, тебе не нужно менять код в UserService. Ты просто создаешь новую реализацию Database и внедряешь ее.
🛑 Когда DI может быть "слишком"?
В небольших JS-проектах, где нет сложной иерархии классов, избыточный DI-контейнер может быть излишеством. Однако, если ты работаешь с крупным фреймворком вроде Angular (где DI — центральный элемент) или строишь большое Node.js/фронтенд-приложение, DI — твой лучший друг для поддержания порядка.
DI — это не про то, как писать код, а про то, как его организовывать. Это фундаментальный принцип, который делает твой код профессиональным и масштабируемым!
https://www.youtube.com/watch?v=l7Gu_XrwtZE
#патерн #js
Dependency Injection (DI) – паттерн, который делает наш код чище и удобнее для тестирования.
Внедрение зависимостей — это когда класс или функция не создает объекты (зависимости), которые ему нужны, а получает их извне (внедряет).
Это как в ресторане: ты не идешь на кухню готовить себе стейк, а просто заказываешь его. "Повар" (или, в нашем случае, инжектор/контейнер) предоставляет тебе готовый продукт.
в JavaScript мы можем реализовать DI довольно просто:
1️⃣Внедрение через конструктор (Constructor Injection): Самый распространенный способ. Передаем зависимости как аргументы в конструктор класса.
class Database { /* ... */ }
class UserService {
// Database внедряется сюда
constructor(db) {
this.db = db;
}
getUser(id) {
return this.db.find(id);
}
}
// В коде, где мы создаем экземпляр:
const myDB = new Database();
const userService = new UserService(myDB);2️⃣Внедрение через функцию (Higher-Order Functions): В функциональном JS мы можем использовать функции высшего порядка. Зависимость передается как аргумент внешней функции.
// db внедряется
const createUserService = (db) => (id) => {
// логика работы с db
return db.find(id);
};
// Создаем "зависимую" функцию:
const myDB = { find: (id) => ({ name: `User ${id}` }) };
const getUserService = createUserService(myDB);
// Используем:
console.log(getUserService(5));
🌟 Зачем это нужно? Топ-3 преимуществ
1️⃣ Свобода от Связей (Decoupling):
Код становится менее связанным. UserService знает, что ему нужен объект с методом find(), но ему неважно, как именно он создается. Это позволяет легко заменять реализации.
2️⃣ Удобство Тестирования (Testability):
Самый большой плюс! При юнит-тестировании мы можем легко "подменить" настоящую базу данных (или API-клиента) на моковый (Mock) объект. Это гарантирует, что мы тестируем только логику нашего сервиса, а не внешние системы.
3️⃣ Гибкость и Переиспользование:
Если завтра ты решишь перейти с MySQL на MongoDB, тебе не нужно менять код в UserService. Ты просто создаешь новую реализацию Database и внедряешь ее.
🛑 Когда DI может быть "слишком"?
В небольших JS-проектах, где нет сложной иерархии классов, избыточный DI-контейнер может быть излишеством. Однако, если ты работаешь с крупным фреймворком вроде Angular (где DI — центральный элемент) или строишь большое Node.js/фронтенд-приложение, DI — твой лучший друг для поддержания порядка.
DI — это не про то, как писать код, а про то, как его организовывать. Это фундаментальный принцип, который делает твой код профессиональным и масштабируемым!
https://www.youtube.com/watch?v=l7Gu_XrwtZE
#патерн #js
YouTube
Dependency Injection Easily Explained
In this video, we're going to discover how to implement Dependency Injection in JavaScript and learn how it can help you to decouple your code with an Inversion of Control (IoC), improve testability and use design patterns and best practices. Whether you're…
Директива "use client"
(использующиеся Next.js 13+ в связке с Next.js (или другими фреймворками, поддерживающими React Server Components, RSC).
Next.js 13+ по умолчанию использует архитектуру React Server Components (RSC).
1️⃣ Server Components (По умолчанию)
Где работают: Выполняются на сервере (во время сборки или при запросе).
Цель: Оптимизация производительности, доступ к файловой системе, получение данных.
Ограничение: Они не могут использовать интерактивные функции браузера, включая React Hooks, которые зависят от состояния (state) или эффектов (side effects).
2️⃣Client Components (С директивой "use client" )
Где работают: Выполняются в браузере (на клиенте).
Цель: Добавление интерактивности, обработка событий, управление состоянием.
Активация: Директива "use client"; сообщает сборщику, что этот файл и все импортируемые им дочерние компоненты (если они не помечены как Server Components) должны быть отправлены клиенту для выполнения.
❓ Должны ли все хуки работать с директивой?
Да, абсолютно все встроенные React Hooks, которые добавляют интерактивность и зависят от жизненного цикла компонента в браузере, требуют директивы "use client"; (или должны быть использованы в компоненте, который сам является Client Component)
Исключение: В React 19 появились новые хуки, такие как use (для чтения промисов), которые могут использоваться в Server Components. Однако, если речь идёт о традиционных хуках (useState и т.д.), им обязательно нужен Client Component.
Краткое правило
Если компонент должен реагировать на клик, ввод или хранить состояние, он должен быть Client Component и начинаться с "use client";.
Почему "use client"; не может быть динамическим
Директива "use client"; — это статический маркер (static directive), а не обычная строка кода, которая выполняется во время выполнения.
Сборщик (например, Webpack в Next.js) должен знать, какие файлы являются Клиентскими Компонентами, до того, как код начнёт выполняться. Он использует этот маркер
Определить: Какой код должен быть включен в бандл JavaScript, отправляемый клиенту.
Исключить: Какой код должен остаться на сервере (например, импорты баз данных или API-ключи, которые могут быть в Server Components).
Разбить: Как разделить код для эффективного стриминга и ленивой загрузки (code splitting).
📝 Должен Быть На Вершине Файла
🔄 Как достичь динамизма в RSC
Хотя вы не можете динамически переключать файл между сервером и клиентом, вы можете использовать динамический импорт (Dynamic Import) в Client Component для ленивой загрузки других Client Components.
Если вам нужно динамически загрузить компонент, вы можете использовать функцию next/dynamic (в Next.js) или React.lazy (в чистом React) внутри файла, который уже помечен как Client Component
Таким образом, вы не делаете "use client"; динамическим, но вы динамически загружаете сам Клиентский Компонент, что дает вам необходимую гибкость и оптимизацию.
#React #Next
(использующиеся Next.js 13+ в связке с Next.js (или другими фреймворками, поддерживающими React Server Components, RSC).
Next.js 13+ по умолчанию использует архитектуру React Server Components (RSC).
1️⃣ Server Components (По умолчанию)
Где работают: Выполняются на сервере (во время сборки или при запросе).
Цель: Оптимизация производительности, доступ к файловой системе, получение данных.
Ограничение: Они не могут использовать интерактивные функции браузера, включая React Hooks, которые зависят от состояния (state) или эффектов (side effects).
2️⃣Client Components (С директивой "use client" )
Где работают: Выполняются в браузере (на клиенте).
Цель: Добавление интерактивности, обработка событий, управление состоянием.
Активация: Директива "use client"; сообщает сборщику, что этот файл и все импортируемые им дочерние компоненты (если они не помечены как Server Components) должны быть отправлены клиенту для выполнения.
❓ Должны ли все хуки работать с директивой?
Да, абсолютно все встроенные React Hooks, которые добавляют интерактивность и зависят от жизненного цикла компонента в браузере, требуют директивы "use client"; (или должны быть использованы в компоненте, который сам является Client Component)
Исключение: В React 19 появились новые хуки, такие как use (для чтения промисов), которые могут использоваться в Server Components. Однако, если речь идёт о традиционных хуках (useState и т.д.), им обязательно нужен Client Component.
Краткое правило
Если компонент должен реагировать на клик, ввод или хранить состояние, он должен быть Client Component и начинаться с "use client";.
Почему "use client"; не может быть динамическим
Директива "use client"; — это статический маркер (static directive), а не обычная строка кода, которая выполняется во время выполнения.
Сборщик (например, Webpack в Next.js) должен знать, какие файлы являются Клиентскими Компонентами, до того, как код начнёт выполняться. Он использует этот маркер
Определить: Какой код должен быть включен в бандл JavaScript, отправляемый клиенту.
Исключить: Какой код должен остаться на сервере (например, импорты баз данных или API-ключи, которые могут быть в Server Components).
Разбить: Как разделить код для эффективного стриминга и ленивой загрузки (code splitting).
📝 Должен Быть На Вершине Файла
🔄 Как достичь динамизма в RSC
Хотя вы не можете динамически переключать файл между сервером и клиентом, вы можете использовать динамический импорт (Dynamic Import) в Client Component для ленивой загрузки других Client Components.
Если вам нужно динамически загрузить компонент, вы можете использовать функцию next/dynamic (в Next.js) или React.lazy (в чистом React) внутри файла, который уже помечен как Client Component
Таким образом, вы не делаете "use client"; динамическим, но вы динамически загружаете сам Клиентский Компонент, что дает вам необходимую гибкость и оптимизацию.
#React #Next
🧠 Что такое Inversion of Control (IoC)?
Это не конкретный инструмент или библиотека в JavaScript/React, а скорее архитектурный паттерн и принцип проектирования
Инверсия управления означает, что контроль над выполнением кода и/или созданием зависимостей переходит от вашего кода к внешней структуре (фреймворку, контейнеру, библиотеке).
Традиционное (Не-IoC) Программирование
1️⃣ Активно вызывает библиотеки.
2️⃣ Самостоятельно создает все необходимые объекты и управляет их жизненным циклом.
Пример: Вы сами пишете new DBConnection() и вызываете router.start().
Программирование с IoC
1️⃣ Пассивно предоставляет функции или классы.
2️⃣ Ожидает, что фреймворк или контейнер вызовет их в нужный момент (например, при событии клика) или предоставит необходимые зависимости.
Пример: Вы определяете компонент LoginButton, а React решает, когда и как его рендерить и вызывать обработчик onClick.
💡 IoC в чистом JavaScript (Паттерн "Стратегия" и "Шаблонный метод")
На уровне чистого JS IoC часто проявляется через следующие механизмы:
-
⚛️ IoC в React и JSX
React — это яркий пример фреймворка, основанного на принципе IoC.
1️⃣. Жизненный Цикл Компонентов (Control over Execution)
Вы не управляете рендерингом и обновлением DOM напрямую. Вы просто описываете желаемое состояние UI (в JSX).
2️⃣ Внедрение Зависимостей (Dependency Injection - DI) через Props
Хотя в React нет традиционного Контейнера IoC (как в Angular или Spring), он использует IoC для внедрения зависимостей через props.
Вместо того чтобы дочерний компонент сам импортировал и создавал свои зависимости, он просто ожидает, что родительский компонент передаст ему все, что нужно.
.3️⃣ IoC через React Context
React Context — это форма Service Locator (которая тесно связана с IoC).
Вместо того чтобы передавать зависимость (например, объект пользователя или тему) через десятки уровней props (prop drilling), вы инвертируете контроль:
Provider (Поставщик): Размещает зависимость в Context.
Consumer (Потребитель): Использует useContext() для запроса зависимости у React.
🔑 Ключевой вывод
IoC в JavaScript и React — это принцип, который позволяет писать декларативный код. Вместо того чтобы говорить, как что-то делать (императивный код), вы говорите, что нужно сделать, а фреймворк или система берет на себя ответственность за управление потоком выполнения и зависимостями. Это приводит к более чистому, модульному и легко поддерживаемому коду.
#архитектура #патерн #react
Это не конкретный инструмент или библиотека в JavaScript/React, а скорее архитектурный паттерн и принцип проектирования
Инверсия управления означает, что контроль над выполнением кода и/или созданием зависимостей переходит от вашего кода к внешней структуре (фреймворку, контейнеру, библиотеке).
Традиционное (Не-IoC) Программирование
1️⃣ Активно вызывает библиотеки.
2️⃣ Самостоятельно создает все необходимые объекты и управляет их жизненным циклом.
Пример: Вы сами пишете new DBConnection() и вызываете router.start().
Программирование с IoC
1️⃣ Пассивно предоставляет функции или классы.
2️⃣ Ожидает, что фреймворк или контейнер вызовет их в нужный момент (например, при событии клика) или предоставит необходимые зависимости.
Пример: Вы определяете компонент LoginButton, а React решает, когда и как его рендерить и вызывать обработчик onClick.
💡 IoC в чистом JavaScript (Паттерн "Стратегия" и "Шаблонный метод")
На уровне чистого JS IoC часто проявляется через следующие механизмы:
-
Обработчики Событий (Event Handlers): Вы не пишете цикл, который постоянно проверяет, нажал ли пользователь кнопку. Вы просто определяете функцию handleClick, а браузер (или Event Loop) вызывает её, когда происходит событие. Контроль инвертирован.- Функции Высшего Порядка (Higher-Order Functions): Функции, которые принимают другие функции в качестве аргументов (map, filter, reduce). Вы передаете им логику (что делать), а они сами решают, когда и как часто её вызвать.⚛️ IoC в React и JSX
React — это яркий пример фреймворка, основанного на принципе IoC.
1️⃣. Жизненный Цикл Компонентов (Control over Execution)
Вы не управляете рендерингом и обновлением DOM напрямую. Вы просто описываете желаемое состояние UI (в JSX).
2️⃣ Внедрение Зависимостей (Dependency Injection - DI) через Props
Хотя в React нет традиционного Контейнера IoC (как в Angular или Spring), он использует IoC для внедрения зависимостей через props.
Вместо того чтобы дочерний компонент сам импортировал и создавал свои зависимости, он просто ожидает, что родительский компонент передаст ему все, что нужно.
.3️⃣ IoC через React Context
React Context — это форма Service Locator (которая тесно связана с IoC).
Вместо того чтобы передавать зависимость (например, объект пользователя или тему) через десятки уровней props (prop drilling), вы инвертируете контроль:
Provider (Поставщик): Размещает зависимость в Context.
Consumer (Потребитель): Использует useContext() для запроса зависимости у React.
🔑 Ключевой вывод
IoC в JavaScript и React — это принцип, который позволяет писать декларативный код. Вместо того чтобы говорить, как что-то делать (императивный код), вы говорите, что нужно сделать, а фреймворк или система берет на себя ответственность за управление потоком выполнения и зависимостями. Это приводит к более чистому, модульному и легко поддерживаемому коду.
#архитектура #патерн #react
🏗 SOLID: Философия профессионального кода (Пост 1/6)
SOLID — это аббревиатура из пяти принципов объектно-ориентированного программирования (ООП). Это фильтр, через который должна проходить каждая ваша мысль о дизайне кода.
Цель: Писать код, который легко изменять, расширять и поддерживать.
Применимость: Хотя это принципы ООП, они применимы в любом современном языке, включая JavaScript (с классами) и, тем более, TypeScript.
🎯 Пример S: Принцип Единственной Ответственности (SRP)
Начинаем с самого простого, но часто нарушаемого принципа: SRP (Single Responsibility Principle).
Принцип: У каждого класса (или модуля/функции) должна быть только одна причина для изменения.
❌ Плохой код (Нарушение SRP)
✅ Хороший код (Соблюдение SRP)
Мы разделяем логику на три отдельных класса/модуля. У каждого — только одна ответственность:
🏆 Выгода от SRP
Чистота: Код легче читать и понимать, что делает каждая часть.
Поддержка: Если изменился только способ сохранения данных, мы меняем только UserRepository, не трогая логику уведомлений.
Тестирование: Легко написать юнит-тест, который проверяет только, что NotificationService отправляет письмо, не инициализируя при этом базу данных.
——————————-продолжение расшифровки в комментариях————-
#SOLID #JavaScript #ООП #Программирование
SOLID — это аббревиатура из пяти принципов объектно-ориентированного программирования (ООП). Это фильтр, через который должна проходить каждая ваша мысль о дизайне кода.
Цель: Писать код, который легко изменять, расширять и поддерживать.
Применимость: Хотя это принципы ООП, они применимы в любом современном языке, включая JavaScript (с классами) и, тем более, TypeScript.
Буква,Принцип,Название
S,Single Responsibility Principle,Единственная Ответственность
O,Open-Closed Principle,Открытости-Закрытости
L,Liskov Substitution Principle,Подстановки Барбары Лисков
I,Interface Segregation Principle,Разделения Интерфейса
D,Dependency Inversion Principle,Инверсии Зависимостей
🎯 Пример S: Принцип Единственной Ответственности (SRP)
Начинаем с самого простого, но часто нарушаемого принципа: SRP (Single Responsibility Principle).
Принцип: У каждого класса (или модуля/функции) должна быть только одна причина для изменения.
❌ Плохой код (Нарушение SRP)
class UserService {
// 1. Управление данными (Причина для изменения: изменилась база данных/API)
createUser(user) {
console.log(`Saving ${user.name} to DB...`);
}
// 2. Управление уведомлениями (Причина для изменения: нужно добавить SMS)
sendEmail(user, message) {
console.log(`Sending email to ${user.email}: ${message}`);
}
// 3. Управление логированием (Причина для изменения: нужно писать в файл)
logAction(action) {
console.log(`[LOG]: ${action}`);
}
}
// Если нам нужно поменять только, как мы отправляем почту,
// мы вынуждены менять весь класс UserService! 😱✅ Хороший код (Соблюдение SRP)
Мы разделяем логику на три отдельных класса/модуля. У каждого — только одна ответственность:
// 1. Класс для управления данными
class UserRepository {
save(user) {
console.log(`Saving user ${user.name} to DB.`);
}
}
// 2. Класс для управления уведомлениями
class NotificationService {
sendEmail(email, message) {
console.log(`Sending email to ${email}: ${message}`);
}
}
// 3. Класс для объединения (координации) действий
class UserRegistrationService {
constructor(repository, notifier) {
// Зависимости внедряются извне (DIP, увидим позже)
this.repo = repository;
this.notifier = notifier;
}
register(user) {
this.repo.save(user); // Вызывает ответственность Repository
this.notifier.sendEmail(user.email, "Welcome!"); // Вызывает ответственность Notifier
// Логирование может быть в отдельном декораторе или здесь, но в минимальном виде
}
}
🏆 Выгода от SRP
Чистота: Код легче читать и понимать, что делает каждая часть.
Поддержка: Если изменился только способ сохранения данных, мы меняем только UserRepository, не трогая логику уведомлений.
Тестирование: Легко написать юнит-тест, который проверяет только, что NotificationService отправляет письмо, не инициализируя при этом базу данных.
——————————-продолжение расшифровки в комментариях————-
#SOLID #JavaScript #ООП #Программирование
❤2
💡 Введение в GRASP
GRASP (Паттерны для общего распределения обязанностей) — это не конкретные классы или функции, а рекомендации о том, кому (какому объекту или функции) следует поручить ту или иную задачу (ответственность).
Цель: Создавать системы с низкой связанностью (Low Coupling) и высокой сплочённостью (High Cohesion) — это два ключевых "оценочных" паттерна GRASP.
1. Информационный Эксперт (Information Expert) 🧠
Это, пожалуй, самый фундаментальный принцип.
Пример в JS: Если вам нужно посчитать общую стоимость корзины, то метод calculateTotal() должен находиться в объекте Cart, потому что именно он содержит список товаров и их количество, а не в каком-то внешнем объекте-утилите.
Основные принципы создания объектов и управления ими
Создатель (Creator) 🏭
Этот паттерн помогает решить, кто должен создавать новый объект.
Суть: Класс A должен создавать объекты класса B, если:
- A содержит или агрегирует объекты B.
- A тесно использует объекты B.
- A имеет инициализирующие данные для B.
Пример : Объект ShoppingCart должен создавать объекты CartItem, потому что ShoppingCart содержит их и управляет ими.
В функциональном JS это могут быть фабричные функции или функции, управляющие коллекцией данных.
Контроллер (Controller) 🕹
Как обрабатывать пользовательский ввод или системные события?
Суть: Назначайте ответственность за обработку системных событий (клики, запросы API) объекту-контроллеру, который не является частью предметной области (домена).
Пример: В веб-приложении это может быть:
Главный объект, который обрабатывает маршруты (Router).
Объект, управляющий состоянием компонента (Component Manager).
В Telegram-боте — это главный обработчик входящих сообщений, который затем делегирует задачи другим объектам.
🎯 Оценочные паттерны для качества кода
Низкая Связанность (Low Coupling) 🔗
Стремитесь к тому, чтобы классы (или модули/функции) минимально зависели друг от друга.
Преимущества:
Упрощает повторное использование кода.
Изменения в одном месте меньше влияют на другие.
Упрощает тестирование.
Пример : Вместо того чтобы напрямую обращаться к свойствам другого объекта, используйте публичные методы (интерфейсы).
Высокая Сплочённость (High Cohesion) 🧩
Сплочённость — это степень, в которой обязанности элемента логически связаны друг с другом.
Элемент (класс, функция, модуль) должен иметь одну чётко определённую, сфокусированную ответственность (напоминает Single Responsibility Principle из SOLID).
Преимущества:
Код становится понятнее и легче в обслуживании.
Уменьшается "раздутость" классов/функций.
Пример : Модуль UserValidator.js должен только валидировать данные пользователя, а не сохранять их в базу данных.
GRASP помогает нам задавать правильные вопросы в процессе проектирования: Кто должен выполнять эту задачу? Кто имеет для этого нужную информацию? Применяя эти принципы, вы делаете свой JavaScript-код более масштабируемым и управляемым.
РЕКОМЕНДУЮ К просмотрю https://www.youtube.com/watch?v=ExauFjYV_lQ
#патерн
GRASP (Паттерны для общего распределения обязанностей) — это не конкретные классы или функции, а рекомендации о том, кому (какому объекту или функции) следует поручить ту или иную задачу (ответственность).
Цель: Создавать системы с низкой связанностью (Low Coupling) и высокой сплочённостью (High Cohesion) — это два ключевых "оценочных" паттерна GRASP.
1. Информационный Эксперт (Information Expert) 🧠
Это, пожалуй, самый фундаментальный принцип.
Суть: Назначайте ответственность тому, у кого есть все необходимые данные для её выполнения.Пример в JS: Если вам нужно посчитать общую стоимость корзины, то метод calculateTotal() должен находиться в объекте Cart, потому что именно он содержит список товаров и их количество, а не в каком-то внешнем объекте-утилите.
в// ✅ Правильно: OrderItem знает свою цену и количество
class OrderItem {
constructor(product, count) {
this.product = product;
this.count = count;
}
// Информационный Эксперт: OrderItem знает, как считать свою под-сумму
getSubtotal() {
return this.product.price * this.count;
}
}
Основные принципы создания объектов и управления ими
Создатель (Creator) 🏭
Этот паттерн помогает решить, кто должен создавать новый объект.
Суть: Класс A должен создавать объекты класса B, если:
- A содержит или агрегирует объекты B.
- A тесно использует объекты B.
- A имеет инициализирующие данные для B.
Пример : Объект ShoppingCart должен создавать объекты CartItem, потому что ShoppingCart содержит их и управляет ими.
В функциональном JS это могут быть фабричные функции или функции, управляющие коллекцией данных.
Контроллер (Controller) 🕹
Как обрабатывать пользовательский ввод или системные события?
Суть: Назначайте ответственность за обработку системных событий (клики, запросы API) объекту-контроллеру, который не является частью предметной области (домена).
Пример: В веб-приложении это может быть:
Главный объект, который обрабатывает маршруты (Router).
Объект, управляющий состоянием компонента (Component Manager).
В Telegram-боте — это главный обработчик входящих сообщений, который затем делегирует задачи другим объектам.
🎯 Оценочные паттерны для качества кода
Низкая Связанность (Low Coupling) 🔗
Стремитесь к тому, чтобы классы (или модули/функции) минимально зависели друг от друга.
Преимущества:
Упрощает повторное использование кода.
Изменения в одном месте меньше влияют на другие.
Упрощает тестирование.
Пример : Вместо того чтобы напрямую обращаться к свойствам другого объекта, используйте публичные методы (интерфейсы).
Высокая Сплочённость (High Cohesion) 🧩
Сплочённость — это степень, в которой обязанности элемента логически связаны друг с другом.
Элемент (класс, функция, модуль) должен иметь одну чётко определённую, сфокусированную ответственность (напоминает Single Responsibility Principle из SOLID).
Преимущества:
Код становится понятнее и легче в обслуживании.
Уменьшается "раздутость" классов/функций.
Пример : Модуль UserValidator.js должен только валидировать данные пользователя, а не сохранять их в базу данных.
GRASP помогает нам задавать правильные вопросы в процессе проектирования: Кто должен выполнять эту задачу? Кто имеет для этого нужную информацию? Применяя эти принципы, вы делаете свой JavaScript-код более масштабируемым и управляемым.
РЕКОМЕНДУЮ К просмотрю https://www.youtube.com/watch?v=ExauFjYV_lQ
#патерн
YouTube
🎧 GRASP принципы с адаптацией для JavaScript и Node.js
Плейлист: https://www.youtube.com/playlist?list=PLHhi8ymDMrQby8kXxsz2-J6-lsv0ilEg2
Автор: https://github.com/tshemsedinov
Патреон: https://www.patreon.com/tshemsedinov
Автор: https://github.com/tshemsedinov
Патреон: https://www.patreon.com/tshemsedinov
Паттерны GoF (сокр. от Gang of Four — «Банда Четырёх»)
это набор из 23 классических шаблонов проектирования программного обеспечения.
Их использование дает несколько ключевых преимуществ:
1️⃣ Проверенные решения: Вы используете опыт других, избегая ошибок и "изобретения велосипеда".
2️⃣ Общий язык: Паттерны дают разработчикам общий словарь для обсуждения архитектуры. Например, вместо того, чтобы долго объяснять, как вы хотите обеспечить единственный экземпляр класса, вы просто говорите: "Здесь мы используем Одиночку (Singleton)
3️⃣ Гибкость и поддерживаемость: Код, построенный на паттернах, обычно легче понимать, отлаживать, изменять и расширять.
🗂 Классификация Паттернов GoF
Все 23 паттерна делятся на три основные категории, в зависимости от их назначения:
Порождающие (Creational Patterns) — 5 паттернов
Они фокусируются на механизмах создания объектов, делая его более гибким и не привязывая код к конкретным классам.
Singleton (Одиночка) Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа.
Factory Method (Фабричный метод) Определяет интерфейс для создания объекта, но позволяет подклассам решать, какой класс инстанцировать.
Abstract Factory (Абстрактная фабрика) Предоставляет интерфейс для создания семейств взаимосвязанных объектов без указания их конкретных классов.
Builder (Строитель) Позволяет создавать сложные объекты пошагово, используя один и тот же код для разных представлений.
Prototype (Прототип) Создает новые объекты путем клонирования существующего объекта.
Структурные (Structural Patterns) — 7 паттернов
Они определяют, как классы и объекты образуют более крупные структуры, обеспечивая их гибкое и эффективное взаимодействие.
Adapter (Адаптер) Позволяет объектам с несовместимыми интерфейсами работать вместе
Decorator (Декоратор) Динамически добавляет новые обязанности объекту, оборачивая его.
Facade (Фасад) Предоставляет простой, унифицированный интерфейс к сложной подсистеме.
Composite (Компоновщик) Позволяет работать с отдельными объектами и их группами одинаково.
Поведенческие (Behavioral Patterns) — 11 паттернов
Они описывают алгоритмы и способы взаимодействия между объектами, обеспечивая эффективную коммуникацию и распределение обязанностей.
Observer (Наблюдатель) Определяет зависимость "один-ко-многим" между объектами, чтобы при изменении одного все зависимые были оповещены.
Strategy (Стратегия) Определяет семейство алгоритмов, инкапсулирует каждый из них и обеспечивает их взаимозаменяемость.
Command (Команда) Инкапсулирует запрос как объект, позволяя параметризовать клиентов, ставить операции в очередь или логировать их.
Iterator (Итератор) Предоставляет способ последовательного доступа к элементам составного объекта, не раскрывая его внутреннее представление.
#патерн
это набор из 23 классических шаблонов проектирования программного обеспечения.
Паттерны проектирования — это не готовый код, который можно скопировать, а проверенные, типовые решения часто встречающихся проблем, возникающих при проектировании объектно-ориентированных программ.Их использование дает несколько ключевых преимуществ:
1️⃣ Проверенные решения: Вы используете опыт других, избегая ошибок и "изобретения велосипеда".
2️⃣ Общий язык: Паттерны дают разработчикам общий словарь для обсуждения архитектуры. Например, вместо того, чтобы долго объяснять, как вы хотите обеспечить единственный экземпляр класса, вы просто говорите: "Здесь мы используем Одиночку (Singleton)
3️⃣ Гибкость и поддерживаемость: Код, построенный на паттернах, обычно легче понимать, отлаживать, изменять и расширять.
🗂 Классификация Паттернов GoF
Все 23 паттерна делятся на три основные категории, в зависимости от их назначения:
Порождающие (Creational Patterns) — 5 паттернов
Они фокусируются на механизмах создания объектов, делая его более гибким и не привязывая код к конкретным классам.
Singleton (Одиночка) Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа.
Factory Method (Фабричный метод) Определяет интерфейс для создания объекта, но позволяет подклассам решать, какой класс инстанцировать.
Abstract Factory (Абстрактная фабрика) Предоставляет интерфейс для создания семейств взаимосвязанных объектов без указания их конкретных классов.
Builder (Строитель) Позволяет создавать сложные объекты пошагово, используя один и тот же код для разных представлений.
Prototype (Прототип) Создает новые объекты путем клонирования существующего объекта.
Структурные (Structural Patterns) — 7 паттернов
Они определяют, как классы и объекты образуют более крупные структуры, обеспечивая их гибкое и эффективное взаимодействие.
Adapter (Адаптер) Позволяет объектам с несовместимыми интерфейсами работать вместе
Decorator (Декоратор) Динамически добавляет новые обязанности объекту, оборачивая его.
Facade (Фасад) Предоставляет простой, унифицированный интерфейс к сложной подсистеме.
Composite (Компоновщик) Позволяет работать с отдельными объектами и их группами одинаково.
Поведенческие (Behavioral Patterns) — 11 паттернов
Они описывают алгоритмы и способы взаимодействия между объектами, обеспечивая эффективную коммуникацию и распределение обязанностей.
Observer (Наблюдатель) Определяет зависимость "один-ко-многим" между объектами, чтобы при изменении одного все зависимые были оповещены.
Strategy (Стратегия) Определяет семейство алгоритмов, инкапсулирует каждый из них и обеспечивает их взаимозаменяемость.
Command (Команда) Инкапсулирует запрос как объект, позволяя параметризовать клиентов, ставить операции в очередь или логировать их.
Iterator (Итератор) Предоставляет способ последовательного доступа к элементам составного объекта, не раскрывая его внутреннее представление.
#патерн
👍1
Как я перестал «тыкаться» и начал учиться: мои итоги 2025 года 👨💻
Два года в разработке. Путь, который начался с попыток кодить на телефоне , привел меня к четкой системе и пониманию: фронтенд — это не только React.
Главный инсайт года: Дисциплина бьет хаос.
В 2024-м я не понимал, за что хвататься. В 2025-м я ввел жесткий график:
☀️ Утро — задачи.
🥗 Обед — теория.
💻 День — практика и пет-проекты.
📖 Перед сном — профильная книга.
Мои ошибки и победы:
Февраль: Прыгнул в Next.js без базы React и TS. Получил по носу, откатился назад и начал учить базу. Это было лучшее решение.
Март: «Оживил» GitHub. Разобрался со сборщиками (Webpack/Vite) — теперь я понимаю, как код превращается в приложение, а не просто жму кнопки.
Апрель-Май: Ушел в «подкапотку» сетей и Node.js. Было сложно, но теперь я знаю, как мои запросы летают по протоколам.
Лето: Прокачка JS, алгоритмы и структуры данных. Теперь мой код стал эффективнее.
Переломный момент — Preax 🚀
Думал, что HTML/CSS — это просто. Платформа Preax быстро поставила меня на место. Жесткое ревью, пиксель-перфект, семантика. Теперь я не просто копирую макет, я делаю продукт, готовый к продакшену. А еще сам проверяю чужие работы — это нереально бустит насмотренность.
Изученные технологии 2025:
-React
-TypeScript
-Flux архитектура и библеотеки на ней
-StoryBook
-Jest
-Cypress
-Node/express
-FireBase
-AWS
-Strapi
-oAuth(подключение)
Книги:
-JavaScript рецепты
-Компьютерные сети (6 издание)
-JavaScript Полное руководство (Носорог)
-Алгоритмы(Род стивенс)
-Патерны проектирования (Уго ди франческо)
-Оптимизирующие компиляторы,структура и алгоритмы (Константин Владимиров)
-Грокаем
1)функциональное мышление
2)continius delivery
3)алгоритмы 2
4)конкурентность
-React к вершинам мастерства
Что дальше? 2026-й станет финальным годом обучения. Сейчас грызу Next.js и Java (для расширения кругозора). План на 2027-й — выход на работу мечты.
Всех с наступающим! Учитесь, ошибайтесь и не забивайте на базу!
#frontend #learning #javascript #it #итогигода #preax
Два года в разработке. Путь, который начался с попыток кодить на телефоне , привел меня к четкой системе и пониманию: фронтенд — это не только React.
Главный инсайт года: Дисциплина бьет хаос.
В 2024-м я не понимал, за что хвататься. В 2025-м я ввел жесткий график:
☀️ Утро — задачи.
🥗 Обед — теория.
💻 День — практика и пет-проекты.
📖 Перед сном — профильная книга.
Мои ошибки и победы:
Февраль: Прыгнул в Next.js без базы React и TS. Получил по носу, откатился назад и начал учить базу. Это было лучшее решение.
Март: «Оживил» GitHub. Разобрался со сборщиками (Webpack/Vite) — теперь я понимаю, как код превращается в приложение, а не просто жму кнопки.
Апрель-Май: Ушел в «подкапотку» сетей и Node.js. Было сложно, но теперь я знаю, как мои запросы летают по протоколам.
Лето: Прокачка JS, алгоритмы и структуры данных. Теперь мой код стал эффективнее.
Переломный момент — Preax 🚀
Думал, что HTML/CSS — это просто. Платформа Preax быстро поставила меня на место. Жесткое ревью, пиксель-перфект, семантика. Теперь я не просто копирую макет, я делаю продукт, готовый к продакшену. А еще сам проверяю чужие работы — это нереально бустит насмотренность.
Изученные технологии 2025:
-React
-TypeScript
-Flux архитектура и библеотеки на ней
-StoryBook
-Jest
-Cypress
-Node/express
-FireBase
-AWS
-Strapi
-oAuth(подключение)
Книги:
-JavaScript рецепты
-Компьютерные сети (6 издание)
-JavaScript Полное руководство (Носорог)
-Алгоритмы(Род стивенс)
-Патерны проектирования (Уго ди франческо)
-Оптимизирующие компиляторы,структура и алгоритмы (Константин Владимиров)
-Грокаем
1)функциональное мышление
2)continius delivery
3)алгоритмы 2
4)конкурентность
-React к вершинам мастерства
Что дальше? 2026-й станет финальным годом обучения. Сейчас грызу Next.js и Java (для расширения кругозора). План на 2027-й — выход на работу мечты.
Всех с наступающим! Учитесь, ошибайтесь и не забивайте на базу!
#frontend #learning #javascript #it #итогигода #preax
👍4❤3
Forwarded from Ивашев про айти
Что будет с IT в 2026 году / С НГ, ребята!
Буду краток: думаю, что всего самого-самого вам уже пожелали близкие, поэтому со своей стороны желаю вам вкатиться, прорваться, пробиться и взлететь до новых зарплатных потолков. А я в свою очередь постараюсь вам рассказать, как это сделать максимально быстро и просто.
Без вас не было бы этого блога, поэтому очередной раз говорю: благодарю. И с праздником конечно же.
А теперь по делу.
Я всё чаще думаю о том, куда вообще движется IT — и, кажется, парадигма смещается.
Если коротко:
ценность смещается от «умения писать код» к «умению читать и понимать код».
Почему так?
Потому что само написание кода становится всё дешевле по времени.
Современные инструменты (AI, агенты, автогенерация) уже сейчас умеют генерировать вполне рабочий код — не идеальный, но достаточный. И дальше это будет только усиливаться.
Роль разработчика постепенно превращается из кодописца в ревьюера, архитектора и оркестратора:
— ты всё реже полностью «делаешь руками»;
— ты всё чаще проверяешь то, что было сделано за тебя;
— ты принимаешь решения, а не набиваешь строки кода.
И тут важно понимать:
ценность хардов — не в знании конкретного фреймворка или языка.
Да, безусловно популярные технологии знать полезно.
Но реальное преимущество дают:
— problem solving;
— системное и архитектурное мышление;
— понимание чужого кода и логики.
А теперь ещё и:
— способность сказать ИИ что именно нужно сделать — и проверить результат.
Будет целая каста людей, которые создают код, не понимая его.
И это хорошо и плохо: будут быстрее появляться продукты и будет больше проблем в этих продуктах.
И такие специалисты будут ценны, как когда-то стали создатели ботов и сайтов на конструкторах.
А вот специалисты, которые умеют:
— читать и понимать код;
— видеть очевидные ошибки и неочевидные риски;
— понимать, почему решение принято именно так;
— собирать систему из разных кусков и оркестрировать агентов;
будут тоже востребованными и дорогими.
Частый вопрос:
«Будет ли меньше рабочих мест? Упадут ли зарплаты?»
Честный ответ: никто не знает.
Я общаюсь с людьми на руководящих позициях, и могу сказать одно:
многие из них до конца не осознают, на что уже способен ИИ, и пока не готовы полностью ему доверять. Поэтому каких-то супер резких и массовых «урезаний костов» я бы не ожидал. По классике стандартные «оптимизации»
Но тренд очевиден:
— скорость разработки растёт;
— решений можно делать больше;
— команды могут быть меньше, но сильнее;
Какой будет баланс между:
— «делаем больше продуктов → больше людей»;
— «делаем то же самое → меньшей командой»;
пока открытый вопрос.
Теперь самое важное для тех, кто только входит в IT.
Многие сейчас думают:
«Наверное, уже поздно. Всё автоматизируют. Я зря учусь».
Я считаю — нет.
Почему:
— многие просто сошли с дистанции, решив, что вход слишком сложный;
— обучение стало сложнее и глубже, чем раньше;
— через время это может привести к дефициту middle специалистов.
Да, ценность «джуна» со временем снижается.
Но и уровень тех, кто сейчас обучается, становится выше.
Получается как будто баш на баш:
— ИИ забирает простую работу;
— люди выходят на рынок уже с более прокаченным мышлением.
И в итоге выигрывают те, кто:
не просто «учится программировать»,
а учится думать, разбираться в и понимать продукты.
Мой главный вывод простой:
будущее — за теми, кто сможет принимать решения и контролировать их выполнение, а не просто писать код.
И вход в то самое айти в таком случае может открываться совсем иначе. Об этом будем дальше говорить.
С НГ🎄
Буду краток: думаю, что всего самого-самого вам уже пожелали близкие, поэтому со своей стороны желаю вам вкатиться, прорваться, пробиться и взлететь до новых зарплатных потолков. А я в свою очередь постараюсь вам рассказать, как это сделать максимально быстро и просто.
Без вас не было бы этого блога, поэтому очередной раз говорю: благодарю. И с праздником конечно же.
А теперь по делу.
Я всё чаще думаю о том, куда вообще движется IT — и, кажется, парадигма смещается.
Если коротко:
ценность смещается от «умения писать код» к «умению читать и понимать код».
Почему так?
Потому что само написание кода становится всё дешевле по времени.
Современные инструменты (AI, агенты, автогенерация) уже сейчас умеют генерировать вполне рабочий код — не идеальный, но достаточный. И дальше это будет только усиливаться.
Роль разработчика постепенно превращается из кодописца в ревьюера, архитектора и оркестратора:
— ты всё реже полностью «делаешь руками»;
— ты всё чаще проверяешь то, что было сделано за тебя;
— ты принимаешь решения, а не набиваешь строки кода.
И тут важно понимать:
ценность хардов — не в знании конкретного фреймворка или языка.
Да, безусловно популярные технологии знать полезно.
Но реальное преимущество дают:
— problem solving;
— системное и архитектурное мышление;
— понимание чужого кода и логики.
А теперь ещё и:
— способность сказать ИИ что именно нужно сделать — и проверить результат.
Будет целая каста людей, которые создают код, не понимая его.
И это хорошо и плохо: будут быстрее появляться продукты и будет больше проблем в этих продуктах.
И такие специалисты будут ценны, как когда-то стали создатели ботов и сайтов на конструкторах.
А вот специалисты, которые умеют:
— читать и понимать код;
— видеть очевидные ошибки и неочевидные риски;
— понимать, почему решение принято именно так;
— собирать систему из разных кусков и оркестрировать агентов;
будут тоже востребованными и дорогими.
Частый вопрос:
«Будет ли меньше рабочих мест? Упадут ли зарплаты?»
Честный ответ: никто не знает.
Я общаюсь с людьми на руководящих позициях, и могу сказать одно:
многие из них до конца не осознают, на что уже способен ИИ, и пока не готовы полностью ему доверять. Поэтому каких-то супер резких и массовых «урезаний костов» я бы не ожидал. По классике стандартные «оптимизации»
Но тренд очевиден:
— скорость разработки растёт;
— решений можно делать больше;
— команды могут быть меньше, но сильнее;
Какой будет баланс между:
— «делаем больше продуктов → больше людей»;
— «делаем то же самое → меньшей командой»;
пока открытый вопрос.
Теперь самое важное для тех, кто только входит в IT.
Многие сейчас думают:
«Наверное, уже поздно. Всё автоматизируют. Я зря учусь».
Я считаю — нет.
Почему:
— многие просто сошли с дистанции, решив, что вход слишком сложный;
— обучение стало сложнее и глубже, чем раньше;
— через время это может привести к дефициту middle специалистов.
Да, ценность «джуна» со временем снижается.
Но и уровень тех, кто сейчас обучается, становится выше.
Получается как будто баш на баш:
— ИИ забирает простую работу;
— люди выходят на рынок уже с более прокаченным мышлением.
И в итоге выигрывают те, кто:
не просто «учится программировать»,
а учится думать, разбираться в и понимать продукты.
Мой главный вывод простой:
будущее — за теми, кто сможет принимать решения и контролировать их выполнение, а не просто писать код.
И вход в то самое айти в таком случае может открываться совсем иначе. Об этом будем дальше говорить.
С НГ
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Я решил освежить свои знания в области алгоритмов и структур данных, прочитав книгу "Computer Science для программиста-самоучки" Кори Альтхоффа.
Если у вас нет базовых знаний по алгоритмам и структурам данных, вы готовитесь к собеседованию или просто стремитесь обновить свои знания, я настоятельно рекомендую данное издание.
Книга написана доступным языком, и, несмотря на примеры на Python, материал изложен ясно и понятно.
Объем книги составляет всего 240 страниц.)
Копия книги в коментариях
#книга #алгоритмы
Если у вас нет базовых знаний по алгоритмам и структурам данных, вы готовитесь к собеседованию или просто стремитесь обновить свои знания, я настоятельно рекомендую данное издание.
Книга написана доступным языком, и, несмотря на примеры на Python, материал изложен ясно и понятно.
Объем книги составляет всего 240 страниц.)
Копия книги в коментариях
#книга #алгоритмы
❤2👍1
Live-coding на собеседовании: как не пойти ко дну, если вы Junior 💻🔥
Лайвкодинг — самый стрессовый этап. В голове паника: «А вдруг я все забуду?», а на тебя смотрят будущий тимлид и HR.
Спокойно! Выдыхаем 🙏
Цель интервьюера — не поймать вас на незнании синтаксиса, а увидеть, как вы думаете. Вот 4 правила, которые помогут пройти этот этап достойно:
1️⃣Не молчите! 🗣 Самая большая ошибка — замолчать и уйти в себя. Говорите вслух всё, что делаете: — «Я возьму хеш-таблицу, чтобы поиск был за O(1)». — «Сначала проверю крайний случай, чтобы код не упал на пустом массиве». Это показывает, что вы решаете задачу осознанно, а не просто копипастите заученные куски.
2️⃣ План важнее кода 📋 Не бросайтесь писать код сразу. Потратьте 60 секунд на декомпозицию: — «Сначала я напишу парсер, потом добавлю бизнес-логику и в конце — валидацию». Даже если план в процессе изменится, вы покажете, что умеете видеть структуру задачи.
3️⃣ Застряли? Скажите об этом прямо 🆘 Замирать и «тупить» — плохо. Профессионально — признать проблему: — «Кажется, тут нужна рекурсия, но я пока не уверен, как обработать базовый случай. Сейчас попробую набросать варианты». В реальной работе вы будете обсуждать баги с коллегами, а не страдать в одиночку. Это и хотят увидеть.
4️⃣ Идеального кода не существует ✨ Идеальное решение, появившееся из ниоткуда, пугает. «Грязное», но прозрачное решение с вашими комментариями — радует. Команде нужен человек, который умеет объяснять свои мысли.
Лайвкодинг — это имитация рабочего процесса. Будьте понятными, вовлеченными и не бойтесь ошибаться.
Для лайвкодинка мне помогает практика на CodeWars
Для размышлений в слух помогает простая диктовка своих действий при написании кода
И естественно базовые знания об алгоритмах и структурах данных, как раз недавно опубликовал книгу выше)
Дышите, думайте вслух — и всё получится! 🙌
#career #junior #livecoding #собеседование #tips
Лайвкодинг — самый стрессовый этап. В голове паника: «А вдруг я все забуду?», а на тебя смотрят будущий тимлид и HR.
Спокойно! Выдыхаем 🙏
Цель интервьюера — не поймать вас на незнании синтаксиса, а увидеть, как вы думаете. Вот 4 правила, которые помогут пройти этот этап достойно:
1️⃣Не молчите! 🗣 Самая большая ошибка — замолчать и уйти в себя. Говорите вслух всё, что делаете: — «Я возьму хеш-таблицу, чтобы поиск был за O(1)». — «Сначала проверю крайний случай, чтобы код не упал на пустом массиве». Это показывает, что вы решаете задачу осознанно, а не просто копипастите заученные куски.
2️⃣ План важнее кода 📋 Не бросайтесь писать код сразу. Потратьте 60 секунд на декомпозицию: — «Сначала я напишу парсер, потом добавлю бизнес-логику и в конце — валидацию». Даже если план в процессе изменится, вы покажете, что умеете видеть структуру задачи.
3️⃣ Застряли? Скажите об этом прямо 🆘 Замирать и «тупить» — плохо. Профессионально — признать проблему: — «Кажется, тут нужна рекурсия, но я пока не уверен, как обработать базовый случай. Сейчас попробую набросать варианты». В реальной работе вы будете обсуждать баги с коллегами, а не страдать в одиночку. Это и хотят увидеть.
4️⃣ Идеального кода не существует ✨ Идеальное решение, появившееся из ниоткуда, пугает. «Грязное», но прозрачное решение с вашими комментариями — радует. Команде нужен человек, который умеет объяснять свои мысли.
Лайвкодинг — это имитация рабочего процесса. Будьте понятными, вовлеченными и не бойтесь ошибаться.
Для лайвкодинка мне помогает практика на CodeWars
Для размышлений в слух помогает простая диктовка своих действий при написании кода
И естественно базовые знания об алгоритмах и структурах данных, как раз недавно опубликовал книгу выше)
Дышите, думайте вслух — и всё получится! 🙌
#career #junior #livecoding #собеседование #tips
👍2
Вайб-кодинг! Вот и приплыли 😁
Из каждого утюга уже трезвонит...
После поста https://t.me/brit_front/63 я серьёзно задумался...
Вайб-кодинг не зло, а помощник в умелых руках, стоит выделить внимание "в УМЕЛЫХ ".
Поразмыслив, принял такое решение , что надо этому тоже учиться, но учится просто на ПЭТ проектах или же переписывая старый код.
Так как я даже еще не junior разработчик , мне важно тренировать насмотренность кода и практику написания .
По моему мнению( после прочтения статей и вообще послушав некоторых экспертов) стоит начинать тренировать навыки Вайб-кодинга, так как скорость решения бизнес задач важна и дейдлайны все короче, да на собесах так и будут спрашивать теорию, но когда попадёшь в команду , то нужно быстро реализовывать задачи и всем плевать на нейронке написал или своими ручками...
но главное не переводить это в панацею и вдаваться в каждый момент который непонятен.
И вот первая статья https://habr.com/ru/articles/942402/?ysclid=mkh941i7mx182671775
Грубо говоря инструкция как писать)
#вайб_кодинг
Из каждого утюга уже трезвонит...
После поста https://t.me/brit_front/63 я серьёзно задумался...
Вайб-кодинг не зло, а помощник в умелых руках, стоит выделить внимание "в УМЕЛЫХ ".
Поразмыслив, принял такое решение , что надо этому тоже учиться, но учится просто на ПЭТ проектах или же переписывая старый код.
Так как я даже еще не junior разработчик , мне важно тренировать насмотренность кода и практику написания .
По моему мнению( после прочтения статей и вообще послушав некоторых экспертов) стоит начинать тренировать навыки Вайб-кодинга, так как скорость решения бизнес задач важна и дейдлайны все короче, да на собесах так и будут спрашивать теорию, но когда попадёшь в команду , то нужно быстро реализовывать задачи и всем плевать на нейронке написал или своими ручками...
но главное не переводить это в панацею и вдаваться в каждый момент который непонятен.
И вот первая статья https://habr.com/ru/articles/942402/?ysclid=mkh941i7mx182671775
Грубо говоря инструкция как писать)
#вайб_кодинг
Есть идея, что скоро все мы будем писать не на языках программирования, а на обычном человеческом языке (например, английском или русском). Десятки лет об этом мечтают фантасты и менеджеры. Неужели мечта скоро воплотится? Это доклад о том, что нас ждет в парадигме, где нет кода в его привычном понимании. Посмотрим, как меняется роль инженера: из простого кодера он становится «архитектором намерений», создающим фундаментальные правила для интеллектуальных систем.
https://vkvideo.ru/video-182881521_456239539?t=26m47s
https://vkvideo.ru/video-182881521_456239539?t=26m47s
VK Видео
За гранью вайбкодинга: от промтов к спецификациям [Dev Platform Services]
☁️ Попробуй наше облако бесплатно https://clck.ru/3Ljx6D Трек: Dev Platform Services Спикер: Олег Чирухин Владелец продукта GigaIDE Cloud, СберТех О чем доклад: Есть идея, что скоро все мы будем писать не на языках программирования, а на обычном человеческом…
🚀 Popover API: Всплывающие окна без боли и JavaScript
Раньше для создания обычного выпадающего меню или тултипа нам приходилось либо подключать тяжелые библиотеки, либо вручную возиться с z-index, позиционированием и обработчиками кликов.
Popover API меняет правила игры. Теперь это стандартная фича браузеров, позволяющая создавать всплывающие элементы на чистом HTML.
🔹 Top Layer (Верхний слой): Поповер автоматически рендерится на «верхнем слое» страницы. Больше никакой войны с z-index: 99999. 🔹 Light Dismiss: Нативное «легкое закрытие». Кликнули мимо или нажали Esc — окно закрылось само. 🔹 Минимум кода: Связка кнопки и окна происходит через HTML-атрибуты. 🔹 Доступность (A11Y): Браузер сам объясняет скринридерам, что это всплывающее окно и оно открыто.
🧐 Popover vs <dialog>: в чем разница?
Многие путают их, но назначение разное:
<dialog> — для критически важных модальных окон (подтверждение удаления, логин), которые блокируют работу со страницей.
Popover API — для вспомогательного UI (меню, подсказки, уведомления), которые не мешают взаимодействию с контентом.
🎨 Кастомизация
Вы можете стилизовать поповер через CSS с помощью псевдокласса :popover-open и добавлять размытие фона через ::backdrop.
Поддержка: Уже во всех современных браузерах (Chrome 114+, Safari 17+, Firefox 125+). Можно смело использовать в проектах!
Благодарю Андрея за предоставленный новый иструмент. канал https://t.me/vzhuh_frontend
#webdev #frontend #html #css #tips
Раньше для создания обычного выпадающего меню или тултипа нам приходилось либо подключать тяжелые библиотеки, либо вручную возиться с z-index, позиционированием и обработчиками кликов.
Popover API меняет правила игры. Теперь это стандартная фича браузеров, позволяющая создавать всплывающие элементы на чистом HTML.
🔹 Top Layer (Верхний слой): Поповер автоматически рендерится на «верхнем слое» страницы. Больше никакой войны с z-index: 99999. 🔹 Light Dismiss: Нативное «легкое закрытие». Кликнули мимо или нажали Esc — окно закрылось само. 🔹 Минимум кода: Связка кнопки и окна происходит через HTML-атрибуты. 🔹 Доступность (A11Y): Браузер сам объясняет скринридерам, что это всплывающее окно и оно открыто.
<button popovertarget="my-menu">Открыть меню</button>
<div id="my-menu" popover>
<p>Привет! Я — нативный поповер 👋</p>
</div>
🧐 Popover vs <dialog>: в чем разница?
Многие путают их, но назначение разное:
<dialog> — для критически важных модальных окон (подтверждение удаления, логин), которые блокируют работу со страницей.
Popover API — для вспомогательного UI (меню, подсказки, уведомления), которые не мешают взаимодействию с контентом.
🎨 Кастомизация
Вы можете стилизовать поповер через CSS с помощью псевдокласса :popover-open и добавлять размытие фона через ::backdrop.
Поддержка: Уже во всех современных браузерах (Chrome 114+, Safari 17+, Firefox 125+). Можно смело использовать в проектах!
Благодарю Андрея за предоставленный новый иструмент. канал https://t.me/vzhuh_frontend
#webdev #frontend #html #css #tips
Telegram
Bжух-frontend
Советы, хаки и новости frontend-разработки
#React #Vue #Angular #Svelte #jQuery #frontend #Node #Git #programmer #html #css #js #ts #javascript #typescript #Next #Vite
#React #Vue #Angular #Svelte #jQuery #frontend #Node #Git #programmer #html #css #js #ts #javascript #typescript #Next #Vite
❤2
Шедоуинг и парное программирование
При прочтении книги README.суровые реалии разработчика, наткнулся на такую интересную методику
🔹 Шедоуинг:
Наблюдение за действиями опытного сотрудника позволяет активно учиться новому. Важно вести заметки и задавать вопросы. Выделяйте время перед сессиями для планирования и после — для анализа результатов. Когда почувствуете себя уверенно, предложите поменять роли: пусть старший разработчик станет наблюдателем и даст вам обратную связь. Так вы подготовитесь даже к стрессовым ситуациям вроде собеседований.
🔹 Парное программирование:
Два инженера работают над задачей одновременно, вводя код по очереди. Этот метод требует привыкания, но значительно ускоряет обмен знаниями. Сторонники метода отмечают улучшение качества кода. Даже опытные специалисты извлекают пользу из такого подхода.
⭐️ Некоторые компании практикуют взаимное обучение разными способами: наблюдение за сотрудниками поддержки клиентов или отдела продаж помогает лучше понимать потребности пользователей. Поделитесь своими выводами с командой и обсудите идеи с руководством и старшими специалистами.
инструменты для внедрения методик:
📌 Совместные редакторы кода:
Используйте онлайн-платформы типа Google Docs или специализированные IDE с поддержкой совместного редактирования (например, Visual Studio Live Share).
📌 Сервисы обратной связи:
Записывайте свои сессии и просматривайте их позже для анализа ошибок и успехов. Используйте сервисы вроде Loom или Zoom для записи экранов.
📌 Интеграция в рабочий процесс:
Разрабатывая новые проекты, заранее включайте элементы шедоуинга и парного программирования в этапы разработки, тестирования и рефакторинга.
Конечно интересно это все, я бы попробовал, особенно парное ...
Мб у вас есть опыт в этом ? Или мб кто хочет скооперироваться?)
#статья
При прочтении книги README.суровые реалии разработчика, наткнулся на такую интересную методику
🔹 Шедоуинг:
Наблюдение за действиями опытного сотрудника позволяет активно учиться новому. Важно вести заметки и задавать вопросы. Выделяйте время перед сессиями для планирования и после — для анализа результатов. Когда почувствуете себя уверенно, предложите поменять роли: пусть старший разработчик станет наблюдателем и даст вам обратную связь. Так вы подготовитесь даже к стрессовым ситуациям вроде собеседований.
🔹 Парное программирование:
Два инженера работают над задачей одновременно, вводя код по очереди. Этот метод требует привыкания, но значительно ускоряет обмен знаниями. Сторонники метода отмечают улучшение качества кода. Даже опытные специалисты извлекают пользу из такого подхода.
⭐️ Некоторые компании практикуют взаимное обучение разными способами: наблюдение за сотрудниками поддержки клиентов или отдела продаж помогает лучше понимать потребности пользователей. Поделитесь своими выводами с командой и обсудите идеи с руководством и старшими специалистами.
инструменты для внедрения методик:
📌 Совместные редакторы кода:
Используйте онлайн-платформы типа Google Docs или специализированные IDE с поддержкой совместного редактирования (например, Visual Studio Live Share).
📌 Сервисы обратной связи:
Записывайте свои сессии и просматривайте их позже для анализа ошибок и успехов. Используйте сервисы вроде Loom или Zoom для записи экранов.
📌 Интеграция в рабочий процесс:
Разрабатывая новые проекты, заранее включайте элементы шедоуинга и парного программирования в этапы разработки, тестирования и рефакторинга.
Конечно интересно это все, я бы попробовал, особенно парное ...
Мб у вас есть опыт в этом ? Или мб кто хочет скооперироваться?)
#статья
Лови краткий гайд по архитектуре и неймингу в React. Это база, которая спасет тебя от превращения проекта в «помойку» из файлов уже на второй неделе разработки. 📂
🏷 Как называть файлы?
В мире JS/React есть негласный стандарт, которого придерживается большинство топовых команд:
Компоненты: Используем PascalCase.
Button.jsx, UserProfile.tsx. Если файл — это компонент, он должен выделяться с большой буквы.
Обычные JS-функции и хуки: Используем camelCase.
useAuth.ts, apiClient.js, formatDate.ts.
Стили: Чаще всего Component.module.scss или styles.ts.
Тесты: FileName.test.tsx или FileName.spec.tsx.
Совет: Старайся давать файлам существительные имена. Не DoingAction.tsx, а ActionExecutor.tsx.
🏗 Куда что класть? (Архитектура)
Если проект маленький — хватит папки components. Но если ты планируешь расти, смотри в сторону Feature-Sliced Design (FSD) или упрощенной слоистой структуры:
1. src/shared (Общее)
Здесь живут переиспользуемые кирпичики, которые не знают о бизнесе:
UI-kit (кнопки, инпуты, модалки).
Хелперы, утилиты, типы.
2. src/entities (Сущности)
Бизнес-единицы. Например: User, Product, Article.
Тут лежат только данные этой сущности и ее простейшее отображение (карточка товара, аватар пользователя).
3. src/features (Фичи)
Действия, которые несут ценность.
AddToCart, LoginByEmail, SearchProduct. Фича может объединять несколько сущностей.
4. src/widgets (Виджеты)
Крупные блоки страницы.
Header, Sidebar, ProductGrid. Они собирают фичи и сущности в готовые композиции.
5. src/pages (Страницы)
Целые экраны. Здесь минимум логики — просто склеиваем виджеты.
🚀 Золотое правило импортов
Чтобы не запутаться, запомни: слои могут импортировать только то, что находится ниже их по списку.
✅ Page может брать из Widgets, Features, Entities и Shared.
❌ Shared не может импортировать ничего из Features или Pages. Это «чистая» папка.
#статья #архитектура
🏷 Как называть файлы?
В мире JS/React есть негласный стандарт, которого придерживается большинство топовых команд:
Компоненты: Используем PascalCase.
Button.jsx, UserProfile.tsx. Если файл — это компонент, он должен выделяться с большой буквы.
Обычные JS-функции и хуки: Используем camelCase.
useAuth.ts, apiClient.js, formatDate.ts.
Стили: Чаще всего Component.module.scss или styles.ts.
Тесты: FileName.test.tsx или FileName.spec.tsx.
Совет: Старайся давать файлам существительные имена. Не DoingAction.tsx, а ActionExecutor.tsx.
🏗 Куда что класть? (Архитектура)
Если проект маленький — хватит папки components. Но если ты планируешь расти, смотри в сторону Feature-Sliced Design (FSD) или упрощенной слоистой структуры:
1. src/shared (Общее)
Здесь живут переиспользуемые кирпичики, которые не знают о бизнесе:
UI-kit (кнопки, инпуты, модалки).
Хелперы, утилиты, типы.
2. src/entities (Сущности)
Бизнес-единицы. Например: User, Product, Article.
Тут лежат только данные этой сущности и ее простейшее отображение (карточка товара, аватар пользователя).
3. src/features (Фичи)
Действия, которые несут ценность.
AddToCart, LoginByEmail, SearchProduct. Фича может объединять несколько сущностей.
4. src/widgets (Виджеты)
Крупные блоки страницы.
Header, Sidebar, ProductGrid. Они собирают фичи и сущности в готовые композиции.
5. src/pages (Страницы)
Целые экраны. Здесь минимум логики — просто склеиваем виджеты.
🚀 Золотое правило импортов
Чтобы не запутаться, запомни: слои могут импортировать только то, что находится ниже их по списку.
✅ Page может брать из Widgets, Features, Entities и Shared.
❌ Shared не может импортировать ничего из Features или Pages. Это «чистая» папка.
src/
├── app/ # Инициализация: провайдеры (Redux, Query), глобальные стили
├── pages/ # Сами экраны
│ ├── ProductPage/ # Страница товара
│ └── CartPage/ # Страница корзины
├── widgets/ # Сложные блоки (собираются из фич и сущностей)
│ ├── Header/ # Лого + Поиск + Иконка профиля
│ └── ProductList/ # Сетка товаров с фильтрацией
├── features/ # Действия (логика + UI)
│ ├── AddToCart/ # Кнопка "Купить" + логика добавления в стейт
│ ├── FilterProducts/ # Логика фильтрации по цене/категории
│ └── AuthByPhone/ # Форма входа
├── entities/ # Бизнес-сущности (только данные и простые компоненты)
│ ├── Product/ # Карточка товара (без кнопок действия), типы, API
│ ├── User/ # Стейт юзера, его аватар
│ └── Cart/ # Логика расчета суммы корзины
└── shared/ # Переиспользуемый "фундамент"
├── ui/ # UI-Kit: Button.tsx, Input.tsx, Loader.tsx
└── api/ # Базовый инстанс axios/fetch
#статья #архитектура
❤1👍1
🚀 Enum: Зачем они нужны и как выживать в JS без них
Если ты когда-нибудь писал код вроде if (status === 0) или if (status === 'active'), то ты уже сталкивался с проблемой «магических значений». Enum (перечисления) — это способ дать этим значениям понятные имена.
🧩 Что такое Enum на пальцах?
Представь, что у тебя есть набор фиксированных опций: например, статусы заказа.
- Вместо того чтобы помнить, что 0 — это «новый», а 1 — «в работе», ты создаешь OrderStatus.New и OrderStatus.Processing.
- Результат: Код читается как книга, а вероятность опечататься в строке actve (вместо active) стремится к нулю.
🧐 А что в JavaScript?
Тут небольшой подвох: в чистом JS нативных Enum нет. Совсем. Это тебе не Java или C#.
Но JavaScript-разработчики — народ находчивый, поэтому мы используем Plain Old JavaScript Objects (POJO).
Как это выглядит в коде:
Важно: Мы используем Object.freeze(), чтобы никто случайно не удалил или не изменил наши статусы в процессе работы.
🛡 TypeScript спешит на помощь
Если тебе нужны «настоящие» Enum, добро пожаловать в TypeScript. Там они встроены из коробки:
Плюс: TS сам подскажет доступные варианты через автокомплит.
Минус: Под капотом Enum в TS превращаются в довольно громоздкие функции, что иногда бесит перфекционистов (поэтому многие используют const enum или Union Types).
💡 Связь в вебе: когда это критично?
В больших проектах (как твой список задач) Enum незаменимы для:
1️⃣Тем оформления: THEME.LIGHT / THEME.DARK.
2️⃣ Ролей пользователей: USER_ROLE.ADMIN / USER_ROLE.GUEST.
3️⃣Типов задач: TASK_TYPE.URGENT / TASK_TYPE.BACKLOG.
Если пишешь на JS — создавай замороженный объект. Если на TS — используй enum или строковые литералы. Главное — убей «магические строки» в своем коде! 💀
#JS #WebDev #Tips #Programming #Enum
Если ты когда-нибудь писал код вроде if (status === 0) или if (status === 'active'), то ты уже сталкивался с проблемой «магических значений». Enum (перечисления) — это способ дать этим значениям понятные имена.
🧩 Что такое Enum на пальцах?
Представь, что у тебя есть набор фиксированных опций: например, статусы заказа.
- Вместо того чтобы помнить, что 0 — это «новый», а 1 — «в работе», ты создаешь OrderStatus.New и OrderStatus.Processing.
- Результат: Код читается как книга, а вероятность опечататься в строке actve (вместо active) стремится к нулю.
🧐 А что в JavaScript?
Тут небольшой подвох: в чистом JS нативных Enum нет. Совсем. Это тебе не Java или C#.
Но JavaScript-разработчики — народ находчивый, поэтому мы используем Plain Old JavaScript Objects (POJO).
Как это выглядит в коде:
const OrderStatus = Object.freeze({
NEW: 'new',
PROCESSING: 'processing',
COMPLETED: 'completed',
CANCELLED: 'cancelled'
});
// Используем:
let currentStatus = OrderStatus.NEW;
if (currentStatus === OrderStatus.NEW) {
console.log('Начинаем работу!');
}Важно: Мы используем Object.freeze(), чтобы никто случайно не удалил или не изменил наши статусы в процессе работы.
🛡 TypeScript спешит на помощь
Если тебе нужны «настоящие» Enum, добро пожаловать в TypeScript. Там они встроены из коробки:
enum Direction {
Up = "UP",
Down = "DOWN",
Left = "LEFT",
Right = "RIGHT",
}Плюс: TS сам подскажет доступные варианты через автокомплит.
Минус: Под капотом Enum в TS превращаются в довольно громоздкие функции, что иногда бесит перфекционистов (поэтому многие используют const enum или Union Types).
💡 Связь в вебе: когда это критично?
В больших проектах (как твой список задач) Enum незаменимы для:
1️⃣Тем оформления: THEME.LIGHT / THEME.DARK.
2️⃣ Ролей пользователей: USER_ROLE.ADMIN / USER_ROLE.GUEST.
3️⃣Типов задач: TASK_TYPE.URGENT / TASK_TYPE.BACKLOG.
Если пишешь на JS — создавай замороженный объект. Если на TS — используй enum или строковые литералы. Главное — убей «магические строки» в своем коде! 💀
#JS #WebDev #Tips #Programming #Enum
👍2
Книга «Как на самом деле работают компьютеры» автора Метью Джастиса
представляет собой подробное руководство, объясняющее принципы работы компьютеров простым и доступным языком .
Начнём с аналового сигнала, перейдём на биты, дадим тока на транзистор , посмотрим что происходит с ОЗУ,
создадим сервер, заставим игровой автомат работать и получать с него данные о наших денюшках!
В общем книгу прочитал на одном дыхании!Советую , Копия книги в коментарих
#компьютеры #IT #технологии #книга
представляет собой подробное руководство, объясняющее принципы работы компьютеров простым и доступным языком .
Начнём с аналового сигнала, перейдём на биты, дадим тока на транзистор , посмотрим что происходит с ОЗУ,
создадим сервер, заставим игровой автомат работать и получать с него данные о наших денюшках!
В общем книгу прочитал на одном дыхании!Советую , Копия книги в коментарих
#компьютеры #IT #технологии #книга
Forwarded from kaleos.p
hh.ru провели очередной анализ и выяснили:
🟣 Общее количество доступных вакансий в IT значительно уменьшилось по сравнению с прошлым годом (–39 %).🟣 Количество резюме от IT-специалистов выросло на 30 % за два года.🟣 В январе 2026 индекс соотношения резюме к вакансиям показал ~21,3, что говорит о сильной конкуренции на рынке труда. (в январе 2025 этот показатель был около 9,9)
Стоит учитывать, что это просто сводка и усредненные цифры от hh(где борьбу за место ведут боты друг с другом), а не глубокое исследование.
источник
Подписаться
Please open Telegram to view this post
VIEW IN TELEGRAM
