🤔 Что такое структуры с высоким сцеплением?

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

🚩Что такое сцепление (Coupling)?

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

🟠Низкое сцепление (Low Coupling)
Модули независимы друг от друга и взаимодействуют через чётко определённые интерфейсы.
🟠Высокое сцепление (High Coupling)
Модули тесно связаны и сильно зависят друг от друга, что делает их взаимозависимыми.

🚩Признаки структур с высоким сцеплением

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

🚩Проблемы высоко сцепленных структур
🟠Сложность внесения изменений
При изменении одного компонента другие компоненты, которые зависят от него, также должны быть изменены или протестированы. Например, если модуль A напрямую вызывает функции из модуля B и структура модуля B меняется, то модуль A сломается.

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

🟠Сложность тестирования
Невозможно протестировать отдельные модули из-за их зависимости от других частей системы. Это приводит к сложным и ненадёжным тестам.

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

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

🚩Примеры высокого сцепления

🟠Жёсткая зависимость между классами
Если один класс напрямую создаёт экземпляры других классов или вызывает их методы, это ведёт к высокому сцеплению. Например, если класс OrderProcessor напрямую вызывает методы DatabaseManager и PaymentGateway, то изменения в их логике повлияют на OrderProcessor.

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

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

🚩Как снизить сцепление (добиться Low Coupling)?

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

🟠Dependency Injection (DI)
Внедрение зависимостей позволяет передавать зависимости в модуль извне, что уменьшает их прямую связь.

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

🟠Использование паттернов проектирования
Паттерны, такие как Adapter, Facade, Mediator и Observer, помогают уменьшить прямую зависимость между компонентами.

🟠Разделение ответственности (SRP)
Каждый модуль должен отвечать только за одну задачу. Это делает их более независимыми.

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

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

🤔 Что такое Git-flow?

Это стратегия работы с ветками в Git, которая организует разработку и релизы. Она включает в себя основные ветки: main (или master), develop и временные ветки для новых функций (feature), исправлений (hotfix), релизов (release). Git-flow упрощает управление разработкой, параллельной работой и релизным циклом.

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

🤔 Плюсы и минусы изменяемых и неизменяемых значений?

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

🚩Определения

🟠Изменяемые значения (Mutable)
Это значения или структуры данных, которые могут быть изменены после их создания. Например, массивы, списки и словари в Python или объекты в Java.
🟠Неизменяемые значения (Immutable)
Это значения или структуры данных, которые не могут быть изменены после их создания. Любое изменение приводит к созданию нового объекта. Примеры: строки (string) и кортежи в Python, объекты String в Java, или const в некоторых языках программирования.

🚩Плюсы и минусы изменяемых

➕Эффективное использование памяти
Поскольку изменяемые объекты обновляются "на месте", нет необходимости создавать новые копии объекта, что экономит память.

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

➕Гибкость
Изменяемые объекты более гибкие и удобные для задач, которые требуют частых модификаций, таких как добавление или удаление элементов.

➕Простота записи
Код с изменяемыми объектами часто выглядит проще и чище для операций обновления значений.

➖Неожиданное поведение (побочные эффекты)
При передаче изменяемых объектов между функциями или частями программы их изменение в одном месте может непредсказуемо повлиять на другие части кода.

➖Сложность отладки
Из-за изменения значений "на месте" сложнее отследить, где именно произошло изменение объекта.

➖Проблемы в многопоточных программах
Одновременные изменения одного и того же объекта в разных потоках могут привести к состояниям гонки (race conditions) и другим багам. Это требует дополнительной синхронизации.

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

🚩Плюсы и минусы неизменяемых

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

➕Потокобезопасность (Thread Safety)
Неизменяемые объекты безопасны для многопоточного программирования, так как их состояние не может быть изменено после создания. Это устраняет проблемы синхронизации.

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

