🤔 Что такое singleton?

Singleton — это паттерн, обеспечивающий создание только одного экземпляра класса для управления глобальным состоянием.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что такое гибкость (agility)?

Это способность команды, процесса или организации быстро адаптироваться к изменениям, минимизируя затраты времени, ресурсов и усилий. Гибкость подразумевает не только оперативное реагирование на запросы, но и проактивное планирование с учетом возможных изменений. Она лежит в основе *ибких методологий разработки (Agile), которые ставят в приоритет взаимодействие, ценность для клиента и быструю адаптацию к новым условиям.

🚩Аспекты гибкости

🟠Адаптивность
Гибкие системы и команды способны подстраиваться под новые бизнес-требования, изменения в технологиях или рыночных условиях без значительных потерь в эффективности. Это требует минимизации жестких зависимостей и использования подходов, таких как итеративная разработка.

🟠Итеративность и инкрементальность
Работа над проектом делится на небольшие этапы, каждый из которых добавляет определенную ценность. Итеративный подход позволяет на каждом этапе учитывать обратную связь и изменять стратегию.

🟠Устранение жесткой бюрократии
Для достижения гибкости важно упрощение процессов, которые могут затруднять принятие решений или реализацию изменений. Это обеспечивает быстрое принятие решений на основе текущих данных.

🟠Клиентоориентированность
Гибкость помогает лучше удовлетворять потребности клиента, благодаря постоянной обратной связи, приоритезации задач и возможности корректировки целей в процессе работы.

🟠Кросс-функциональные команды
Гибкость подразумевает тесное взаимодействие между разработчиками, тестировщиками, аналитиками и бизнес-стейкхолдерами. Это ускоряет обмен информацией и сокращает задержки.

🚩Почему гибкость важна?

🟠Удовлетворение клиента
В быстро меняющихся условиях рынка запросы клиентов могут изменяться. Гибкость позволяет удовлетворять эти изменения, поставляя максимально актуальный продукт.
🟠Снижение рисков
Итеративный подход позволяет быстрее выявлять и исправлять ошибки, чем при использовании традиционных методологий, таких как каскадная модель.
🟠Сокращение времени выхода на рынок
Гибкость позволяет быстрее выводить продукт на рынок, предоставляя минимально жизнеспособную версию (MVP) с возможностью дальнейшего развития.
🟠Улучшение командного взаимодействия
Постоянная обратная связь и взаимодействие между участниками команды повышают прозрачность процессов и уменьшают риски недопонимания.

🚩Примеры методологий и подходов для гибкости:

🟠Agile Manifesto
Основной документ, в котором заложены ценности и принципы гибкой разработки.
🟠Scrum
Конкретная реализация Agile с упором на спринты и роль Scrum-мастера.
🟠Kanban
Методология визуализации процессов, которая помогает выявлять узкие места и повышать эффективность.
🟠Extreme Programming (XP)
Подход, направленный на повышение качества кода и оперативное удовлетворение изменяющихся требований.

Ставь 👍 и забирай 📚 Базу знаний

🤔 В чем разница между Scrum и Kanban?

Scrum — это методология Agile с фиксированными спринтами и определёнными ролями (Scrum Master, Product Owner). Kanban — это гибкий подход, где работа организована на доске с карточками, и нет строгих временных рамок. Scrum ориентирован на итерации, а Kanban — на постоянный поток задач.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что такое гибкость (agility)?

🚩Гибкость

В контексте разработки программного обеспечения относится к способности команды, процесса или системы быстро адаптироваться к изменениям. Это ключевая характеристика Agile-методологий, которые нацелены на создание программного обеспечения через итеративный процесс, частую обратную связь и постоянную готовность к изменениям.

🚩Аспекты

🟠Быстрая адаптация к изменениям
Способность вносить изменения в функциональность, требования или архитектуру продукта без значительных потерь времени и ресурсов. Это важно, так как бизнес-цели, приоритеты и технологии могут изменяться в течение жизненного цикла проекта.

🟠Краткие итерации и обратная связь
В Agile-подходе используются короткие спринты (обычно 1–4 недели), в конце которых предоставляется работающий продукт или его часть. Это позволяет учитывать обратную связь и своевременно корректировать курс.

