Backend

🤔 Что делает код хорошим?

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

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

🟠Поддерживаемость
Код должен легко поддаваться изменениям, чтобы можно было адаптировать его под новые требования или исправлять ошибки. Это достигается за счёт модульности, изолирования логики и избегания «жёсткого» связывания частей кода. Хорошая структура и стандартизация, такие как следование принципам SOLID или архитектурным шаблонам (например, MVC), делают код более устойчивым.

🟠 Простота
Хороший код решает задачи самым простым и прямым способом. Простой код легче читать, тестировать и отлаживать. Он избегает ненужных усложнений и излишних абстракций, но при этом остаётся гибким. Следование принципу KISS (Keep It Simple, Stupid) и принципу YAGNI (You Aren't Gonna Need It) помогает держать код простым.

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

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

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

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

🟠Соответствие стилю и стандартам
Код должен соответствовать общим стандартам стиля, принятым в проекте или языке. Это делает его единообразным и легко читаемым для других участников команды. Использование линтеров, форматтеров и следование общеотраслевым стандартам (например, PEP8 для Python) помогает поддерживать единый стиль.

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

🤔 В чём разница между SQL и NoSQL?

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

🟠Архитектура и структура данных
SQL (Structured Query Language) базы данных
Реляционные базы данных: SQL базы данных являются реляционными и используют таблицы для хранения данных. Каждая таблица состоит из строк и столбцов, что позволяет структурировать данные в виде отношений.
Схемы данных: SQL базы данных требуют четко определенных схем (schemas), которые строго контролируют структуру данных. Все записи в таблице должны следовать заранее определенной структуре.
Язык запросов: SQL использует структурированный язык запросов для манипуляции данными. Язык SQL стандартизирован и включает команды для создания, чтения, обновления и удаления данных (CRUD).
🟠NoSQL (Not Only SQL)
Нереляционные базы данных: NoSQL базы данных не обязательно используют таблицы для хранения данных. Вместо этого они могут использовать различные модели данных, такие как документы, графы, ключ-значение и столбцы
Гибкость схем: NoSQL базы данных часто не требуют фиксированных схем. Это позволяет хранить данные разной структуры в одной и той же коллекции или таблице.
Разнообразие языков запросов: В NoSQL базах данных отсутствует единый стандарт языка запросов. Они могут использовать различные методы доступа к данным, включая REST API и собственные языки запросов.

🚩Масштабируемость и производительность

🟠SQL базы данных
Вертикальная масштабируемость: SQL базы данных обычно масштабируются вертикально, то есть увеличивая мощность сервера (CPU, RAM, дисковое пространство).
Транзакции и консистентность: SQL базы данных поддерживают ACID транзакции (Atomicity, Consistency, Isolation, Durability), что обеспечивает высокую надежность и консистентность данных.
🟠NoSQL базы данных
Горизонтальная масштабируемость: NoSQL базы данных предназначены для горизонтального масштабирования, что позволяет распределять данные по множеству серверов.
Гибкость и скорость: NoSQL базы данных обычно более гибки и могут обеспечивать высокую производительность при работе с большими объемами данных и высокими нагрузками на запись и чтение.

🚩Использование и примеры

🟠SQL базы данных
MySQL, PostgreSQL, Oracle, Microsoft SQL Server.
Финансовые системы, системы управления запасами, системы управления клиентами (CRM), где требуется сложные запросы и транзакции.
🟠NoSQL базы данных
MongoDB, Cassandra, Redis, Couchbase.
Системы больших данных, реального времени аналитика, социальные сети, приложения для интернета вещей (IoT), где требуется высокая производительность и гибкость.

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

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

Один из основных принципов объектно-ориентированного программирования (ООП), наряду с наследованием и полиморфизмом. Смысл инкапсуляции заключается в объединении данных и методов, работающих с этими данными, в одном объекте, а также в ограничении доступа к этим данным из внешнего мира.

🚩Основные аспекты инкапсуляции

🟠Сокрытие данных
В инкапсуляции данные (свойства) объекта скрываются от внешнего доступа и защищаются от некорректных изменений. Это достигается путем использования модификаторов доступа (например, private, protected, public).

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

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

🚩Примеры инкапсуляции

На Java

public class Person {
    private String name;
    private int age;

    // Конструктор
    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    // Геттер для имени
    public String getName() {
        return name;
    }

    // Сеттер для имени
    public void setName(String name) {
        this.name = name;
    }

    // Геттер для возраста
    public int getAge() {
        return age;
    }

    // Сеттер для возраста
    public void setAge(int age) {
        if (age > 0) {
            this.age = age;
        } else {
            System.out.println("Возраст должен быть положительным числом.");
        }
    }
}

На Python

class Person:
    def __init__(self, name, age):
        self._name = name
        self._age = age

    # Геттер для имени
    @property
    def name(self):
        return self._name

    # Сеттер для имени
    @name.setter
    def name(self, name):
        self._name = name

    # Геттер для возраста
    @property
    def age(self):
        return self._age

    # Сеттер для возраста
    @age.setter
    def age(self, age):
        if age > 0:
            self._age = age
        else:
            print("Возраст должен быть положительным числом.")

# Пример использования
person = Person("John", 30)
print(person.name)  # John
person.age = -5  # Возраст должен быть положительным числом.
print(person.age)  # 30

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

🤔 Что такое Docker Compose?

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

🚩Функции

🟠Определение многоконтейнерного приложения
Docker Compose использует YAML-файл (docker-compose.yml) для описания всех контейнеров (сервисов), которые составляют ваше приложение. В этом файле можно указать образы, настройки сети, монтируемые тома и переменные окружения.

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

🟠Запуск и остановка сервисов
С помощью простой команды docker-compose up можно запустить все контейнеры, указанные в docker-compose.yml. Команда docker-compose down останавливает и удаляет все контейнеры, сети и тома, созданные up.

🟠Поддержка масштабирования
Можно легко масштабировать сервисы (запускать несколько экземпляров одного контейнера) с помощью команды docker-compose up --scale.

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

docker-compose.yml для веб-приложения, состоящего из веб-сервера и базы данных:

version: '3'
services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - ./html:/usr/share/nginx/html
    depends_on:
      - db

  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: example
    volumes:
      - db_data:/var/lib/mysql

volumes:
  db_data:

🚩Команды

🟠docker-compose up
Создает и запускает все контейнеры, указанные в docker-compose.yml.
🟠docker-compose down
Останавливает и удаляет все контейнеры, сети и тома, созданные docker-compose up.
🟠docker-compose ps
Показывает статус запущенных контейнеров.
🟠docker-compose logs
Выводит логи всех контейнеров.
🟠docker-compose exec [service] [command]
Выполняет команду в запущенном контейнере.

🚩Плюсы

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

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

🤔 Что такое ACID?

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

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

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

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

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

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

🤔 Чем отличается RIGHT, LEFT, INNER, JOIN?

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

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

🟠LEFT JOIN (или LEFT OUTER JOIN)
Возвращает все строки из левой таблицы, а из правой – только совпадающие. Если в правой таблице нет совпадения, в итоговом наборе будут NULL-значения.

🟠RIGHT JOIN (или RIGHT OUTER JOIN)
Возвращает все строки из правой таблицы, а из левой – только совпадающие. Если в левой таблице нет соответствующего значения, в результате появятся NULL.

🟠FULL JOIN (или FULL OUTER JOIN)
Возвращает все строки из обеих таблиц. Если в одной из таблиц нет соответствующей записи, подставляются NULL.

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

Пожизненная PRO подписка на easyoffer по цене одного года.

Акция до 20 февраля. Покупаешь сейчас один раз – пользуешься всю жизнь без лимита, включая все будущие функции.

Запланированные новые фичи на ближайшие пол года:
1. Агрегатор вакансий
2. Улучшение резюме, чтобы проходить ATS системы
3. Генерация уникального резюме и сопроводительного письма под вакансию

Покупай на https://easyoffer.ru/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🤔 Примеры систем CP, AP и CA?

В контексте CAP-теоремы(Consistency, Availability, Partition Tolerance) системы обычно делят на три группы: CP (Consistency + Partition Tolerance), AP (Availability + Partition Tolerance) и CA (Consistency + Availability).

🚩CP-системы (Consistency + Partition Tolerance)

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

🟠HBase и MongoDB в режиме CP
Оба эти хранилища данных поддерживают согласованность при сетевых сбоях, но могут ограничивать доступность данных, блокируя операции до восстановления связи.

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

🚩AP-системы (Availability + Partition Tolerance)

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

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

🟠DynamoDB (режим AP)
Поддерживает доступность и устойчивость к разделению сети, за счёт возможного отклонения в согласованности. DynamoDB был разработан Amazon для обеспечения высокой доступности даже в условиях сбоя сети.

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

🚩CA-системы (Consistency + Availability)

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

🟠Реляционные базы данных на одном сервере
Например, PostgreSQL или MySQL в традиционной конфигурации, работающей на одном сервере без распределения данных. Они поддерживают согласованность и доступность, так как нет сетевого разделения.
🟠Системы кэширования в локальной сети
Такие системы, как Redis, при отсутствии распределённой конфигурации и работе в пределах одного узла, могут обеспечить согласованность и доступность.

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

🤔 Что такое идемпотентность?

Идемпотентность — это свойство операции, при котором повторное выполнение этой операции приводит к тому же результату, что и однократное выполнение. Это понятие часто используется в контексте HTTP методов, API запросов и транзакций в системах с распределенной архитектурой.

🚩Основные аспекты идемпотентности

🟠Идемпотентные операции
GET: Получение ресурса. Повторный запрос не изменяет состояние ресурса.
PUT: Обновление или создание ресурса. Повторный запрос с одинаковыми данными приводит к одному и тому же состоянию ресурса.
DELETE: Удаление ресурса. Повторный запрос удаляет ресурс, если он существует, или не изменяет состояние, если ресурс уже удален.

🟠Неидемпотентные операции
POST: Создание нового ресурса. Повторный запрос приводит к созданию нового ресурса с новым идентификатором, что изменяет состояние системы.

🚩Примеры идемпотентности

GET запрос

  GET /user/123

PUT запрос

  PUT /user/123
  {
      "name": "John Doe",
      "age": 30
  }

Идемпотентная операция

  UPDATE users SET name = 'John Doe' WHERE id = 123;

Неидемпотентная операция

  INSERT INTO users (name, age) VALUES ('John Doe', 30);

🚩Зачем нужна идемпотентность

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

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

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

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

🤔 Как обнаружить самые затратные запросы?

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

🚩Включение логирования медленных запросов (Slow Query Logging)

Многие системы управления базами данных (СУБД) поддерживают логирование запросов, выполнение которых занимает больше определённого времени.

🟠MySQL
Используйте slow_query_log. Активировать лог:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1; -- Время выполнения в секундах

🟠PostgreSQL
Включите log_min_duration_statement.

SET log_min_duration_statement = 1000; -- Логировать запросы, выполняющиеся более 1 секунды

🚩Использование EXPLAIN или ANALYZE

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

MySQL

EXPLAIN SELECT * FROM orders WHERE status = 'pending';

PostgreSQL

EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE status = 'pending';

🚩Использование системных представлений и мониторинга запросов

🟠MySQL
Используйте таблицу performance_schema для анализа запросов.

SELECT * FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

🟠PostgreSQL
Используйте расширение pg_stat_statements.

CREATE EXTENSION pg_stat_statements;

Получите информацию

SELECT query, calls, total_time, mean_time
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 10;

🚩Мониторинг с использованием внешних инструментов

🟠New Relic
Проводит анализ SQL-запросов, показывая самые медленные.
🟠Datadog
Позволяет отслеживать производительность запросов в реальном времени.
🟠SolarWinds DPA (Database Performance Analyzer)
Специализированный инструмент для анализа производительности баз данных.

🚩Оптимизация индексов

🟠MySQL

SELECT * FROM sys.schema_unused_indexes;

🟠PostgreSQL
Проверьте в плане выполнения запросов (EXPLAIN), используются ли индексы.

🚩Нагрузочное тестирование (Load Testing)

Используйте нагрузочные тесты, чтобы выявить запросы, создающие "бутылочные горлышки":
🟠Apache JMeter
Симулирует многопоточную нагрузку на базу данных.
🟠Gatling
Анализирует производительность системы под высокой нагрузкой.

🚩Анализ трассировки запросов

Включите трассировку (например, в MySQL — SHOW PROFILE):

SET profiling = 1;
SELECT * FROM orders WHERE status = 'pending';
SHOW PROFILE FOR QUERY 1;

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

🤔 Что такое ORM?

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

🚩Основные особенности ORM

🟠Абстракция базы данных
ORM позволяет разработчикам работать с базой данных через объекты, не написав SQL-код напрямую. Это упрощает разработку и делает код более читабельным и поддерживаемым.

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

🟠Автоматическое управление связями
ORM поддерживает управление отношениями между объектами, такими как "один-к-одному", "один-ко-многим" и "многие-ко-многим".

🟠Кэширование и оптимизация запросов
ORM может кешировать запросы и результаты для улучшения производительности.

🚩Плюсы

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

➕Поддерживаемость
Код на ORM более понятен и легко поддерживается, поскольку использует объектно-ориентированные принципы.

➕Безопасность
ORM помогает избежать SQL-инъекций, так как запросы строятся с помощью методов и свойств классов.

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

🚩Популярные библиотеки и фреймворки ORM

🟠Hibernate
Java
🟠Entity Framework
.NET
🟠Django ORM
Python
🟠SQLAlchemy
Python
🟠ActiveRecord
Ruby on Rails

🚩Примеры

Модель

from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)
    birth_date = models.DateField()