➕История изменений и откаты
Благодаря неизменяемости можно сохранять "снимки" состояния программы, что полезно для версирования данных, откатов и реализации undo/redo функциональности.

➕Оптимизация в компиляторах и кэшировании
Неизменяемые объекты могут кэшироваться и повторно использоваться компилятором или средой выполнения, что повышает производительность.

➖Накладные расходы по памяти
При каждом изменении неизменяемого объекта создаётся новая копия, что может привести к большому расходу памяти, особенно при работе с большими данными.

➖Снижение производительности
Создание нового объекта и копирование данных занимает дополнительное время, что может быть медленнее по сравнению с изменяемыми значениями.

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

➖Усложнение кода
Код, работающий с неизменяемыми объектами, может выглядеть более громоздким из-за необходимости создания новых копий при каждом изменении.

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

🤔 Что такое "Сложность алгоритма"?

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

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

🤔 Что такое переполнение стека?

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

🚩Что такое стек?

Это структура данных, работающая по принципу LIFO (*Last In, First Out*, последним пришёл — первым вышел). В контексте программного исполнения стек используется для хранения:
🟠Адресов возврата
Функций при их вызовах.
🟠Локальных переменных
И параметров функции.
🟠Информации о контексте выполнения
Программы.

🚩Причины переполнения стека

🟠Бесконечная рекурсия
Если функция вызывает саму себя бесконечное количество раз без условия завершения, стек будет наполняться до тех пор, пока не исчерпает выделенную память. Функция рекурсивно вызывает саму себя без выхода.

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

🟠Выделение больших локальных переменных
Стек ограничен по размеру, поэтому выделение больших структур или массивов в локальной области функции может быстро исчерпать стек. Пример: создание большого массива как локальной переменной внутри функции.

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

🚩Признаки и последствия переполнения стека

🟠Ошибка времени выполнения
В большинстве языков программирования возникает ошибка StackOverflowError или подобная. В C/C++ это может привести к сегментационному сбою (*segmentation fault*). В Java, Python и других языках будет выброшено исключение о переполнении стека.

🟠Сбой программы
Программа аварийно завершает работу из-за невозможности выделить дополнительное пространство для стека.

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

🚩Как избежать переполнения стека?

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

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

🟠Динамическое выделение памяти
Для больших структур данных используйте кучу (heap) вместо стека для выделения памяти, так как она имеет больший объём доступного пространства.

🟠Контроль размера стека
В некоторых языках можно увеличить размер стека через настройки среды выполнения или компилятора. Например: В C/C++ можно задать размер стека с помощью опций компиляции. В Java размер стека можно увеличить с помощью параметра -Xss.

🟠Анализ кода
Используйте анализаторы статического кода и профилировщики, чтобы найти функции, вызывающие избыточную глубину стека.

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

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

🤔 Какие есть коды ответов HTTP?

1. 1xx (Информационные): уведомления о процессе запроса (например, 100 Continue).
2. 2xx (Успех): успешное выполнение запроса (например, 200 OK, 201 Created).
3. 3xx (Перенаправления): требуется дополнительное действие клиента (например, 301 Moved Permanently, 302 Found).
4. 4xx (Ошибки клиента): проблемы с запросом (например, 400 Bad Request, 401 Unauthorized, 404 Not Found).
5. 5xx (Ошибки сервера): проблемы на стороне сервера (например, 500 Internal Server Error, 503 Service Unavailable).

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

🤔 В чём разница между параллелизмом и многопоточностью?

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

🚩Определения

🟠Параллелизм (Parallelism)
Это одновременное выполнение нескольких задач или частей задачи на нескольких процессорных ядрах или машинах. Он предполагает физический параллельный запуск операций. Например, выполнение двух разных операций одновременно на двух ядрах процессора. Параллелизм направлен на повышение производительности программы за счёт разделения работы.

🟠Многопоточность (Multithreading)
Это техника, при которой одна программа делится на несколько потоков, выполняющихся псевдопараллельно (по очереди или параллельно, в зависимости от количества ядер процессора). Потоки работают в рамках одного процесса и делят общую память. Многопоточность позволяет эффективно использовать ресурсы процессора при переключении между задачами. Она часто используется для работы с I/O-операциями, где потоки могут ожидать данных и не блокировать выполнение программы.

🚩Детальное сравнение

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

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

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

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

🚩Параллелизм и многопоточность вместе

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

🚩Примеры из жизни

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

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

🤔 Какие типы HTTP запросов знаешь? В чём их отличия?

1. GET: запрашивает данные с сервера, без изменения.
2. POST: отправляет данные на сервер для создания ресурса.
3. PUT: обновляет или заменяет данные, может создать новый ресурс.
4. DELETE: удаляет ресурс на сервере.
5. PATCH: частично обновляет ресурс.
6. OPTIONS: возвращает информацию о доступных методах для ресурса.

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

🤔 Почему значение null считается ошибкой?

Значение null считается ошибкой в программировании, потому что оно часто приводит к непредсказуемым ошибкам, сложным для отладки и устранения. Его использование стало настолько проблематичным, что создатель null — Тони Хоар — назвал его "миллиардной ошибкой" из-за огромного количества проблем и уязвимостей, которые оно вызвало.

🚩Почему `null` считается ошибкой?

🟠Проблема отсутствия значения
null используется для обозначения "отсутствия значения", но сама по себе идея "пустоты" вводит двусмысленность в код. Например: "Отсутствует ли значение из-за ошибки, или это нормальное поведение?".

🟠Ошибки времени выполнения (NullPointerException)
Попытка вызвать метод или обратиться к полю объекта, который равен null, приводит к исключению, например, NullPointerException в Java или TypeError в JavaScript. Эти ошибки сложно предсказать на этапе компиляции и они часто приводят к сбоям программы.

String name = null;
int length = name.length(); // NullPointerException

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

🟠Повышенная вероятность ошибок
Каждый раз, когда переменная может быть null, программист должен явно проверять её наличие перед использованием. Это делает код многословным и менее читаемым. Плохой код

if (user != null && user.getAddress() != null) {
    String city = user.getAddress().getCity();
}

🟠Нарушение семантики типов
null не соответствует типу, который описывает переменную. Например, если переменная типа String равна null, то фактически в ней нет строки. Это нарушает типобезопасность и вносит неявное поведение в программу.

🟠Неопределённость и ошибки логики
Часто null используется для обозначения нескольких состояний одновременно: "значение не инициализировано", "значение отсутствует" или "ошибка при получении данных". Это приводит к логическим ошибкам и двусмысленности.

🟠Проблемы в многопоточных приложениях
Если несколько потоков работают с общим объектом, и один из них устанавливает его в null, то другие потоки могут столкнуться с ошибками времени выполнения.

🟠Усложнение кода
Из-за потенциального наличия null разработчики должны добавлять дополнительные проверки, чтобы избежать ошибок. Это делает код менее чистым и увеличивает вероятность пропустить проверку.

🚩Альтернативы значению null

🟠Optional-объекты
В Java, Kotlin и других языках существуют Optional (или аналоги), которые явно представляют "наличие или отсутствие значения". Это заставляет разработчика явно обрабатывать "пустое" состояние.

Optional<String> name = Optional.ofNullable(user.getName());
name.ifPresent(System.out::println);

🟠Монады (Maybe/Option)
В функциональных языках (Haskell, Scala) используются монады Maybe/Option, которые безопасно обрабатывают отсутствие значения.

🟠Инициализация значений по умолчанию
Вместо использования null можно задавать значения по умолчанию, например, пустую строку "" или 0 для чисел.

🟠Null Object Pattern
Это шаблон проектирования, где вместо null используется специальный "пустой объект", который имеет предсказуемое поведение. Например, вместо null можно вернуть объект с "пустыми" методами.

class NullUser extends User {
    @Override
    public String getName() {
        return "Unknown User";
    }
}

🟠Языки с безопасной обработкой

ength = 

В Kotlin и Swift типы разделяются на nullable и non-nullable. Компилятор заставляет разработчика обрабатывать потенциальный null.

val name: String? = null // nullable
println(name?.length) // Безопасный вызов

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

🤔 Что такое Docker?

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

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

🤔 Что такое Request/Reply и Publish/Subscribe?

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

🚩Request/Reply (Запрос/Ответ)

Это коммуникационная модель, при которой один компонент системы отправляет запрос другому компоненту и ожидает ответа.

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

🚩Плюсы и минусы

➕Простая реализация.
➕Подходит для задач, где требуется немедленный результат (например, запрос данных из базы).
➖Уязвимость к задержкам (если один из компонентов медленный, это замедляет всю систему).
➖Меньшая масштабируемость из-за зависимости от синхронности.

🚩Publish/Subscribe (Публикация/Подписка)

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

🟠Асинхронность
Публикация сообщений и их получение подписчиками происходят независимо.
🟠Множественные подписчики
Сообщение может быть отправлено нескольким подписчикам одновременно.
🟠Темы или каналы
Публикация осуществляется в рамках определённых тем или каналов, а подписчики получают только интересующие их сообщения.

🚩Плюсы и минусы

➕Высокая масштабируемость.
➕Уменьшение связности компонентов (компоненты не знают друг о друге напрямую).
➕Асинхронность, позволяющая более эффективно использовать ресурсы.
➖Сложнее отлаживать из-за асинхронного характера.
➖Отсутствие гарантий доставки сообщений без дополнительных механизмов (в зависимости от реализации).

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

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

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

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

🤔 Почему родные и сторонние куки обрабатываются по-разному?

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

🟠Родные куки (First-Party Cookies)
Родные куки создаются доменом, который пользователь непосредственно посещает. Они используются для хранения информации, связанной с сессией пользователя или предпочтениями.
Авторизация пользователя.
Сохранение настроек сайта, таких как язык или тема оформления.
Хранение данных о товарах в корзине интернет-магазина.
Они считаются менее рискованными с точки зрения безопасности и конфиденциальности. Доступ к этим кукам имеет только сайт, который их установил. По умолчанию браузеры предоставляют полный доступ к родным кукам.

🟠Сторонние куки (Third-Party Cookies)
Сторонние куки устанавливаются другим доменом, отличным от того, который пользователь посещает. Обычно это происходит через интеграцию внешних сервисов, таких как рекламные сети, аналитические платформы или социальные виджеты.
Таргетированная реклама.
Аналитика кросс-доменного поведения пользователей.
Ретаргетинг.
Считаются более уязвимыми с точки зрения конфиденциальности, так как позволяют сторонним организациям отслеживать поведение пользователей на множестве сайтов.
Современные браузеры ограничивают или блокируют доступ к сторонним кукам:
Safari (Intelligent Tracking Prevention) и Firefox (Enhanced Tracking Protection) автоматически блокируют сторонние куки.
Google Chrome также планирует отказаться от сторонних куков, заменяя их на Privacy Sandbox.

🟠Причины разного подхода к обработке
a) Защита конфиденциальности
Сторонние куки используются для отслеживания пользователей на разных сайтах, что может нарушать их приватность. Регуляции, такие как GDPR и CCPA, требуют строгого контроля над сбором персональных данных.

b) Минимизация рисков безопасности
Сторонние куки могут быть использованы злоумышленниками для атак (например, CSRF). Ограничение доступа к таким кукам снижает эти риски.

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

d) Регуляторные требования:
Правовые нормы требуют информировать пользователей о сборе данных и получать их согласие. Разные подходы к обработке куков помогают соблюдать эти требования.

🟠Техническая реализация различий
Родные куки доступны только для домена, который их установил, и передаются только в рамках запросов к этому домену. Сторонние куки могут использоваться только если браузер явно разрешает это, либо если сервер настроен для совместимости с современными политиками (например, SameSite=None; Secure).

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

🤔 Какие JOIN бывают?

1. INNER JOIN: возвращает строки, совпадающие в обеих таблицах.
2. LEFT JOIN: возвращает все строки из левой таблицы и совпадающие строки из правой.
3. RIGHT JOIN: возвращает все строки из правой таблицы и совпадающие строки из левой.
4. FULL OUTER JOIN: объединяет все строки из обеих таблиц, заполняя несоответствия NULL.
5. CROSS JOIN: возвращает декартово произведение строк двух таблиц.
6. SELF JOIN: соединяет таблицу саму с собой.

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

🤔 Почему событийно-ориентированная архитектура улучшает масштабируемость?

Событийно-ориентированная архитектура (event-driven architecture, EDA) улучшает масштабируемость за счет асинхронного и независимого взаимодействия между компонентами системы. Основной принцип EDA — использование событий в качестве триггеров для выполнения задач, что устраняет прямую зависимость между инициатором события и его обработчиками. Это позволяет системе более гибко реагировать на рост нагрузки и распределять её между различными частями системы.

🚩Основные причины улучшения масштабируемости в EDA

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

🟠Разделение ответственности
EDA строится на слабой связанности компонентов: каждый сервис отвечает только за обработку определённых событий. Компоненты могут масштабироваться автономно, без влияния на другие части системы. Если в системе интернет-магазина одновременно увеличивается количество заказов и запросов аналитики, можно масштабировать сервис обработки заказов независимо от аналитического сервиса.

🟠Использование очередей и брокеров сообщений
События отправляются в очереди сообщений или брокеры (Kafka, RabbitMQ, AWS SNS/SQS), которые выступают посредниками между производителями и потребителями событий. Это позволяет сглаживать пики нагрузки и временно сохранять события до их обработки, что улучшает масштабируемость. Если нагрузка на обработку увеличивается, можно просто добавить больше обработчиков событий, не изменяя остальную часть системы.

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

🟠События как единицы данных
В EDA события — это четко определённые сообщения, которые передают состояние системы. Это упрощает добавление новых компонентов без изменения существующих. Новые компоненты могут подписываться на события и обрабатывать их, не нарушая текущую логику системы. Аналитическая система может быть подключена для обработки событий о действиях пользователей без необходимости вмешательства в код основной системы.

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

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

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

🤔 Как работает браузер?

1. Обработка запроса: браузер отправляет HTTP-запрос к серверу, чтобы получить HTML-страницу.
2. Парсинг HTML: полученный код анализируется, создаётся DOM-дерево, которое описывает структуру страницы.
3. Загрузка ресурсов: CSS, JavaScript, изображения загружаются асинхронно. CSS формирует CSSOM (модель стилей), объединяясь с DOM.
4. Рендеринг: DOM и CSSOM объединяются в Render Tree, и браузер отображает страницу, выполняя раскладку и отрисовку.
5. JavaScript: выполняется на этапе рендеринга или после загрузки страницы, обновляя DOM.

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

🤔 Основные подводные камни при удалённом вызове процедур (RPC)

Удалённый вызов процедур (Remote Procedure Call, RPC) используется для взаимодействия между компонентами распределённой системы, позволяя одной системе вызывать функции, реализованные в другой. Несмотря на удобство, RPC имеет несколько подводных камней, связанных с особенностями распределённых систем, сетевых взаимодействий и управления состоянием.

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

🟠Задержки (latency)
RPC неизбежно добавляет задержку из-за времени передачи данных по сети и сериализации/десериализации сообщений. Снижение производительности системы при большом количестве вызовов. Минимизировать количество RPC-вызовов, объединяя данные в пакеты. Использовать кеширование на стороне клиента.