🟠Минимизация технического долга
Гибкость также зависит от качества кода и архитектуры системы. Хорошо структурированный код облегчает внесение изменений и снижает риск появления ошибок.

🟠Кросс-функциональные команды
В гибких командах разработчики, тестировщики, дизайнеры и бизнес-аналитики работают вместе, что ускоряет процесс и позволяет быстрее реагировать на изменения.

🟠Инструменты и автоматизация
Использование CI/CD (Continuous Integration/Continuous Delivery) помогает оперативно вносить изменения в код и быстро их доставлять пользователям.

🚩Применение гибкости

🟠Запуск продукта на рынок
Быстрое тестирование гипотез и выпуск минимально жизнеспособного продукта (MVP), чтобы собрать обратную связь от пользователей.
🟠Изменение бизнес-целей
Если меняются бизнес-требования, гибкая команда может переключиться на новые приоритеты, сохраняя при этом эффективность.
🟠Технические изменения
Адаптация к новым технологиям или платформам без больших затрат.

🚩Плюсы

➕Улучшенное качество программного обеспечения.
➕Быстрая доставка ценности заказчику.
➕Способность конкурировать в условиях быстро меняющегося рынка.
➕Снижение рисков, связанных с ошибками или неверно понятыми требованиями.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое git?

Git — это распределённая система контроля версий, которая позволяет разработчикам отслеживать изменения в коде, работать в командах и управлять ветвлениями проекта.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Проблемы с сине-зелёным деплоем при изменении БД

Предполагает, что одновременно существуют две версии приложения: старая (синяя) и новая (зелёная). База данных при этом используется общая. Во время переключения трафика от синей версии к зелёной возникают потенциальные сложности, связанные с изменением структуры данных или логики работы с ними.

🚩Проблемы

🟠Совместимость схемы данных
Если новая версия приложения требует изменений в структуре базы данных (например, добавление колонок, изменение типов данных или удаление полей), старая версия приложения может стать несовместимой с новой схемой.

🟠Изменения данных на уровне логики
Если новая версия изменяет способ обработки или хранения данных, это может вызвать проблемы при переключении трафика обратно на старую версию (например, в случае отката).

🟠Миграции данных
Выполнение миграции данных может занять время и потребовать блокировки таблиц, что может привести к снижению производительности или временному недоступности приложения.

🟠Сложность отката
Если переключение на новую версию произошло, но затем потребовался откат, структура или данные, изменённые новой версией, могут быть несовместимы со старой версией.

🟠Производительность и нагрузка
Изменения в индексации или структуре таблиц могут привести к временной деградации производительности базы данных, что затронет обе версии приложения.

🟠Состояние транзакций
Если новая версия меняет логику транзакций или порядок операций над данными, это может вызвать несогласованность в данных при выполнении параллельных операций обеими версиями.

🚩Подходы для минимизации проблем

🟠Мягкие изменения схемы
Сначала добавить новые поля или таблицы, не удаляя старые. Убедиться, что новая версия поддерживает как старую, так и новую схему. Удалить устаревшие элементы только после полного перехода.

🟠Двусторонняя совместимость
Обеспечить, чтобы новая версия приложения могла работать со старой схемой, а старая версия — с новой (на ограниченное время).

🟠Тестирование миграций
Тщательно тестировать миграции на копии данных в условиях, максимально близких к боевым.

🟠Пошаговые изменения
Сначала внести изменения в базу данных, совместимые с обеими версиями. Затем задеплоить новую версию. Удалить устаревшие элементы только после убедительности в стабильности.

🟠Фичи-флаги
Использовать фичи-флаги, чтобы включать или отключать новую функциональность, связанной с изменениями в БД, без полной смены версии.

🟠Резервное копирование и мониторинг
Выполнять резервное копирование базы данных перед началом миграции. Использовать мониторинг для раннего обнаружения проблем с производительностью или данными.

Ставь 👍 и забирай 📚 Базу знаний

🤔 В чём смысл инкапсуляции?

Инкапсуляция скрывает внутренние детали реализации объекта, предоставляя доступ к данным только через публичные методы, что защищает данные от прямого изменения.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как работать с легаси-кодом?