class Book(models.Model):
    title = models.CharField(max_length=100)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

Создание записи

author = Author(name='J.K. Rowling', birth_date='1965-07-31')
author.save()

book = Book(title='Harry Potter and the Philosopher\'s Stone', author=author)
book.save()

Извлечение данных

books = Book.objects.filter(author__name='J.K. Rowling')
for book in books:
    print(book.title)

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

🤔 В чем разница между MVC и MVVM?

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

🚩MVC (Model-View-Controller)

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

🟠View (Представление)
Отображает данные пользователю. Представление отвечает за визуальное представление данных, полученных от модели, и обновление интерфейса в ответ на изменения данных.

🟠Controller (Контроллер)
Обрабатывает пользовательские вводы и взаимодействует с моделью и представлением. Контроллер получает ввод от пользователя, обрабатывает его (например, валидирует данные), обновляет модель и выбирает соответствующее представление для отображения.

Пользователь взаимодействует с представлением (например, нажимает кнопку).
Контроллер обрабатывает это событие, изменяет данные в модели.
Модель уведомляет представление об изменениях.
Представление обновляет отображение данных для пользователя.

🚩MVVM (Model-View-ViewModel)

🟠Model (Модель)
Так же, как и в MVC, модель представляет данные и бизнес-логику. Модель не изменяется.