🟠Сериализация/Десериализация данных
Передача данных между системами требует их преобразования в формат, понятный обеим сторонам (например, JSON, Protobuf). Потери производительности из-за дополнительной обработки. Потенциальные ошибки преобразования из-за несовместимости форматов. Использовать оптимальные протоколы сериализации (например, Protobuf быстрее и компактнее, чем JSON). Тестировать совместимость форматов при изменении контрактов.

🟠Совместимость API
Изменение интерфейса RPC-сервиса (например, добавление новых параметров) может нарушить работу существующих клиентов. Поломка системы из-за несовместимости старых клиентов с новым API. Применять версионирование API. Использовать backward-compatible изменения (например, добавление необязательных полей).

🟠Отсутствие атомарности
RPC вызывает функции в удалённой системе, где их выполнение не является атомарным (например, если соединение разорвано). Частичное выполнение операций, что может привести к неконсистентности данных. Использовать механизмы транзакций, например, с помощью паттерна Saga для распределённых систем.

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

🟠Сложность отладки
Отладка RPC сложнее из-за распределённого характера системы. Сложно отслеживать вызовы, возникающие между сервисами. Затруднён поиск причин ошибок. Использовать распределённые трейсинг-системы, такие как Jaeger или Zipkin.

🟠Безопасность
RPC вызывает удалённые функции, которые могут быть атакованы злоумышленниками. Утечка данных, несанкционированное выполнение операций. Использовать шифрование (например, TLS). Применять аутентификацию и авторизацию (например, с использованием OAuth или JWT).

🟠Проблемы масштабирования
С ростом нагрузки увеличивается количество RPC-вызовов, что может перегружать сервис. Замедление или отказ системы. Использовать балансировку нагрузки. Проектировать системы с учётом горизонтального масштабирования.

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

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

🤔 Что такое миксины?

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

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

🤔 Как протестировать отказоустойчивость системы?

Отказоустойчивость системы — это её способность продолжать работать в случае отказа компонентов. Тестирование отказоустойчивости (resilience testing) направлено на проверку того, как система ведёт себя при сбоях, выявление уязвимостей и подтверждение эффективности мер по их устранению.

🚩Основные подходы к тестированию отказоустойчивости

🟠Инъекция отказов (Failure Injection Testing)
Этот метод предполагает преднамеренное внесение сбоев в систему, чтобы проверить её реакцию. Используются инструменты или ручные действия для моделирования отказов.
Недоступность узла.
Потеря сети или задержка.
Перегрузка памяти или процессора.

🟠Тестирование высокой нагрузки (Stress Testing)
Моделируется нагрузка, превышающая обычный рабочий уровень, чтобы выявить, какие компоненты начинают отказывать под давлением.
Увеличение количества запросов к API.
Снижение доступных системных ресурсов (памяти, дисковое пространство).

🟠Тестирование восстановления (Recovery Testing)
Проверяется, насколько быстро и корректно система может восстановиться после сбоя.
Перезапуск сервисов.
Переключение на резервные копии данных.

🟠Тестирование с изоляцией (Chaos Engineering)
Моделируются случайные сбои в производственной среде или её имитации для изучения поведения системы.
Chaos Monkey от Netflix.

🚩Что тестировать для отказоустойчивости?

🟠Сетевые сбои
Потеря соединения между сервисами.
Высокая задержка (latency).
Нестабильность сети (пакеты теряются, приходят с ошибками).

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

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

🟠Перегрузка системы
Всплеск количества пользователей.
Увеличение объёма входящих данных (например, в API или БД).

🟠Проблемы с внешними зависимостями
Недоступность внешних API или сервисов.
Непредсказуемое поведение внешних систем (например, возвращают неверные данные).

🚩Методы проведения тестов

🟠Симуляция отказов вручную
Выключение серверов. Уменьшение доступной памяти или процессорных ресурсов. Отключение или замедление сети.