Это код, который устарел, но продолжает использоваться в производственных системах. Он может быть плохо документирован, сложным для понимания, не покрытым тестами или написанным на устаревших технологиях. Работа с таким кодом — частая задача разработчиков, требующая особого подхода.

🚩Проблемы легаси-кода

🟠Отсутствие тестов
Без тестов сложно понять, работает ли изменение корректно.
🟠Сложность понимания
Легаси-код часто плохо документирован и написан без соблюдения современных стандартов.
🟠Зависимость от устаревших технологий
Легаси-код может быть привязан к фреймворкам или библиотекам, которые больше не поддерживаются.
🟠Хрупкость
Даже небольшие изменения могут привести к непредсказуемым ошибкам.
🟠Долгий цикл разработки
Из-за сложности внесения изменений и отсутствия автоматизированных процессов разработка занимает больше времени.

🚩Стратегии работы с легаси-кодом

🟠Изучение и анализ
Прежде чем вносить изменения, изучите код и его окружение: Проведите рефакторинг "окружающего контекста" (например, упростите сложные методы). Используйте дебаггеры, чтобы понять поведение системы. Привлеките экспертов, знакомых с системой, если они доступны. Постарайтесь выделить области, которые наиболее часто модифицируются, чтобы сосредоточиться на них.

🟠Покрытие тестами
Перед внесением изменений напишите базовые unit-тесты или интеграционные тесты: Начните с регрессионных тестов для фиксации текущего поведения. Используйте "Characterization Tests", чтобы зафиксировать, как работает система, а не как она должна работать. Постепенно увеличивайте покрытие тестами.

🟠Модульная работа
Если возможно, изолируйте старые модули, минимизируя их влияние на новую разработку. Используйте "стратегию шва" (Seam Technique) для упрощения взаимодействия с легаси-кодом: Добавьте промежуточный слой между новым и старым кодом. Это позволит вам изменять и тестировать функциональность поэтапно.

🟠Рефакторинг
Разделяйте большие методы и классы на мелкие, с понятной ответственностью. Переименовывайте переменные и методы для улучшения читаемости. Используйте шаблоны проектирования, если это обоснованно. Применяйте правило "Boy Scout Rule": оставляйте код чуть лучше, чем он был.

🟠Декомпозиция системы
Постепенно выделяйте функциональность в независимые модули или микросервисы: Определите ключевые компоненты системы. Реализуйте новые функции вне легаси-кода, минимизируя его изменения.

🟠Обновление зависимостей
Если легаси-код зависит от устаревших библиотек или фреймворков, поэтапно обновите их: Обновляйте зависимости в порядке их важности и уровня риска. Тщательно тестируйте каждое обновление.

🟠Документирование
Если документация отсутствует, создайте её: Описывайте ключевые части системы. Добавляйте комментарии в код, объясняющие сложные места.

🟠Инструменты анализа кода
Используйте статический анализатор кода (например, SonarQube, ReSharper) для выявления проблем и повышения качества.

🚩Ошибки при работе с легаси-кодом

Полный рефакторинг "с нуля" без понимания бизнеса и текущих процессов. Внесение изменений без тестирования. Игнорирование влияния изменений на систему в целом.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое операция GROUP BY?

GROUP BY — это оператор SQL, используемый для группировки строк с одинаковыми значениями в указанных столбцах, обычно с последующим применением агрегатных функций (SUM, COUNT, AVG).

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Когда MongoDB предпочтительнее реляционной БД?

Как документо-ориентированная база данных, лучше подходит для определённых сценариев, где её гибкость, масштабируемость и высокая производительность предоставляют существенные преимущества по сравнению с реляционными базами данных (RDBMS).

🟠Гибкая и динамическая схема данных
MongoDB: Позволяет хранить документы с разной структурой, не требуя предварительного определения схемы. Реляционная БД: Требует строгого определения схемы, что делает изменения структуры данных сложными.
Когда использовать MongoDB: Разработка MVP (минимально жизнеспособного продукта) или системы, где требования к структуре данных постоянно меняются. Приложения с разнообразными типами данных, например, каталоги товаров с различными наборами атрибутов.