🟠View (Представление)
Отвечает за визуальное представление данных. В отличие от MVC, представление связывается с ViewModel, а не с контроллером.

🟠ViewModel (Модель представления)
Посредник между моделью и представлением. ViewModel содержит логику отображения и команду для представления. Он отвечает за преобразование данных из модели в форму, удобную для представления, и наоборот. ViewModel часто использует механизмы связывания данных (data binding) для автоматического обновления представления при изменении данных.

Представление связывается с ViewModel через механизмы привязки данных.
Пользователь взаимодействует с представлением (например, вводит текст).
ViewModel обновляет данные в модели.
Модель уведомляет ViewModel об изменениях.
ViewModel автоматически обновляет представление через привязку данных.

🚩Основные различия

🟠Связывание данных
В MVVM используется двустороннее связывание данных между представлением и ViewModel, что упрощает автоматическое обновление UI. В MVC такого механизма нет, и обновление представления осуществляется через контроллер.

🟠Посредник
В MVC контроллер действует как посредник между моделью и представлением. В MVVM эту роль выполняет ViewModel, который теснее интегрирован с представлением через привязку данных.

🟠Упрощение UI-логики
MVVM лучше подходит для сложных UI, так как позволяет выносить логику отображения в ViewModel, что делает код представления (UI) более чистым и простым. В MVC логика может оставаться в представлении или контроллере, что иногда усложняет структуру.

🟠Технологическая направленность
MVVM часто используется в приложениях, где активно применяется привязка данных, например, в WPF, Xamarin, Angular. MVC более универсален и часто используется в веб-приложениях (например, ASP.NET MVC).

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

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

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

🚩Проблемы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🤔 Какие существуют типы баз данных?

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

🟠Реляционные базы данных (RDBMS)
Организуют данные в таблицы с заранее определенными схемами. Используют SQL для управления данными. MySQL, PostgreSQL, Oracle, Microsoft SQL Server.

🟠Документные базы данных (Document-Oriented)
Хранят данные в виде документов (обычно в формате JSON или BSON), что позволяет хранить сложные и гибкие структуры данных. MongoDB, CouchDB.

🟠Колонковые базы данных (Columnar)
Хранят данные столбцами вместо строк, что оптимизирует производительность для операций чтения и агрегации. Apache Cassandra, HBase.

🟠Ключ-значение базы данных (Key-Value)
Хранят данные в виде пар "ключ-значение", что позволяет быстрое извлечение данных по ключу. Redis, Riak, Amazon DynamoDB.

🟠Графовые базы данных (Graph)
Оптимизированы для хранения и обработки графовых структур, таких как узлы, ребра и свойства, что удобно для социальных сетей, рекомендательных систем и др. Neo4j, ArangoDB, Amazon Neptune.