🟠Использование инструментов для тестирования отказов
Chaos Monkey: Генерация случайных сбоев в продакшене.
Gremlin: Моделирование различных видов отказов (сети, ресурсов, зависимостей).
Toxiproxy: Симуляция проблем с сетевым соединением (задержки, потеря пакетов).
Fault Injection Tool (FIT): Моделирование аппаратных и программных сбоев.

🟠Эмуляция перегрузки
Использование инструментов для нагрузочного тестирования, таких как JMeter или Locust, для увеличения нагрузки до критических значений.

🟠Тестирование сценариев восстановления
Ручное или автоматическое выключение сервисов и проверка работы механизмов восстановления (например, перезапусков через Orchestrator типа Kubernetes).

🚩Ключевые показатели эффективности отказоустойчивости

🟠Время простоя
Как долго система остаётся недоступной после сбоя?
🟠Время восстановления (Recovery Time Objective, RTO)
За сколько времени система восстанавливает свою работоспособность?
🟠Потеря данных (Data Loss)
Какой объём данных теряется при сбоях?
🟠Стабильность после восстановления
Система возвращается в нормальное состояние или остаётся уязвимой?

🚩Советы по тестированию отказоустойчивости

🟠Тестировать на всех уровнях
От отдельных компонентов до всей системы.
🟠Автоматизировать тесты
Регулярное выполнение сценариев отказа.
🟠Начинать с изолированной среды
Минимизировать риски в продакшене.
🟠Проводить тесты в реальных условиях
Только в зрелой системе для точных результатов.
🟠Документировать результаты
Для анализа и улучшения системы.

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

🤔 Что такое интерполяция?

Это способ подстановки значений переменных в строку.
• В JavaScript используются шаблонные строки с синтаксисом ${expression}.
• В CSS, например, в препроцессорах (Sass), интерполяция позволяет динамически подставлять значения в свойства.

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

🤔 Проблемы при восстановлении работоспособности системы?

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

🟠Идентификация причины сбоя
Выявление корневой причины (root cause) может быть затруднено в сложных распределённых системах. Ложные сигналы и ошибки усложняют диагностику.
Сбой вызван внешним API, но он маскируется внутренними проблемами. Непредсказуемые сбои в сети.
Использование инструментов для логирования и мониторинга (например, ELK Stack, Prometheus). Внедрение распределённого трейсинга (Jaeger, Zipkin).

🟠Потеря данных
Если данные не были надёжно сохранены, сбой может привести к их потере или неконсистентности.
Запрос был частично обработан перед сбоем. Утеря транзакции из-за недоступности базы данных.
Использовать механизмы журналирования (write-ahead logging). Реализовать стратегии резервного копирования и восстановления (backup & restore). Использовать идемпотентные операции для повторного выполнения.

🟠Недостаточная автоматизация восстановления
Ручное восстановление занимает больше времени и подвержено ошибкам.
Сложная последовательность действий для перезапуска зависимых сервисов. Зависимость от человеческого фактора при переключении на резервные системы.
Автоматизировать восстановление с помощью оркестрации (Kubernetes, Ansible). Внедрить механизмы самовосстановления (self-healing systems).

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

🟠Конфликтующие версии системы
Во время восстановления разные узлы системы могут использовать несовместимые версии программного обеспечения или данных.
Некорректная миграция базы данных. Разные версии микросервисов вызывают ошибки при взаимодействии.
Использовать механизм версионирования API и схем данных. Внедрять "blue-green" или "canary" деплойменты.

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

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

🟠Консистентность данных
После восстановления состояние данных может быть неконсистентным между компонентами.
Пользователь видит устаревшие данные после переключения на резервный сервер. Несогласованные транзакции в распределённых базах данных. Использовать механизмы консенсуса (например, Raft, Paxos). Внедрить стратегии "eventual consistency" для распределённых систем.

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