🟠Хранение сложных, вложенных и неструктурированных данных
MongoDB: Поддерживает вложенные структуры и массивы прямо в документах JSON.
Реляционная БД: Хранение таких данных требует сложных связей и множества таблиц.
Когда использовать MongoDB: Приложения, где нужно работать с иерархическими данными, такими как документы, профили пользователей или логи с вложенными структурами.

🟠Большие объемы данных и высокая производительность
MongoDB: Подходит для быстрого чтения/записи и обработки больших объемов данных благодаря горизонтальной масштабируемости.
Реляционная БД: Масштабируется вертикально и может столкнуться с узкими местами при экстремальных нагрузках.
Когда использовать MongoDB: Большие системы логирования, аналитики и трекинга событий. Приложения, работающие с потоками данных (например, IoT).

🟠Географически распределённые данные
MongoDB: Имеет встроенную поддержку шардирования, репликации и управления географически распределёнными данными.
Реляционная БД: Требует внешних решений для сложной настройки распределённых систем.
Когда использовать MongoDB: Приложения с глобальной пользовательской базой, требующие низкой задержки при доступе к данным.

🟠Простота горизонтального масштабирования
MongoDB: Легко масштабируется горизонтально через шардирование (распределение данных по множеству серверов).
Реляционная БД: Масштабируется в основном вертикально, что может быть дорого.
Когда использовать MongoDB: Проекты с потенциальным ростом данных до петабайтных масштабов. Приложения, где важна линейная производительность при добавлении новых серверов.

🟠Проекты, требующие быстрого времени разработки
MongoDB: Упрощает разработку благодаря отсутствию жёсткой схемы и встроенным инструментам для работы с JSON.
Реляционная БД: Требует больше времени на проектирование структуры и взаимодействие с данными.
Когда использовать MongoDB: Быстрорастущие стартапы или проекты с короткими циклами разработки.

🟠Отсутствие сложных транзакций
MongoDB: Поддерживает транзакции с ограничениями, но рассчитана на сценарии, где они не являются основным требованием.
Реляционная БД: Отлично подходит для приложений с сложными ACID-транзакциями.
Когда использовать MongoDB: Системы, где операции являются атомарными на уровне одного документа или набора документов (например, управление корзинами покупок, хранилища данных).

🚩Примеры применения MongoDB

🟠Электронная коммерция
Хранение данных о товарах с разной структурой атрибутов.
🟠Игровая индустрия
Логирование действий игроков, управление профилями.
🟠Системы аналитики
Хранение больших объемов событий и данных мониторинга.
🟠Мобильные приложения
Управление пользовательскими данными, кэшированием или оффлайн-доступом.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое транзакция в БД?

Транзакция — это последовательность операций с базой данных, которая выполняется как единое целое, с гарантиями атомарности, согласованности, изолированности и долговечности (ACID).

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как писать безопасный код?

🚩Принципы написания

🟠Валидация и очистка пользовательских данных
Опасность: Некорректные данные могут привести к SQL-инъекциям, XSS или другим атакам.
Как действовать: Всегда проверяйте входные данные на стороне сервера (не только на клиенте). Используйте whitelisting (разрешение только ожидаемых значений) вместо blacklisting (запрета нежелательных). Экранируйте или очищайте данные перед их использованием, особенно для HTML или SQL.

🟠Использование параметризованных запросов
Опасность: SQL-инъекции возможны при динамическом составлении SQL-запросов.
Как действовать: Используйте параметризованные запросы (prepared statements) для взаимодействия с базой данных. Не включайте пользовательский ввод непосредственно в запросы.

🟠Шифрование и защита данных
Опасность: Утечка конфиденциальных данных, таких как пароли или персональные данные.
Как действовать: Никогда не храните пароли в открытом виде. Используйте сильные алгоритмы хэширования, такие как bcrypt или Argon2. Шифруйте чувствительные данные перед их хранением или передачей. Используйте TLS (SSL) для защиты данных при передаче.

🟠Защита от XSS (Cross-Site Scripting)
Опасность: Вредоносный скрипт может быть внедрен и выполнен в браузере пользователя.
Как действовать: Всегда экранируйте данные, которые отображаются в HTML, JavaScript или атрибутах. Используйте контекстно-зависимую экранизацию (например, HTML, JavaScript или URL-экранирование). Ограничивайте возможность загрузки вредоносного содержимого, используя заголовок Content Security Policy (CSP).