🟠Базы данных временных рядов (Time Series)
Специализируются на хранении и анализе временных рядов данных, таких как метрики, события или показания датчиков. InfluxDB, TimescaleDB.

🟠Базы данных на основе объектов (Object-Oriented)
Хранят данные в виде объектов, как в объектно-ориентированном программировании, что позволяет хранить более сложные структуры данных. db4o, ObjectDB.

🟠Многомодельные базы данных (Multi-Model)
Поддерживают несколько типов моделей данных (например, реляционные, документные, графовые) в рамках одной базы данных. ArangoDB, OrientDB.

🟠Базы данных, ориентированные на массивы (Array)
Оптимизированы для работы с большими массивами данных, часто используемыми в научных вычислениях и аналитике. SciDB, Rasdaman.

🟠Распределенные базы данных (Distributed)
Распределяют данные по нескольким узлам или серверам, обеспечивая масштабируемость и отказоустойчивость. Google Spanner, CockroachDB.

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

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

В реляционных базах данных, операции объединения (JOIN) позволяют объединить строки из двух или более таблиц на основе связанных между собой столбцов. Существует несколько типов JOIN, каждый из которых имеет свои особенности и применим для разных ситуаций. Рассмотрим основные типы JOIN:

🟠INNER JOIN
Объединяет строки из обеих таблиц, если они удовлетворяют условию объединения. Когда необходимо выбрать только те строки, которые имеют соответствующие значения в обеих таблицах.

SELECT *
FROM таблица1
INNER JOIN таблица2
ON таблица1.ключ = таблица2.ключ;

🟠LEFT JOIN (или LEFT OUTER JOIN)
Возвращает все строки из левой таблицы и соответствующие строки из правой таблицы. Если соответствующей строки в правой таблице нет, в результирующем наборе данных для столбцов правой таблицы будут значения NULL. Когда необходимо выбрать все строки из одной таблицы и соответствующие данные из другой таблицы, если они существуют.

SELECT *
FROM таблица1
LEFT JOIN таблица2
ON таблица1.ключ = таблица2.ключ;

🟠RIGHT JOIN (или RIGHT OUTER JOIN)
Возвращает все строки из правой таблицы и соответствующие строки из левой таблицы. Если соответствующей строки в левой таблице нет, в результирующем наборе данных для столбцов левой таблицы будут значения NULL. Когда необходимо выбрать все строки из одной таблицы (правой) и соответствующие данные из другой таблицы (левой), если они существуют.

SELECT *
FROM таблица1
RIGHT JOIN таблица2
ON таблица1.ключ = таблица2.ключ;

🟠FULL JOIN (или FULL OUTER JOIN)
Возвращает все строки, когда есть совпадения либо в левой, либо в правой таблице. Если строки не соответствуют в одной из таблиц, для этой таблицы будут значения NULL. Когда необходимо выбрать все строки из обеих таблиц, независимо от того, есть ли соответствующие строки в другой таблице.

SELECT *
FROM таблица1
FULL JOIN таблица2
ON таблица1.ключ = таблица2.ключ;

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

SELECT *
FROM таблица1
CROSS JOIN таблица2;

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

SELECT A.*
FROM таблица A, таблица B
WHERE A.ключ = B.ключ;

🟠NATURAL JOIN
Автоматически объединяет таблицы по всем столбцам с одинаковыми именами и типами данных. Когда у таблиц есть столбцы с одинаковыми именами, и нужно объединить их без явного указания условий объединения.

SELECT *
FROM таблица1
NATURAL JOIN таблица2;

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

🤔 Какие связи с моделями в БД знаешь?

🚩"Один к одному" (One-to-One)

Каждая запись в одной таблице связана с одной и только одной записью в другой таблице.

Пользователь (User) и Паспорт (Passport)
Каждому пользователю соответствует один уникальный паспорт. В реляционных базах данных можно реализовать эту связь с помощью уникального внешнего ключа.

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100)
);

CREATE TABLE passports (
  id SERIAL PRIMARY KEY,
  user_id INTEGER UNIQUE,
  passport_number VARCHAR(50),
  FOREIGN KEY (user_id) REFERENCES users(id)
);

🚩"Один ко многим" (One-to-Many)

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

Пользователь (User) и Заказы (Orders)
Один пользователь может сделать много заказов, но каждый заказ связан с одним пользователем. Эта связь обычно реализуется с помощью внешнего ключа.

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100)
);

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INTEGER,
  order_date DATE,
  FOREIGN KEY (user_id) REFERENCES users(id)
);

🚩"Многие ко многим" (Many-to-Many)

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

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

CREATE TABLE students (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100)
);

CREATE TABLE courses (
  id SERIAL PRIMARY KEY,
  course_name VARCHAR(100)
);

CREATE TABLE student_courses (
  student_id INTEGER,
  course_id INTEGER,
  PRIMARY KEY (student_id, course_id),
  FOREIGN KEY (student_id) REFERENCES students(id),
  FOREIGN KEY (course_id) REFERENCES courses(id)
);

🚩Варианты связей в нереляционных базах данных (NoSQL)

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

Вложенные документы
Например, в MongoDB документы могут включать вложенные документы или массивы, что позволяет моделировать отношения "один ко многим" и "многие ко многим" внутри одного документа.

{
  "_id": 1,
  "name": "John",
  "orders": [
    { "order_id": 1, "order_date": "2023-08-01" },
    { "order_id": 2, "order_date": "2023-08-05" }
  ]
}

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

🤔 В чём разница InnerJoin и RightJoin ?


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

🚩`INNER JOIN`

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

SELECT A.*, B.*
FROM TableA A
INNER JOIN TableB B ON A.id = B.id;

🚩`RIGHT JOIN` (или `RIGHT OUTER JOIN`)

RIGHT JOIN возвращает все строки из правой таблицы (TableB) и совпадающие строки из левой таблицы (TableA). Если совпадения нет, строки из правой таблицы все равно включаются в результат с NULL значениями для столбцов из левой таблицы.

SELECT A.*, B.*
FROM TableA A
RIGHT JOIN TableB B ON A.id = B.id;

🚩Основные различия

🟠INNER JOIN
Возвращает только строки с совпадающими значениями в обеих таблицах. Исключает строки без совпадений.
🟠RIGHT JOIN
Возвращает все строки из правой таблицы (TableB) и совпадающие строки из левой таблицы (TableA). Включает строки из правой таблицы, даже если нет совпадений, с NULL значениями для столбцов из левой таблицы.

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

🤔 Что такое cherrypick?

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

🚩Основные аспекты cherry-pick

🟠Избирательное применение коммитов
Позволяет выбрать конкретные изменения из истории одной ветки и перенести их в другую ветку.
🟠Избежание полного слияния
В отличие от обычного слияния (merge), cherry-pick переносит только выбранные коммиты, а не всю историю изменений.

🚩Как использовать cherry-pick

Основной синтаксис

git cherry-pick <commit_hash>

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

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

git checkout target-branch

🟠Применение коммита
Используйте команду cherry-pick, чтобы применить нужный коммит.

git cherry-pick a1b2c3d4 

🟠Решение конфликтов (если они возникли)
Если во время cherry-pick возникают конфликты, Git предложит их решить. Разрешите конфликты, затем завершите процесс:

git add <resolved_files>
git cherry-pick --continue

Предположим, у вас есть коммит с хешем a1b2c3d4 в ветке feature-branch, который вы хотите перенести в main-branch.

git checkout main-branch
git cherry-pick a1b2c3d4

🚩Когда использовать cherry-pick

🟠Перенос исправлений
Когда нужно быстро перенести исправление из одной ветки в другую (например, багфикс из develop в release).
🟠Избирательное применение новых функций
Когда нужно перенести конкретную функцию или изменение без переноса всей ветки.

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

🟠Конфликты
Перенос коммитов может вызвать конфликты, особенно если изменяемые файлы были модифицированы в целевой ветке.
🟠Историческая чистота
Частое использование cherry-pick может запутать историю изменений, так как один и тот же коммит будет существовать в нескольких ветках с разными хешами.

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

🤔 Основные HTTP-методы

HTTP-методы (или глаголы) определяют тип действия, которое клиент хочет выполнить с ресурсом на сервере.

🟠GET
Назначение: Получение данных с сервера. Используется для чтения информации, не изменяя состояние сервера. Безопасный и идемпотентный метод (выполнение одного и того же запроса несколько раз даёт одинаковый результат).
Запрос страницы или API-ресурса

GET /users/123

🟠POST
Назначение: Создание нового ресурса или выполнение действий на сервере. Может изменять состояние сервера (например, добавлять новые данные). Не идемпотентен (повторный запрос создаёт новый ресурс или дублирует операцию).
Создание нового пользователя

POST /users

🟠PUT
Назначение: Полное обновление ресурса на сервере. Идемпотентен (повторный запрос с одинаковыми данными не изменяет результат).
Обновление профиля пользователя:

PUT /users/123

🟠PATCH
Назначение: Частичное обновление ресурса. Обновляет только указанные поля, не затрагивая остальные. Не всегда идемпотентен (зависит от реализации).
Обновление только имени пользователя

PATCH /users/123

🟠DELETE
Назначение: Удаление ресурса с сервера. Идемпотентен (повторный запрос удаления того же ресурса не вызывает ошибку).
Удаление пользователя

DELETE /users/123

🟠HEAD
Назначение: Получение метаинформации о ресурсе без передачи его содержимого. Аналогичен GET, но сервер возвращает только заголовки ответа. Полезен для проверки существования ресурса или его свойств (например, размера).

HEAD /users/123

🟠OPTIONS
Назначение: Запрос информации о поддерживаемых сервером методах или возможностях ресурса. Используется, например, в CORS для проверки, какие методы доступны для клиента.

OPTIONS /users

🟠TRACE
Назначение: Диагностика и отладка соединения между клиентом и сервером. Возвращает запрос клиента в теле ответа, позволяя понять, какие изменения произошли на пути от клиента до сервера. Редко используется из-за риска безопасности.

TRACE /users/123

🟠CONNECT
Назначение: Установка туннеля для защищённого соединения (например, через прокси). Чаще всего используется для создания HTTPS-соединений.

CONNECT www.example.com:443

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