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

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

🚩Проблемы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🟠Покрытие тестами
Перед внесением изменений напишите базовые 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, если совпадений нет.

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

🤔 Как тесты и TDD влияют на организацию кода?

Тесты и подход разработки через тестирование (Test-Driven Development, TDD) оказывают значительное влияние на структуру, организацию и качество кода. Они стимулируют разработчиков писать более чистый, модульный и тестируемый код, следуя принципам хорошего дизайна.

🟠Декомпозиция и модульность
Как тесты влияют: Для удобства тестирования разработчики разделяют большие методы и классы на мелкие, с чёткими зонами ответственности. В результате код становится более модульным, а его компоненты проще повторно использовать и изменять.

🟠Снижение зависимости (Loose Coupling)
Как тесты влияют: Для изолированного тестирования классов и методов зависимости инвертируются и предоставляются через интерфейсы или моки. Это приводит к использованию принципа инверсии зависимостей (Dependency Inversion Principle) и снижению связности между модулями.

🟠Чёткая ответственность (Single Responsibility Principle, SRP)
Как тесты влияют: Если метод или класс берёт на себя слишком много обязанностей, тестировать его становится сложно. Это побуждает разработчиков разделять функциональность, соблюдая SRP.

🟠Улучшение проектирования интерфейсов
Как тесты влияют: Разработка через тесты требует определения интерфейсов и API до написания кода. Интерфейсы проектируются с упором на удобство использования, минимальный набор методов и простоту.

🟠Стимуляция рефакторинга
Как тесты влияют: Наличие тестов создаёт уверенность, что изменения в коде не сломают существующую функциональность. Это стимулирует регулярный рефакторинг, что улучшает организацию и качество кода.

🟠Документация кода через тесты
Как тесты влияют: Хорошо написанные тесты документируют ожидаемое поведение кода, показывая, как он должен использоваться и какие результаты ожидать.

🟠Принципы разработки (SOLID, KISS, DRY)
Как тесты влияют: Чтобы код был тестируемым, разработчики чаще соблюдают принципы проектирования:
SOLID: Принципы проектирования для создания гибких и расширяемых систем.
KISS: Сохранение кода простым.
DRY: Избежание повторений.

🟠Мотивация к изоляции побочных эффектов
Как тесты влияют: Чтобы упростить тестирование, разработчики изолируют побочные эффекты (например, работу с БД, сетью, файловой системой) в отдельных компонентах.

🟠Обнаружение ошибок на ранних этапах
Как тесты влияют: Написание тестов до основного кода (TDD) выявляет проблемы в проектировании и требованиях на ранних стадиях.

🚩Ограничения и потенциальные проблемы

🟠Избыточность тестов
Если тесты плохо написаны, это может усложнить рефакторинг.
🟠Временные затраты
Написание тестов занимает больше времени на ранних этапах, но окупается в долгосрочной перспективе.
🟠Кривая обучения
Новички могут столкнуться с трудностями при проектировании тестируемого кода.

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

🤔 Как "под капотом" работает аннотация @Transactional?

Аннотация @Transactional в Spring использует прокси для перехвата методов и управления транзакциями. Перед выполнением метода создаётся или используется существующая транзакция, а после выполнения транзакция коммитится или откатывается в случае исключения.

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

🤔 Проблема N+1 и её решение?

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

🚩Как проявляется?

Представим, что у нас есть две сущности: User и связанные с ним Posts. Приложение запрашивает список всех пользователей, а затем для каждого пользователя делает отдельный запрос, чтобы получить связанные с ним посты. Вместо одного запроса к базе данных выполняется: Один запрос для получения всех пользователей. N запросов для получения постов каждого пользователя.
Итог: N+1 запросов.
Это неэффективно, так как количество запросов растёт линейно с увеличением количества данных, что приводит к большим задержкам.

🚩Причины возникновения
🟠Неправильная настройка ORM (например, использование ленивой загрузки (`lazy loading`)).
🟠Невнимательность при проектировании архитектуры приложения.
🟠Недостаток оптимизации при составлении SQL-запросов.

🚩Подходы к решению проблемы

🟠Жадная загрузка (Eager Loading)
Вместо выполнения N отдельных запросов для связанных данных, ORM можно настроить так, чтобы они загружались вместе с основным запросом. Например: В Hibernate это можно сделать с помощью fetch join. В Django ORM используется метод select_related() или prefetch_related().

🟠Оптимизация SQL-запросов вручную
Иногда автоматическая оптимизация ORM не работает идеально. В таких случаях можно написать кастомные SQL-запросы, используя соединения (JOIN) для получения всех необходимых данных в одном запросе.

🟠Кэширование
Если данные редко меняются, можно использовать кэш (например, Redis или Memcached), чтобы минимизировать количество обращений к базе данных.

🟠Анализ запросов
Использование инструментов мониторинга запросов (например, SQLAlchemy профайлеры или Django Debug Toolbar) позволяет вовремя выявить проблему N+1 и устранить её.

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

🤔 Расскажи про уровни изоляции?

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

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