🟠Защита от CSRF (Cross-Site Request Forgery)
Опасность: Злоумышленник может заставить пользователя выполнить действие от его имени.
Как действовать: Используйте уникальные токены CSRF в запросах (например, в форме или заголовке). Ограничивайте методы запросов (например, PUT/POST) для выполнения важных операций. Проверяйте заголовок Referer или Origin для подтверждения источника запроса.

🟠Минимизация прав доступа
Опасность: Злоумышленник может использовать уязвимость в вашем коде для получения привилегий.
Как действовать: Давайте минимально необходимые права как для пользователей, так и для сервисов. Применяйте принцип наименьших привилегий на уровне кода, базы данных и системного доступа. Ограничивайте доступ к конфиденциальным данным.

🟠Использование современных библиотек и обновлений
Опасность: Устаревшие библиотеки могут содержать уязвимости.
Как действовать: Используйте актуальные версии библиотек и фреймворков. Следите за сообщениями о безопасности и патчами в используемых технологиях.

🟠Обработка ошибок и логирование
Опасность: Некорректная обработка ошибок может раскрыть внутреннюю информацию системы.
Как действовать: Не показывайте пользователям технические детали ошибок (например, трассировки стека). Логируйте ошибки на стороне сервера, но избегайте записи конфиденциальных данных в логи. Создавайте понятные сообщения об ошибках для пользователей, не раскрывая внутренние механизмы.

🟠Защита от уязвимостей в конфигурациях
Опасность: Неправильные настройки среды выполнения, серверов или библиотек могут оставить приложение уязвимым.
Как действовать: Ограничьте доступ к административным интерфейсам через IP или авторизацию. Не храните конфиденциальные данные (например, ключи API) в коде. Используйте файлы конфигурации или хранилища секретов. Деактивируйте ненужные функции и модули в среде выполнения.

🟠Аутентификация и управление сессиями
Опасность: Угрозы включают угон сессий, слабые пароли и неподтверждённую личность.
Как действовать: Используйте безопасные механизмы аутентификации, такие как OAuth2. Ограничивайте время жизни сессий и добавляйте механизмы их завершения. Убедитесь, что сессионные токены передаются только через защищённые соединения (HTTPS).

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие есть уровни изоляции транзакций?

READ UNCOMMITTED — транзакции видят незавершённые изменения.
READ COMMITTED — видны только зафиксированные изменения.
REPEATABLE READ — данные остаются неизменными во время транзакции.
SERIALIZABLE — транзакции выполняются последовательно.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что такое двухфакторная аутентификация (2FA)?

Это метод подтверждения личности пользователя, который требует предъявления двух различных факторов аутентификации. Эти факторы относятся к разным категориям и обеспечивают дополнительный уровень безопасности по сравнению с одной лишь аутентификацией, например, паролем.

🚩Категории факторов аутентификации

🟠Знание
Например: пароль, PIN-код или ответ на секретный вопрос.
🟠Обладание
Например: одноразовый код из SMS, аппаратный токен, приложение-аутентификатор (Google Authenticator, Authy).
🟠Биометрия
Например: отпечаток пальца, скан лица или радужной оболочки глаза.

🚩Принцип работы

1⃣Пользователь вводит первый фактор — обычно это пароль.
2⃣Система запрашивает второй фактор — например, одноразовый код, отправленный на телефон, или подтверждение через приложение.
3⃣Если оба фактора подтверждены, доступ предоставляется.

🚩Плюсы
➕Повышенная безопасность
Даже если злоумышленник узнает ваш пароль, ему будет сложно получить доступ к устройству или коду второго фактора.
➕Защита от фишинга
Одного украденного пароля недостаточно для получения доступа.
➕Универсальность
Подходит для широкого спектра приложений: от банковских сервисов до социальных сетей.

🚩Примеры реализации

🟠Одноразовые коды (OTP)
Генерируются приложениями-аутентификаторами или отправляются через SMS/email.
🟠Устройства или токены
Физические ключи (например, YubiKey, ключи с поддержкой FIDO2).
🟠Биометрия
Используется как второй фактор в сочетании с паролем.
🟠Push-уведомления
Подтверждение входа через уведомление в мобильном приложении.

🚩Ограничения

🟠Уязвимость SMS-кодов
Возможны атаки через SIM-сваппинг или перехват сообщений.
🟠Зависимость от устройства
Потеря устройства или токена затруднит доступ к аккаунту.
🟠Усложнение процесса входа
Требует больше времени и усилий от пользователя.

Ставь 👍 и забирай 📚 Базу знаний🤔 Что такое двухфакторная аутентификация (2FA)?

Это метод подтверждения личности пользователя, который требует предъявления двух различных факторов аутентификации. Эти факторы относятся к разным категориям и обеспечивают дополнительный уровень безопасности по сравнению с одной лишь аутентификацией, например, паролем.

🚩Категории факторов аутентификации

🟠Знание
Например: пароль, PIN-код или ответ на секретный вопрос.
🟠Обладание
Например: одноразовый код из SMS, аппаратный токен, приложение-аутентификатор (Google Authenticator, Authy).
🟠Биометрия
Например: отпечаток пальца, скан лица или радужной оболочки глаза.

🚩Принцип работы

1⃣Пользователь вводит первый фактор — обычно это пароль.
2⃣Система запрашивает второй фактор — например, одноразовый код, отправленный на телефон, или подтверждение через приложение.
3⃣Если оба фактора подтверждены, доступ предоставляется.

🚩Плюсы

➕Повышенная безопасность
Даже если злоумышленник узнает ваш пароль, ему будет сложно получить доступ к устройству или коду второго фактора.
➕Защита от фишинга
Одного украденного пароля недостаточно для получения доступа.
➕Универсальность
Подходит для широкого спектра приложений: от банковских сервисов до социальных сетей.

🚩Примеры реализации

🟠Одноразовые коды (OTP)
Генерируются приложениями-аутентификаторами или отправляются через SMS/email.
🟠Устройства или токены
Физические ключи (например, YubiKey, ключи с поддержкой FIDO2).
🟠Биометрия
Используется как второй фактор в сочетании с паролем.
🟠Push-уведомления
Подтверждение входа через уведомление в мобильном приложении.

🚩Ограничения

🟠Уязвимость SMS-кодов
Возможны атаки через SIM-сваппинг или перехват сообщений.
🟠Зависимость от устройства
Потеря устройства или токена затруднит доступ к аккаунту.
🟠Усложнение процесса входа
Требует больше времени и усилий от пользователя.

Ставь 👍 и забирай 📚 Базу знаний

🤔 В чем разница char и varchar в SQL?

CHAR — это тип фиксированной длины, используемый для хранения строк одинаковой длины. VARCHAR — это тип переменной длины, который экономит пространство, храня строки в соответствии с их фактическим размером.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Возможность менять реализацию без влияния на клиентскую часть — что это значит?

Эта возможность означает, что изменения во внутренней реализации модуля, класса или сервиса не требуют изменений в коде, который взаимодействует с ним (то есть в клиентской части). Это достигается за счёт строгого разделения интерфейса (контракта) и реализации, что является ключевым принципом инкапсуляции и модульного программирования.

🚩Почему это важно?

🟠Гибкость разработки
Позволяет вносить изменения или улучшения во внутреннюю логику без необходимости модифицировать код, использующий данный компонент.

🟠Снижение затрат на поддержку
Упрощает рефакторинг, обновления или замену компонентов системы.

🟠Стабильность клиентского кода
Клиентский код остаётся неизменным и работает без ошибок, даже если внутренние детали реализации полностью поменялись.

🟠Лёгкость тестирования и замены
Упрощает тестирование и замену частей системы на новые реализации (например, подмена мока на реальную базу данных).

🚩Как это достигается?

🟠Абстракции и интерфейсы
Определяется контракт взаимодействия через интерфейс или абстрактный класс.
Клиентская часть работает с этим контрактом, не зная деталей реализации.
Пример: Интерфейс для работы с хранилищем данных IStorage определяет методы save() и load(). Реализация может быть файловой, базой данных или облачным сервисом.

🟠Принцип подстановки Барбары Лисков (LSP)
Реализация должна быть заменяемой без нарушения работы клиентского кода. Это гарантирует, что изменение реализации не повлияет на функциональность.

