Плохая организация кода — это один из главных факторов, который делает поддержку и развитие проекта сложными. Определить, что код плохо организован, можно по следующим признакам:
- Файлы и каталоги разбросаны хаотично.
- Код находится в одном огромном файле без логического разделения.
- Нет четкой модулярности (всё смешано в одном месте).
- Один и тот же фрагмент кода повторяется в разных местах вместо вынесения в отдельные функции или классы.
- При внесении изменений приходится исправлять одну и ту же логику в нескольких местах.
- Функции или методы слишком длинные и делают слишком много.
- Код трудно читать из-за вложенных конструкций (
if, for, while и т. д.).- Используются сложные алгоритмы там, где можно было бы обойтись более простыми.
- Один класс выполняет несколько задач (нарушение *Single Responsibility Principle*).
- Сильная зависимость между модулями (нарушение *Dependency Inversion Principle*).
- Проблемы с расширяемостью кода.
- Используются непонятные или слишком короткие названия (
a, x1, doSomething).- Название не отражает суть выполняемой операции.
- Если документации нет, код сложно понять.
- Если документации слишком много, и она не актуальна, это также мешает.
- Компоненты сильно зависят друг от друга, что усложняет тестирование и внесение изменений.
- Модули не могут использоваться независимо.
- Если код сложно протестировать, это признак плохой организации.
- Нет юнит-тестов или они покрывают только тривиальные случаи.
- Ошибки не логируются, а просто подавляются (
try...catch с пустым catch).- Ошибки обрабатываются хаотично.
- Избыточное потребление памяти или процессорных ресурсов из-за неоптимальных алгоритмов.
- Использование ненужных циклов, повторные вызовы функций.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Это реляционные системы управления базами данных (СУБД), но у них есть значительные различия, которые влияют на выбор той или иной системы в зависимости от проекта.
PostgreSQL — объектно-реляционная СУБД (ORDBMS), поддерживающая расширяемость, сложные структуры данных и расширенные функции. Она использует MVCC (Multiversion Concurrency Control) для обработки транзакций.
MySQL — классическая реляционная СУБД (RDBMS). По умолчанию использует механизм хранения InnoDB, который поддерживает ACID, но менее гибок, чем у PostgreSQL.
PostgreSQL поддерживает более сложные SQL-конструкции, такие как CTE (Common Table Expressions), оконные функции, пользовательские типы данных и полнотекстовый поиск.
MySQL менее гибок в плане сложных SQL-запросов, хотя в новых версиях поддержка CTE и оконных функций была добавлена.
MySQL лучше работает на простых чтениях и небольших нагрузках, особенно в веб-приложениях, где важна скорость выполнения запросов.
PostgreSQL более оптимизирован для сложных аналитических запросов, работы с большими объемами данных и параллельной обработки.
PostgreSQL позволяет добавлять новые типы данных, операторы и даже писать пользовательские функции на различных языках (PL/pgSQL, Python, JavaScript и др.).
MySQL менее гибок, хотя поддерживает хранимые процедуры и триггеры.
PostgreSQL полностью ACID-совместим, поддерживает сложные транзакции и строгую консистентность данных.
MySQL тоже поддерживает ACID (через InnoDB), но раньше его главная фишка была в высокой скорости за счет возможного ослабления требований к консистентности.
MySQL традиционно использовался для масштабирования за счет мастер-слейв репликации и шардинга.
PostgreSQL поддерживает логическую и потоковую репликацию, а также такие расширения, как Citus, позволяющие эффективно масштабировать базу данных горизонтально.
PostgreSQL изначально поддерживает JSONB, что делает его хорошим выбором для гибридных реляционно-документных решений.
MySQL тоже поддерживает JSON, но его функциональность более ограничена.
PostgreSQL — полностью open-source (лицензия PostgreSQL), активно развивается сообществом.
MySQL принадлежит Oracle, и хотя есть open-source-версия, некоторые функции доступны только в коммерческих редакциях.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Это две архитектурные паттерны, которые используются для разделения ответственности и улучшения структуры кода в приложениях. Несмотря на схожие цели, они имеют разные подходы к организации кода и взаимодействию компонентов.
Представляет данные и бизнес-логику. Модель отвечает за получение данных из базы данных, выполнение операций над ними и отправку обновлений обратно в представление через контроллер.
Отображает данные пользователю. Представление отвечает за визуальное представление данных, полученных от модели, и обновление интерфейса в ответ на изменения данных.
Обрабатывает пользовательские вводы и взаимодействует с моделью и представлением. Контроллер получает ввод от пользователя, обрабатывает его (например, валидирует данные), обновляет модель и выбирает соответствующее представление для отображения.
Пользователь взаимодействует с представлением (например, нажимает кнопку).
Контроллер обрабатывает это событие, изменяет данные в модели.
Модель уведомляет представление об изменениях.
Представление обновляет отображение данных для пользователя.
Так же, как и в MVC, модель представляет данные и бизнес-логику. Модель не изменяется.
Отвечает за визуальное представление данных. В отличие от MVC, представление связывается с ViewModel, а не с контроллером.
Посредник между моделью и представлением. ViewModel содержит логику отображения и команду для представления. Он отвечает за преобразование данных из модели в форму, удобную для представления, и наоборот. ViewModel часто использует механизмы связывания данных (data binding) для автоматического обновления представления при изменении данных.
Представление связывается с ViewModel через механизмы привязки данных.
Пользователь взаимодействует с представлением (например, вводит текст).
ViewModel обновляет данные в модели.
Модель уведомляет ViewModel об изменениях.
ViewModel автоматически обновляет представление через привязку данных.
В MVVM используется двустороннее связывание данных между представлением и ViewModel, что упрощает автоматическое обновление UI. В MVC такого механизма нет, и обновление представления осуществляется через контроллер.
В MVC контроллер действует как посредник между моделью и представлением. В MVVM эту роль выполняет ViewModel, который теснее интегрирован с представлением через привязку данных.
MVVM лучше подходит для сложных UI, так как позволяет выносить логику отображения в ViewModel, что делает код представления (UI) более чистым и простым. В MVC логика может оставаться в представлении или контроллере, что иногда усложняет структуру.
MVVM часто используется в приложениях, где активно применяется привязка данных, например, в WPF, Xamarin, Angular. MVC более универсален и часто используется в веб-приложениях (например, ASP.NET MVC).
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Это структура данных, которая позволяет эффективно хранить и извлекать пары "ключ-значение". Она использует хеш-функцию для преобразования ключа в индекс массива, где хранится соответствующее значение.
Это функция, которая принимает ключ и возвращает индекс массива, где должно храниться значение. Хорошая хеш-функция должна равномерно распределять ключи по всему пространству индексов, чтобы минимизировать количество коллизий.
Это ситуации, когда два разных ключа хешируются в один и тот же индекс. Существуют различные методы разрешения коллизий:
Метод цепочек (chaining): В каждой ячейке массива хранится список (или другая структура данных), содержащий все значения, соответствующие этому индексу.
Открытая адресация (open addressing): При коллизии ищется другая свободная ячейка по определённому алгоритму (например, линейное пробирование, квадратичное пробирование или двойное хеширование).
Количество ячеек (бакетов) в массиве. Оптимальный размер зависит от количества ключей и используемой хеш-функции. Обычно размер выбирается простым числом для уменьшения вероятности коллизий.
Хеш-функция вычисляет индекс для ключа.
Если ячейка пуста, значение записывается в неё.
Если ячейка занята (коллизия), применяется выбранный метод разрешения коллизий.
Хеш-функция вычисляет индекс для ключа.
Проверяется ячейка по этому индексу.
Если ключи совпадают, возвращается значение.
Если ключи не совпадают (коллизия), применяется метод разрешения коллизий до нахождения нужного ключа или пустой ячейки (что означает отсутствие ключа).
Хеш-функция вычисляет индекс для ключа.
Элемент удаляется, после чего может потребоваться перемещение других элементов для предотвращения разрыва цепочек или нарушения последовательности в открытой адресации.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM