Специализация
Python Backend Developer
Java Backend Developer
Node.js Backend Developer
Golang Backend Developer
React Frontend Developer
Выберите навыки
React
JavaScript
Git
Redux
Webpack
Сложность
1-3
4-6
7-8
9-10
Рейтинг вопросов
1
2
3
4
5
Подпишись на React Developer в телеграм
Чем отличается convenience от designated?
Designated — это основной инициализатор, который полностью инициализирует все свойства объекта и вызывает инициализатор суперкласса (если это класс). Convenience — это вспомогательный инициализатор, который вызывает другой инициализатор того же класса, чтобы упростить создание объекта.
Что такое FSD-архитектура? Какие слои использовали?
FSD делит проект на слои по бизнес-логике:
App — инициализация, роутинг.
Pages — страницы.
Features — фичи (например, авторизация).
Entities — бизнес-сущности (User, Product).
Shared — UI-кит, утилиты.
Какие методологии организации проекта (FSD, Atomic Design) ты использовал? В чём их отличия?
Atomic Design — это методология дизайна, которая делит интерфейс на иерархические уровни: атомы (кнопка, инпут), молекулы (поисковая строка = инпут + кнопка), организмы (шапка сайта), шаблоны и страницы. FSD (Feature-Sliced Design) — это архитектурная методология для frontend-проектов, которая фокусируется на организации папок по бизнес-логике: она делит код на слои (app, pages, features, entities, shared). Ключевое отличие: Atomic Design — это про компоненты, а FSD — про всю структуру проекта, включая логику, состояния и API.
Какие внешние UI-киты использовал (Material UI, NDesign, Shad-CN)?
Material UI (MUI) — это комплексная библиотека компонентов, реализующая гайдлайны Google Material Design, она предоставляет готовые, стилизованные и функциональные компоненты "из коробки". ShadCN/ui — это не библиотека в традиционном понимании, а коллекция доступных, настраиваемых компонентов, код которых ты копируешь себе в проект и полностью контролируешь; он построен на основе Tailwind CSS и Radix UI. NDesign (теперь известный как Gravity UI) — это дизайн-система от Nordeck, часто используемая в корпоративных продуктах.
Что такое DDD (Domain-Driven Design) и как можно применить этот подход на практике?
DDD (Domain-Driven Design) — это подход к разработке программного обеспечения, который фокусируется на сложной предметной области (домене). Его основная идея — максимально точно смоделировать в коде бизнес-процессы, правила и понятия, используя общий язык между разработчиками и экспертами.
На практике его применяют через:
Глубокое погружение в домен: Постоянное общение с бизнес-экспертами.
Создание единого языка (Ubiquitous Language): Использование одних и тех же точных терминов (например, "Портфель заказов", "Инвойс", "Сборка") в разговорах, документах и коде.
Выделение bounded context (ограниченных контекстов): Чёткое разделение большой системы на относительно независимые модули, каждый со своей внутренней моделью (например, "Контекст логистики" и "Контекст биллинга").
Что такое Domain-Driven Design (DDD) и в чём заключается его фундаментальная идея?
Какие ключевые элементы должны быть отображены на уровне базового System Design для распределённой системы?
Какие основные этапы включает high-level system design?
Какие аспекты system design вы считаете ключевыми при проектировании backend-систем?
Рейтинг:
5
Сложность:
7
DDD — это подход к проектированию, который ставит бизнес-домен в центр разработки. Главная идея — строить архитектуру так, чтобы код отражал реальные бизнес-правила и язык предметной области. Основные элементы DDD — сущности (entities), value objects, агрегаты, доменные сервисы, bounded contexts и ubiquitous language. Этот подход позволяет создавать гибкие и понятные системы, особенно когда бизнес-логика сложная.
Рейтинг:
5
Сложность:
6
На базовом уровне System Design должен включать: клиентов, API-шлюз или load balancer, backend-сервисы, базы данных, кеши, очереди сообщений, систему логирования и мониторинга. Также показывают потоки данных, основные взаимодействия и границы сервисов. Такая схема помогает понять общую архитектуру, без излишних деталей реализации.
Рейтинг:
5
Сложность:
6
High-level system design включает этапы: анализ требований, обработку ограничений, определение ключевых компонентов, проектирование потоков данных, выбор технологий и продумывание масштабирования и отказоустойчивости. На этом уровне создаётся схема, показывающая, как части системы взаимодействуют. Он задаёт основу для дальнейшего детального проектирования.
Рейтинг:
5
Сложность:
7
При проектировании backend-систем важно учитывать масштабируемость, надёжность и производительность. Необходимо заранее продумать работу с данными, отказами и ростом нагрузки. Важную роль играют границы сервисов и способы их взаимодействия. Также нужно учитывать безопасность и удобство поддержки системы. Хороший system design — это баланс между простотой и будущими требованиями.
Рейтинг:
2
Сложность:
7
Рейтинг:
2
Сложность:
6
Рейтинг:
2
Сложность:
7
Рейтинг:
2
Сложность:
6
Рейтинг:
4
Сложность:
8