🟠Инкапсуляция
Внутренние детали модуля или класса скрыты за чётко определённым интерфейсом. Клиентский код взаимодействует только с публичным API, не имея доступа к внутренним данным или методам.

🟠Принципы SOLID
Принципы проектирования (особенно Dependency Inversion Principle) способствуют отделению деталей реализации от интерфейсов.

🟠Модульность и тестируемость
Модули должны быть максимально независимыми друг от друга. Использование dependency injection (внедрение зависимостей) упрощает замену реализаций.

🚩Пример из практики

🟠Рефакторинг хранилища данных
Клиентская часть работает с интерфейсом IStorage, который предоставляет методы для чтения и записи данных. Изначальная реализация использует локальные файлы. Позже её заменяют на работу с базой данных. Поскольку клиентский код взаимодействует только с IStorage, никаких изменений в нём вносить не нужно.

🟠Изменение алгоритмов
Допустим, класс обрабатывает данные с помощью метода process(). Реализация может меняться (например, использование нового алгоритма), но интерфейс остаётся неизменным, поэтому клиентский код продолжает работать.

🚩Плюсы

➕Упрощение внесения изменений в проект.
➕Снижение рисков, связанных с модификацией кода.
➕Улучшение поддержки и масштабируемости.

Ставь 👍 и забирай 📚 Базу знаний

🤔 В чём различие между LEFT JOIN, RIGHT JOIN и INNER JOIN?

LEFT JOIN возвращает все строки из левой таблицы и соответствующие строки из правой, добавляя NULL, если совпадений нет.
RIGHT JOIN делает то же самое, но с правой таблицей, возвращая NULL для отсутствующих строк из левой таблицы.
INNER JOIN возвращает только строки, где есть совпадения в обеих таблицах.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что такое предохранительный уровень (Anti-Corruption Layer, ACL)?

Это программный слой, предназначенный для защиты одной части системы от нежелательного влияния другой. Его основная задача — изолировать доменную логику вашей системы от сложностей или несовместимостей, возникающих при взаимодействии с внешними системами или устаревшими (легаси) модулями.

🚩Основная идея

Предохранительный уровень действует как адаптер или переводчик, который преобразует данные, протоколы или API одной системы в формат, совместимый с другой. Это позволяет вам сохранить чистоту и целостность внутренней логики вашей системы, не погружаясь в детали внешних систем.

🚩Когда нужен ACL?

🟠Интеграция с устаревшими системами (Legacy Systems)
Когда ваша новая система должна работать с устаревшими модулями, которые имеют несовместимые данные, структуры или API.
🟠Подключение к внешним сервисам
Например, при интеграции с внешним API, который использует сложные или нестандартные форматы данных.
🟠Сложные бизнес-правила
Когда внешняя система не соответствует вашей доменной модели, и требуется преобразование данных для их согласованности.
🟠Управление зависимостями
Для предотвращения прямой зависимости между вашим кодом и внешними библиотеками или сервисами, которые могут меняться.

🚩Как работает ACL?

🟠Инкапсуляция преобразований
ACL скрывает сложную логику преобразования данных или протоколов.
🟠Изолированность доменной модели
Ваша система взаимодействует только с ACL, который предоставляет упрощённый и чистый интерфейс.
🟠Программирование на уровне абстракций
ACL создаёт слой абстракции между вашим кодом и внешней системой.

🚩Плюсы

➕Чистота доменной модели
Ваша бизнес-логика остаётся независимой от деталей внешних систем.
➕Гибкость при изменениях
Изменения в внешних системах минимально затрагивают вашу внутреннюю логику — достаточно адаптировать ACL.
➕Повышение тестируемости
ACL можно тестировать отдельно от основной системы.
➕Снижение технического долга
Защищает от проникновения устаревших решений или несовместимых структур в ваш код.
➕Упрощение поддержки
Уменьшает сложность кода за счёт явного разделения зон ответственности.

🚩Пример использования

🟠Интеграция с внешним API
Ваше приложение взаимодействует с системой оплаты, которая возвращает данные в сложном JSON-формате. ACL преобразует этот JSON в понятный объект вашей системы, например, PaymentDetails.
🟠Работа с легаси-системой
Ваша новая система работает с устаревшей базой данных, где используются нестандартные структуры данных. ACL преобразует SQL-запросы и результаты в объекты вашего приложения, скрывая детали старой структуры.

🚩Как реализовать ACL?

🟠Создайте слой адаптера
Реализуйте интерфейс или набор методов, которые предоставляют доступ к функционалу внешней системы.

🟠Применяйте шаблон "Фасад"
Упростите взаимодействие, предоставив единый интерфейс для вызова сложных операций.

🟠Используйте мапперы
Для преобразования данных из формата внешней системы в объекты вашей системы.

🟠Обеспечьте тестируемость
ACL должен быть изолирован, чтобы можно было проверять преобразования без необходимости вызывать внешнюю систему.

🚩Ограничения ACL

🟠Сложность реализации
Для сложных систем может потребоваться значительное время на проектирование и реализацию ACL.
🟠Оверхед производительности
Преобразования данных или вызовы через ACL могут быть медленнее, чем прямое взаимодействие.
🟠Необходимость обновлений
ACL нужно поддерживать, чтобы он оставался актуальным при изменениях внешних систем.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие бывают ограничения в базе данных?

Ограничения включают:
PRIMARY KEY — уникальный идентификатор строки.
FOREIGN KEY — ссылка на ключ другой таблицы.
UNIQUE — значения в колонке должны быть уникальными.
NOT NULL — значение должно быть задано.
CHECK — проверка выполнения условий.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как правильно написать Thread-Safe Singleton?

Для современного подхода используйте static локальную переменную в методе getInstance, так как ее инициализация гарантированно потокобезопасна.

🚩Принципы реализации

🟠Ограничение создания нескольких экземпляров
Экземпляр создаётся только один раз за всё время жизни приложения.
🟠Безопасность в многопоточности
Реализация должна корректно работать при обращении из нескольких потоков.
🟠Ленивая инициализация
Экземпляр создаётся только тогда, когда он нужен, а не заранее.

🚩Способы реализации

🟠Использование блокировки (Double-Checked Locking)
Включает двойную проверку перед созданием экземпляра. Сначала проверяется, существует ли экземпляр без блокировки, а затем с блокировкой создаётся объект, если он ещё не существует.

public class Singleton {
    // Вариант с volatile для предотвращения оптимизаций компилятора
    private static volatile Singleton instance;

    // Закрытый конструктор для предотвращения создания объекта через `new`
    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) { // Первая проверка (без блокировки)
            synchronized (Singleton.class) { // Блокировка
                if (instance == null) { // Вторая проверка (с блокировкой)
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

🟠Инициализация с помощью внутреннего класса (Bill Pugh Singleton)
Реализуется с помощью статического внутреннего класса. Экземпляр создаётся лениво при первом вызове метода getInstance().

public class Singleton {
    // Закрытый конструктор
    private Singleton() {}

    // Внутренний статический класс
    private static class SingletonHelper {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return SingletonHelper.INSTANCE;
    }
}

🟠Использование Enum
Реализация через enum гарантирует, что будет создан только один экземпляр.

public enum Singleton {
    INSTANCE;

    public void someMethod() {
        // Реализация методов
    }
}

🟠Thread-Safe Singleton на ранней инициализации
Экземпляр создаётся при загрузке класса. Не ленивая, но безопасная и простая.

public class Singleton {
    // Экземпляр создаётся при загрузке класса
    private static final Singleton INSTANCE = new Singleton();

    // Закрытый конструктор
    private Singleton() {}

    public static Singleton getInstance() {
        return INSTANCE;
    }
}

🚩Рекомендации

🟠Используйте Bill Pugh Singleton
Рекомендуется для большинства случаев из-за простоты, потокобезопасности и ленивой инициализации.
🟠Enum Singleton
Идеален, если требуется сериализация или простота реализации, но не подходит для классов, требующих параметров при создании.
🟠Double-Checked Locking
Подходит, если требуется максимальная гибкость, но код становится сложнее.

Ставь 👍 и забирай 📚 Базу знаний

🤔 В чём разница INNER JOIN и RIGHT JOIN?

INNER JOIN возвращает только строки, которые совпадают в обеих таблицах.
RIGHT JOIN возвращает все строки из правой таблицы и соответствующие строки из левой, добавляя NULL, если совпадений нет.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний