Git. Обзор и подборка материалов

В связи всё более широким распространением подхода Docs as Code самое время изучить Git.

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

Git позволяет:
💩Хранить историю изменений проекта. Git может определить, кто и в какой момент внёс изменения.
💩Параллельно работать над файлами. Все изменения затем сливаются воедино.
💩Откатиться к предыдущим версиям проекта, если что-то пойдёт не так.

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

1️⃣Разработчик создаёт свою ветку от главного проекта, куда вносит свои изменения
2️⃣В своей ветке разработчик делает необходимые изменения в коде или документации, которые затем фиксируются в истории изменений.
3️⃣После того как работа в ветке завершена, разработчик сохраняет изменения, создавая коммиты. Коммиты отражают историю изменений и могут быть просмотрены в любой момент.
4️⃣Слияние изменений. Когда изменения готовы, создаётся Merge Request, чтобы влить изменения в мастер-ветку. До этого момента все изменения всё ещё находятся в отдельной ветке проекта. После слияния с мастер-веткой изменения вступают в силу для всего проекта.
5️⃣Контроль версий Git позволяет отслеживать все изменения, предоставляя возможность возвращения к любому предыдущему состоянию проекта, если это необходимо.


Курсы (бесплатные)

1. «Основы работы с Git» от Яндекс.Практикума. 16 часов обучения, свободный график, теория и тесты для самопроверки, поддержка специалистов, электронное свидетельство о прохождении курса, доступ после авторизации через Яндекс ID
2. Git для начинающих от Слёрм. Доступ придет на указанную почту после регистрации, закрытый Telegram-чат, теория и практические задания, без сертификата
3. Введение в Git от Хекслет. Видеоуроки, лекции, тренажеры с практикой, бессрочный доступ к теории, асинхронный формат обучения, без сертификата, доступ после регистрации
4. Основы Git из Степика. Много практики
5. Git. Базовый курс от GeekBrains. 13 видеоуроков, без сертификата, доступ после записи

⏯ Видосы с Ютуба
1. GIT - Полный Курс Git и GitHub Для Начинающих — одно видео на 4 часа полного погружения
2. Что такое Git для Начинающих — GitHub за 30 минут
3. Уроки по Git и GitHub от ITDoctor
4. Базовый курс по Git от Devcolibri

🕹 Интерактивные гайды на русском
1. Git How To — это интерактивный тур, который познакомит с основами Git
2. LearnGitBranching — веб-приложение по интерактивному погружению в Git

📄 Полезные статьи
1. Что такое GitHub и как он работает
2. Как начать работать с GitHub: быстрый старт
3. Про стратегии ветвления в Гите
4. 19 советов по повседневной работе с Git
5. Как настроить работу с Git в Intellij IDEA

✍️ Шпаргалка по командам Git

📖 Книга
Pro Git — основное чтиво по гиту от Скотта Чакона и Бена Штрауба


#подборка #инфраструктура

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

▶ Способы асинхронного взаимодействия в API

Обзор посвящён асинхрону в API. Асинхрон в брокерах сообщений смотрите в этом посте. А здесь можно найти вводный пост по асинхронным интеграциям.

Асинхрон в API позволяет клиентским приложениям отправлять запросы на сервер и продолжать работу без ожидания ответа.

Зачем это нужно
👩‍🏫Клиент не блокируется в ожидании ответа. Важно для операций, требующих значительного времени на обработку
🧑‍🏫Сервер может обрабатывать больше запросов за счет асинхронной обработки
👨‍🏫Уменьшается количество необходимых запросов для получения обновленных данных, снижая нагрузку на сервер


Способы асинхронного взаимодействия в API

1⃣ Webhooks
1. Клиент отправляет запрос серверу, указывая сallback URL
2. Сервер принимает запрос и отвечает клиенту, что запрос принят в обработку (например, 202 Accepted)
3. Сервер обрабатывает запрос и отправляет клиенту запрос с результатами на сallback URL
➡ Пример: GitHub Webhooks отправляют автоматические уведомления о событиях в репозитории (например, push или pull request) на конфигурированный внешний сервис

2⃣ Polling
Клиент отправляет запрос на сервер, а затем раз в Т миллисекунд отправляет запросы к серверу, чтобы проверить статус операции
➡  Пример:
1. Пользователь заполняет анкету и загружает скан паспорта
2. Фронт отправляет файл на сервер, получает 202 Accepted и позволяет пользователю заполнять анкету дальше
3. Сервер начинает процесс распознавания паспортных данных, который в среднем занимает 5-7 секунд.
4. Приложение запускает фоновый процесс поллинга: раз в 1 секунду отправляет запрос для получения статуса обработки запроса

3⃣ Long Polling
Сервер получает запрос, но держит его открытым до момента появления новых данных. Это уменьшает количество запросов по сравнению с обычным поллингом. Работает на протоколе HTTP. После получения данных от сервера соединение закрывается.
➡  Пример: чат-приложения, где сервер держит соединение открытым до появления новых сообщений, и только после этого отправляет ответ

4⃣ Server-Sent Events (SSE)
Однонаправленный канал связи от сервера к клиенту, позволяющий серверу посылать события клиенту через открытое соединение. В отличие от Long Polling клиент может получать несколько событий и данных от сервера без необходимости устанавливать соединение заново.
➡ Торговые платформы в реальном времени, где клиенты получают обновления цен акций без необходимости постоянного запроса к серверу

5⃣ WebSocket API
Протокол, обеспечивающий двустороннее постоянное соединение между клиентом и сервером, позволяя обмениваться данными в реальном времени. Это именно отдельный протокол (не НTTP), клиент и сервер могут без задержек обмениваться данными в обе стороны, без необходимости устанавливать и закрывать соединения по несколько раз.
➡ Онлайн-игры, интерактивные приложения, где требуется немедленная реакция сервера на действия пользователя и наоборот


⭐️ Подборка материалов доступна в базе знаний по системному анализу

#интеграции #async

🪧Методы трассировки требований

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

Трассировка требований позволяет:
1️⃣ Обеспечить соответствие функциональности системы исходным бизнес-требованиям
2️⃣ Отслеживать изменения требований на протяжении всего жизненного цикла разработки
3️⃣ Управлять изменениями: позволяет оценить влияние изменений требований на другие артефакты и всю систему в целом
4️⃣ Упрощает тестирование: позволяет покрыть бизнес-требования тест-кейсами и не упустить важное

Для обеспечения прослеживаемости каждое требование должно уникальным образом идентифицироваться, например, иметь ID.
Каждая версия требования должна быть прослеживаема, т.к изменение неизбежны и нужно ими управлять.

Помимо ID, требования могут иметь следующие атрибуты:
💩статус
💩дата создания
💩версия
💩автор
💩владелец
💩приоритет
💩источник
💩обоснование
💩релиз
💩контактное лицо или ответственный за принятие решений по внесению изменений в требование
💩критерии приёмки

Виды трассировки

↕️Вертикальная—связи между высокоуровневыми элементами проекта ( бизнес-требованиями) и низкоуровневыми (техническими требованиями или кодом)
↔️Горизонтальная—связи между элементами одного уровня. Например, трассировка между функциональными требованиями или между разными компонентами архитектуры системы.

✏️ Методы трассировки требований

💫 Матрица трассировки (Requirements Traceability Matrix)

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

Примеры возможных связей
—Один к одному: один элемент дизайна реализуется в одном модуле кода;
—Один ко многим: одно функциональное требование (ФТ) проверяется множеством тест-кейсов;
—Многие ко многим:  общие или повторяющиеся элементы дизайна могут удовлетворять нескольким ФТ. На практике данным видом трассировки сложно и трудно управлять

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

💫 Дерево требований

Структурированное дерево, показывающее иерархию требований от общих к более детальным.

Пример
Техническое требование
—> Архитектурное требование
——>Требование к БД
——>Требование к интерфейсу

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


Плюсы и минусы трассировки

➕Четкое представление о требованиях к системе и их взаимосвязях
➕Отслеживание изменений требований

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

#требования

🧪 Требования ACID: Краткий обзор

ACID (Atomicity, Consistency, Isolation, Durability) — набор характеристик, обеспечивающих надежность транзакций в базах данных.

Транзакция в БД — логическая операция, состоящая из одного/нескольких запросов, которые выполняются как единое целое.

💩Атомарность: Транзакция рассматривается как "неделимая" единица работы. Транзакция либо полностью выполняется, либо вообще не выполняется. Нет промежуточных состояний.

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

💩Изолированность: Другие транзакции не должны видеть промежуточных результатов текущей транзакции. Каждая транзакция должна быть изолирована от других: ее выполнение не должно влиять на другие транзакции.

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

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

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

ACID в реляционных/нереляционных СУБД

🔹Большинство традиционных реляционных БД поддерживают требования ACID

🔸В распределенных БД связанные данные находятся на нескольких узлах. Транзакции в NoSQL затруднены и в большинстве СУБД требования ACID не удовлетворяются. Но некоторые NoSQL СУБД (например, графовая Neo4j и документоориентированная MarkLogic) могут обеспечивать свойства ACID.

Пример

Пусть есть БД с информацией о банковских счетах Алисы и Боба. Рассмотрим две транзакции:
➕Перевод денег: Боб переводит Алисе 100$ со своего счета.
🔻Покупка печенек: Алиса покупает на 50$ со своей банковской карты.
У Алисы изначально 0 на счету. У Боба 110$

Применение ACID гарантирует:
💩А: Покупка печенек завершится ошибкой т.к баланс 0$, деньги не будут списаны. Отмена всей транзакции.
💩С: После обеих транзакций у Алисы должно остаться 50$ (0 + 100 - 50), а у Боба 10$. Операции выполнены в правильном порядке. Данные по клиентам корректно отражены
💩I: Если покупка происходит в то время, когда перевод еще не завершился, в БД не появится несогласованных данных. Блокировки и версионирование в БД изолируют транзакции во избежание путаницы в значениях.
💩D: Если обе транзакции завершились успешно, изменения (перевод и покупка) будут сохранены в базе данных даже в случае сбоев системы.

Как связаны ACID и CAP-теорема

Это две разные концепции, касающиеся транзакций в распределенных системах. Они не противоречат друг другу.
💩Цель ACID — обеспечить надежность в транзакционных БД , где данные обрабатываются в рамках централизованной системы.
💩CAP-теорема рассматривается там, где система распределена между несколькими узлами, что создает потенциальные проблемы согласованности и доступности.

🔹 Подробнее про CAP-теорему в нашем посте

⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

#бд

✔️ Критерии приемки (Acceptance Criteria): краткий обзор

Критерии приемки (Acceptance Criteria, AC) — это набор условий, которым должна удовлетворять пользовательская история (User Story), чтобы её считали выполненной.

Критерии приёмки уникальны для каждой User Story (US) и являются основой для тестирования.

❓Для чего нужны

💩позволяют понять, выполнена ли US и работает ли, как ожидалось
💩определяют негативные сценарии и объясняют, как система должна реагировать на них
💩создают у клиента и команды разработки единое видение как должна быть реализована функциональность
💩помогают выявить проблемы на ранних этапах разработки

Критерии приемки должны:

➖быть определены до того, как начнется разработка US
➖иметь четкие формулировки для проверки их выполнения: «принято» или «не принято». AC должны описывать конкретное поведение или результат, который ожидается от функции
➖иметь четкие формулировки для проверки их выполнения.
➖соответствовать ценности и цели пользователя и продукта

✔️ Подходы к составлению критериев приемки

1. Сценарно-ориентированный подход (Scenario-based acceptance criteria)
2. Свод правил или чек-лист (Rule-based acceptance criteria)

1️⃣ Сценарно-ориентированный подход

Соответствует формату Дано/Когда/Тогда (Given/When/Then):

💩Given (Дано): чёткое описание контекста, состояние системы в начальный момент времени 
💩When (Когда): действие, которое выполняет пользователь или система
💩Then (Тогда): ожидаемый результат

Также можно дополнительно использовать:
💩Сценарий — название поведения, которое будет описано 
💩И / ИЛИ —  для продолжения любого из трех предыдущих утверждений

Пример US: Как пользователь, я хочу иметь возможность восстановить пароль от своей учетной записи, чтобы если я забыл пароль, мог получить доступ к своей учетной записи.
💩Сценарий: Забыт пароль
💩Дано: пользователь переходит на страницу входа 
💩Когда: пользователь выбирает опцию <забыл пароль> 
💩И: вводит действительный адрес эл. почты для получения ссылки на восстановление пароля 
💩Тогда: Система отправляет ссылку на указанный адрес электронной почты 

2️⃣ Свод правил (чек-листы)

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

Например:
1. Все кнопки должны иметь скругленные углы радиуса 10
2. Пользователь может выбирать способ авторизации с паролем или через получение OTP
3. В случае неправильного ввода пароля два раза подряд система отображает пользователю капчу

AC 🆚 DoR 🆚 DoD

💩DoR (Definition of Ready) — это набор условий, которые должны быть выполнены, прежде чем командой может взять US в работу. Например, задача описана и декомпозирована, подготовлены CJ, HLD, прикреплены макеты дизайна, прописаны AC и т.д.

💩DoD (Definition of Done) — набор условий, которые должны быть выполнены, чтобы пользовательская история считалась завершенной.
Например, реализация соответствует ТЗ, выполнены AC, пройдены все тест-кейсы, составлена документация, одобрения получены и т.д

Главная разница
💩DoD & DoR одинаковые для всех US
💩AC уникальны для каждой US


⚒️ Использование Gherkin

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

Применяется для:

➖ Документирования пользовательских сценариев
➖ Написания автоматизированных тестов


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

#требования

🔵 5 книг по изучению SQL

💾 Сохраняйте к себе и делитесь с коллегами

1. Изучаем SQL. — А. Болье
2. SQL для чайников — Аллен Тейлор
3. SQL. Сборник рецептов — М. Энтони, де Грааф Роберт
4. SQL для анализа данных — К. Танимура
5. PostgreSQL. Основы языка SQL — Е.П. Моргунов


✔️ А ещё делимся ссылками на подборки материалов по БД:
1. Большая подборка полезных материалов по основам баз данных
2. Памятка по SQL
3. Список бесплатных онлайн-курсов по базам данных и SQL
4. Основные понятия баз данных. Главное
5. Типы связей в БД. Нормализация
6. SQL vs NoSQL: отличие реляционных и нереляционных БД
7. Виды нереляционных БД. Какие бывают NoSQL базы данных
8. Шпаргалка по выбору правильной СУБД


#бд #sql

✍️ Постановка задачи на разработку: этапы, отличие от ТЗ

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

🔸Техническое задание — это документ, который определяет, что должно быть реализовано и как это должно работать (функциональные требования) и насколько это должно быть быстро/безопасно/отказоустойчиво/дружелюбно/отслеживаемо (нефункциональные требования). ТЗ возникает как результат обработки бизнес-требований, и их перевода на системный уровень.

🔹Постановка задачи на разработку — описание конкретных задач, которые должны быть выполнены разработчиками для реализации ТЗ.

Когда постановка задачи должна быть представлена как отдельный артефакт

Постановка задачи на разработку нужна всегда, но не всегда должна быть оформлена как отдельный артефакт. Иногда достаточно ТЗ, если оно содержит нужные детали для разработки.

Случаи, когда необходимо описать постановку задачи отдельно:

💩Когда задача на доработку, а не на разработку с нуля. Есть одна большая спецификация на кусок функционала, и в это ТЗ дописываются требования по доработкам. ПЗ помогает выделить и описать конкретные изменения, которые нужно внести в существующую систему.
💩Когда задача составная и требует декомпозиции. В постановке можно разбить задачу на более простые подзадачи, тогда как ТЗ описывает реализацию функционала в целом без привязки на то, в рамках каких конкретных задач на разработку это будет реализовываться, сколько будет таких задач, кто их будет делать, какова оценка трудозатрат и т.д.

Постановка задачи на разработку может содержать следующие пункты:

💩Введение, цель: Необходимо описать бизнес-контекст, почему задача возникла. Например, компания столкнулась с проблемой неэффективного учета заказов и хочет улучшить этот процесс.
💩Описание решения: способ и границы реализации (ТЗ, Use Case, статусные модели, макеты UX/UI, описание интеграций)
💩Ключевые источники информации: спецификации API, HLD, глоссарий, стандарты и т.д.
💩Диаграммы: например, UML sequence, activity, бизнес-процесс в BPMN, схемы данных
💩Заинтересованные стороны: перечень людей, влияющие на принятие решений
💩 Критерии приемки: критерии, по которым будет оцениваться успешное завершение проекта.
💩НФТ и ограничения решения: производительность, масштабируемость, доступность и т.д.


🆚 Отличие постановки задачи на разработку (ПЗ) от ТЗ

💩(утрируя) ТЗ — это текст в Confluence, ПЗ — описание в Jira
💩ТЗ описывает требования к функциональности в целом, а постановка направлена на реализацию функционала в рамках конкретных задач
💩Одно ТЗ может быть декомпозировано на несколько задач, при этом каждая может иметь свою постановку на разработку
💩Иногда в ТЗ уже содержится и постановка задачи, но лучше понятия не смешивать и всё равно прописывать постановку задачи отдельно


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу


#требования

💚 Инфраструктура открытых ключей (PKI) : краткий обзор

Инфраструктура открытых ключей (Public Key Infrastructure, PKI) — набор правил, который использует цифровые сертификаты и ключи для обеспечения безопасности в сети, включая аутентификацию, шифрование и цифровые подписи

🔴 Сферы применения

🔷PKI используется везде, где требуется работа с чувствительными данными (e-commerce, банках, гос. системах и т.д), например:
-- Цифровые подписи в ПО
-- Ограниченный доступ к корпоративным интранетам и VPN
-- Бесплатный доступ к Wi-Fi без пароля в зависимости от владельца устройства
-- Шифрование эл. почты и данных

🔷PKI в HTTPS

В HTTPS PKI используется для обеспечения безопасности соединения между клиентом и сервером. Достигается с помощью SSL/TLS протоколов, использующие сертификаты для аутентификации сервера и шифрования данных.

♥️ Принцип работы PKI

В основе PKI лежит асимметричная криптография, использующая пары ключей: открытый и закрытый (приватный).
— Открытый используется для шифрования и проверки подписи
— Закрытый для дешифрования и создания подписи
Ключи связаны математически так, что сообщение, зашифрованное с помощью открытого ключа, может быть расшифровано только с помощью соответствующего закрытого ключа.

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

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


👌 Основные компоненты PKI

🟢Центр сертификации (Certificate Authority, CA): выдает цифровые сертификаты, подтверждающие аутентичность открытых ключей пользователей. Отзывает сертификаты в случае утраты или компрометации
🟢Регистрационный центр (Registration Authority, RA): занимается проверкой личности пользователей и выдачей запросов на сертификаты CA
🟢Серверы доверия (Trust Stores): содержит списки доверенных корневых сертификатов, используемых для проверки цепочек сертификации
🟢Клиентские приложения: ПО, которое использует сертификаты для проверки подлинности удаленных сущностей и шифрования данных
🟢Инструменты управления ключами: для генерации, хранения и управления ключами и сертификатами, включая их резервное копирование и восстановление
🟢Протоколы и стандарты: PKI использует различные протоколы и стандарты, такие как:
— X.509 для формата сертификатов
— SSL/TLS для безопасного обмена информацией, наиболее распространенная реализация PKI
—протоколы OCSP и CRL для проверки отзыва сертификатов

✏️ Пример работы PKI

1️⃣Генерация ключей: Пользователь / устройство генерирует пару ключей.

2️⃣Сертификация ключей: Владелец открытого ключа обращается к доверенному CA с запросом на выдачу сертификата. CA проверяет подлинность запроса и подтверждает ассоциацию "открытый ключ" <-> "сущность" ( пользователем, устройством или веб-сайтом), создавая цифровую подпись для сертификата.

3️⃣Распространение сертификатов: Сертификат, содержащий открытый ключ и цифровую подпись CA, распространяется в сети (публикациЯ на веб-сайте, отправка через эл. почту или др)

4️⃣Проверка подлинности: Пользователь проверяет полученный сертификат, используя публичный ключ CA. Если сертификат и подпись верны, то всё ок

5️⃣Шифрование и подпись: Пользователь использует открытый ключ другой стороны для шифрования данных или проверки подписи. Для шифрования используется открытый ключ получателя, а для проверки подпись отправителя

6️⃣Отзыв сертификатов: Если ключ скомпрометирован, владелец ключа должен отозвать сертификат через CA. Это делается через список отзыва сертификатов (CRL) или протокол проверки статуса сертификата (OCSP)


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

#безопасность

Основы ООП

Объектно-ориентированное программирование (ООП) — методология или стиль программирования, при котором код организуется в логически связанные объекты с четкими интерфейсами и поведением. Это помогает создавать программы, которые легко понять, изменять и масштабировать

⚪️ Когда эффективно?

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

За счет чего эффективно?
— облегчения понимания и обслуживания кода благодаря модульной структуре
— улучшения переиспользование кода и уменьшения дублирования
— увеличения гибкости системы и возможности расширения функциональности без изменения существующего кода


▫️Основные принципы ООП

😈Инкапсуляция: скрытие реализации внутри класса.
Позволяет скрыть детали реализации и предоставить интерфейс для взаимодействия с объектом ➡️ обеспечивает безопасность и упрощает использование объекта другими частями программы
⚪️ Класс Animal содержит
— приватную переменную weight
— публичный метод feed()
Переменная weight скрыта от прямого доступа извне класса ➡️ предотвращает непреднамеренное изменение их значений.
Вместо этого доступ к ним осуществляется через методы класса ➡️ есть контроль доступа к данным.

😈Наследование: создание новых классов на основе существующих.
Подклассы наследуют свойства и методы родительского класса ➡️ можно повторно использовать код и упростить разработку.
Подклассы могут расширять функциональность родительского класса, добавляя новые методы или изменяя существующие.
⚪️ Рассмотрим классы Animal и Mammal
Класс Mammal -- подкласс Animal. Т.е. можно наследовать от него его свойства и методы, такие как move() или eat().
Класс Mammal может добавлять собственные методы, например, milkfeeding(), расширяя функциональность базового класса Animal.

😈Полиморфизм: способность объектов разных типов использовать общий интерфейс для выполнения различных действий.
Проявляется в том, что разные объекты могут реагировать на одну и ту же команду по-разному в зависимости от их типа
⚪️ У нас есть классы Dog и Cat, оба имеют метод makesound()
Когда вызывается метод makesound() для объекта класса Dog, он издаёт лай, а для объекта класса Cat - мяукание

😈Абстракция: позволяет отделить концепцию от её реализации.
Уровень абстракции скрывает сложные детали реализации и предоставляет простой интерфейс для использования объекта ➡️ помогает сосредоточиться на важных аспектах объекта, игнорируя незначительные детали.
⚪️ Класс 4legs абстрактный и имеет метод без реализации walk(). Класс является абстракцией (робот или насекомое тоже может иметь 4 ноги). Объект такого класса невозможно создать.
Но можно наследовать потомков.
Dog наследует класс 4legs и реализует метод walk()


💡 Зачем ООП аналитику?

Поможет структурировать требования в соответствии с требованиями бизнеса:
— выделить объекты
— определить их атрибуты
— методы и взаимосвязи между ними

⚪️Нужно описать систему управления библиотекой.
Можно представить систему как совокупность объектов, таких как "книга", "автор" и "читатель", каждый из которых имеет свои атрибуты и методы.

*️⃣Также понимание ООП поможет:
— спроектировать архитектуру приложения: используя принципы наследования, инкапсуляции и полиморфизма разделить функционал на компоненты
— в определении общих интерфейсов и абстракций, которые позволят разным частям системы взаимодействовать между собой

*️⃣Существуют объектно-ориентированные методы системного анализа (ООМСА).
Это подход к анализу, проектированию и моделированию систем, основанный на принципах ООП
Основные методы:
— моделирования объектов и классов
— анализа взаимодействия объектов
— проектирования классов и иерархий
— анализа наследования и агрегации


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

#проектирование

Хранимые процедуры и пользовательские функции в БД

📌Кратко

Хранимые процедуры предназначены для выполнения действий, а пользовательские функции - для вычислений и возврата значений.


✔️ Хранимые процедуры

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

Как используются?

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

Примеры

⏩процедура принимает ID сотрудника в качестве входного параметра и возвращает его имя из таблицы Employees
⏩процедура принимает данные о новом заказе (например, клиент, товары, количество) и добавляет соответствующую запись в базу данных.
⏩входной параметр -- ID заказа, процедура извлекает информацию о товарах в заказе и вычисляет стоимость всех товаров.


〰️ Минусы
💩 когда сложны, тяжело поддерживаемы, возникают проблемы с рефакторингом
💩могут создавать зависимость от конкретной СУБД — затрудняет масштабирование
💩хранение бизнес-логики в PLSQL ведет к созданию монолита. Его дальнейшее разбиение затрудняется
💩 отладка не всегда удобна, логирование и обработка ошибок выполняется вручную


✅ Пользовательские функции

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

Как используются?

🔘 для сложных логических или арифметических операций
🔘возвращаемые значения используются в др. запросах / выражениях
🔘для использования операторах SQL (SELECT, WHERE и тд) для вычисления значений
🔘фильтрации данных, поиска определенных значений или обработки данных по заданными условиями
🔘для работы с текстовыми данными (разбиение строк, поиск подстрок, замена символов и тд)

Пример:
⏩преобразование даты в определенный формат или вычисление дополнительных параметров на основе входных данных.
⏩входные параметры -- ID пользователя и ID ресурса, в ответе булевое значение, указывающее, имеет ли пользователь доступ к этому ресурсу

〰️ Минусы
💩не эффективны в сложных запросах
💩на больших объемах данных могут привести к низкой производительности
💩отладка может быть трудной из-за изоляции от основного кода
💩могут зависеть от контекста сессии или окружения, что может привести к неожиданным результатам

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

Назначение
🟡процедуры -- для выполнения последовательности операций и изменения данных в БД
🔵функции -- для выполнения вычислений и возвращения результата

Возвращаемые значения
🟡процедуры могут возвращать 0 или более значений или изменять состояние БД
🔵функции возвращают только одно значение

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


ХП и пользовательские функции могут использоваться не только в БД, а еще в:
🟣приложениях на стороне сервера: могут быть частью серверных приложений, написанных на Java, C#, Python и др. Используются для обработки данных на сервере перед отправкой их клиенту.
🟣интеграциях в веб
🟣интеграциях с внешними системами, такими как API, сервисы и внешние БД, чтобы обрабатывать данные и для взаимодействия между приложениями и платформами.


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

#бд

✨ Денормализация в БД и не только

Ранее мы рассказывали про нормализацию в БД, рассмотрим обратный процесс.

Денормализация — внесение избыточности в БД путём объединения таблиц, чтобы упростить структуру и ускорить чтения данных

Отличие от нормализации

Нормализация нужна для устранения избыточности данных; для разделения информации по отдельным таблицам, чтобы обеспечать целостность и упростить обслуживания БД
😀Увеличивает количество джойнов при выполнении запросов и может замедлять чтение данных

Денормализация, наоборот, вводит избыточность обратно в БД, объединяя таблицы и дублируя информацию
😀Запросы становятся проще, операции чтения быстрее. Но могут возникнуть трудности с поддержкой и обновлением из-за риска несогласованности


✨ Когда применяется

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

✨ Методы

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

✨ Примеры

😀Агрегация данных: в таблице заказов хранится не только идентификатор клиента, но и агрегированная информация о клиенте, например, общая сумма покупок. Это избавляет от необходимости соединять таблицы заказов и клиентов для расчета общих покупок клиента
😀Кэширование результатов запросов: в таблице с продуктами может храниться не только информация о продукте, но и предварительно рассчитанное количество продуктов на складе. Это снижает нагрузку на СУБД за счет уменьшения количества вычислений при каждом запросе

✨ Недостатки

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

✨ Совет

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


✨ Денормализация в других областях

😀Data Warehouse: улучшает производительность аналитических запросов через агрегированные структуры данных для быстрого выполнения запросов OLAP
😀NoSQL базы данных: для оптимизации горизонтального масштабирования и ускорения доступа к данным, храня связанные данные вместе
😀Frontend-разработка: при проектировании состояния приложений, например в Redux для React, для упрощения доступа к данным и улучшения производительности
😀Микросервисы: улучшает независимость и отказоустойчивость сервисов, храня данные, необходимые каждому микросервису в его собственной базе


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

#бд

🔄 CI/CD: Краткий обзор

Continuous Integration/Continuous Delivery (непрерывная интеграция и доставка) — подход к разработке приложений, который обеспечивает автоматизацию процессов сборки, тестирования и доставки кода.

Код интегрируется и доставляется пользователю итерационно, как можно чаще. Ценность CI/CD кроется в автоматизации всех этапов интеграции и развёртывания кода.

💩CI — практика интеграции кода от разных разработчиков в общий репозиторий. Разработчики как можно чаще сливают изменения в основную ветку, используя систему контроля версий (например, Git). При этом, любые изменения проходят через автоматические тесты.
💩CD — автоматизация развёртывания (доставки) кода в "прод" после успешной интеграции и тестирования.


✔️ Этапы CI/CD

1️⃣ Код. Разработка создает код, исправляет ошибки или делает доработки, выполняет тесты, а затем отправляет в ветку master с актуальной сборкой продукта. Несколько команд могут отправить любое количество модулей в master.
2️⃣ Сборка. Старт автоматической сборки и авто-тестов. Критерии запуска системы управления версиями и начала сборки настраиваются заранее.
3️⃣ Тестирование. После авто-тестов выкатываемой версии проекта, можно приступать к ручной проверке.
4️⃣ Релиз. После успешных тестов, разработчики вносят исправления и выпускают новую версию продукта.
5️⃣ Развёртывание. Отправка финальной версия кода на боевой сервер. Взаимодействие пользователя с сервисом
6️⃣ Поддержка и мониторинг. Разработка мониторит работу продукта, отслеживая и анализируя пользовательский опыт.
7️⃣ Планирование. На основе мониторинга и анализа, формулируются идеи новых доработок и улучшений. Цикл начинается заново - написание кода.


Плюсы CI/CD

+ Сокращение времени поставки (Time to Market): автоматизация процессов позволяет быстрее и чаще доставлять новые функции и исправления.
+ Качество кода: автотесты обеспечивают высокое качество кода, а регулярные интеграции помогают выявлять проблемы на ранних этапах.
+ Легкость масштабирования: Автоматизированные процессы легко масштабируются с увеличением объемов работы.
+ Однородная среда разработки: все члены команды работают в однородной среде - упрощает совместную разработку.

Минусы CI/CD

— Сложность внедрения: Реализация CI/CD требует времени и усилий для внедрения в существующие процессы разработки. обслуживания. Сложные системы CI/CD могут требовать значительных ресурсов для обслуживания
— Трудность согласования изменений: в больших командах интеграция изменений может быть сложной.
— Безопасность: неправильная настройка CI/CD может стать источником уязвимостей.
— Не всегда применимо: когда проект слишком маленький или слишком сложный для автоматизации всех процессов.


🖥 Программы для CI/CD:

Jenkins: Один из самых популярных и распространенных инструментов для CI/CD.
GitLab CI/CD: Встроенная система CI/CD в GitLab, интегрированная с GitLab репозиториями.
Travis CI: Облачный сервис CI/CD, легко настраиваемый для проектов на GitHub.
CircleCI: Облачная CI/CD-платформа с широкими возможностями конфигурации.
TeamCity: Мощный и гибкий инструмент CI/CD от JetBrains.


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

#devops

Kanban vs Scrum: сравнение методологий

Kanban и Scrum — методологии гибкого управления проектами, используемые для реализации принципов Agile и DevOps при разработке.

Kanban — подход к управлению процессом разработки, который включает следующие практики:

💩Визуализация задач и прогресса с помощью канбан-доски, установление приоритетов задачам
💩Ограничение количества задач со статусом "В работе", или WIP (work in progress). Если лимит превышен, то команда не может взять новую задачу в работу, пока не будет завершена одна из текущих
💩Управление потоком: отслеживание метрик, таких как скорость движения задач между статусами, для устранения «бутылочных горлышек», где процесс замедляется
💩Проведение каденций — встреч членов команды по процессу разработки. Всего выделяют 7 видов встреч. Главная цель — объяснение правил для всех участников команды и сбор обратной связи
💩Непрерывное улучшение процесса на основе обратной связи и анализа метрик

Что общего между Kanban и Scrum

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

Различие подготовили в сравнительной таблице постом выше.


✅ Когда лучше применять

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

Scrum:
💩 важен строгий контроль сроков и структура
💩 требуется четкое определение целей и результатов
💩 команда является кросс-функциональной
Пример: Разработка новой версии продукта с фиксированным релизным циклом, например, каждые 3 месяца.


❌ Когда не подойдет

Kanban
💩в проектах, где необходимо строго соблюдать сроки
💩в кросс-функциональных командах
💩когда требуется постоянная обратная связь от клиентов

Scrum
💩 продукт нужен целиком, итерации невозможны
💩 когда нет сплочённой, самоорганизованной и кросс-функциональной команды
💩 для слишком маленьких групп из 1–2 человек, или, наоборот, больших лучше заменить другими методами — SAFe, LeSS.


☯️ Гибрид ScrumBan

Используется в средах, где необходимо управление проектом в условиях неопределенности и частых изменений. ScrumBan легче внедрить, чем Scrum
💩от Scrum: сохраняет ключевые элементы Scrum: спринты, роли (Product Owner, Scrum Master, и команда разработки) и основные события (планирование, ревью, ретроспектива).
💩от Kanban: заимствует концепцию визуализации процесса на доске, ограничения рабочего объема, адаптацию к изменениям в реальном времени и фокус на поток задач.


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

#управление_проектами

UX/UI: краткий обзор

💙UX (User Experience — «пользовательский опыт») отвечает за то, как интерфейс работает

💙UI (User Interface — «пользовательский интерфейс») отвечает за то, как интерфейс выглядит

Цели UI/UX дизайна

💙UX: обеспечить позитивный опыт пользователя при взаимодействии с продуктом с учетом его потребностей, ожиданий и контекста использования
💙UI: сделать интерфейс интуитивно понятным и легким в использовании, а также привлекательным визуально


💙 UX

Примеры UX-анализа

💙 Исследование пользовательского поведения: взаимодействие с веб-сайтом или приложением, анализ переходов между страницами, время пребывания на страницах, клики на элементы и т. д.
💙 Тестирование пользовательского интерфейса: удобство использования, понятность и эффективность. Например, тесты сценариев использования или а/б-тестирования
💙 Сбор обратной связи от пользователей: анализ отзывов о продукте, определение их потребности и предпочтения, выявление проблем, с которыми пользователи сталкиваются

Основные принципы UX

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

Usability ≠ UX

Usability - лишь часть хорошего UX

💙 Usability - удобство и легкость взаимодействия пользователя с продуктом
Цель: сделать задачу легко, интуитивно и быстро
💙Достиг ли пользователь цели максимально удобным способом?

💙 UX - опыт взаимодействия пользователя. Восприятие и совокупность эмоций, возникающих в результате использования продукта
Цель: сделать пользователя счастливым до, во время и после использования продукта
💙Был ли опыт пользователя максимально положительным?


💙 UI

Примеры UI -анализа

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

Основные принципы UI

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

🟣 Адаптивная верстка

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


⏩Этапы разработки UX/UI

🟢Исследование и анализ: исследование аудитории и их потребностей, изучение рынка и конкурентов
🟢Проектирование: создается структура и навигация, выбирается цветовая гамма и шрифты
🟢Прототипирование: создаются прототипы интерфейса для проверки удобства использования
🟢Тестирование и итерации: прототипы тестируются среди пользователей
🟢Разработка и реализация: на основе утвержденных прототипов
🟢Мониторинг и оптимизация: После запуска продукта сбор аналитики для оптимизации интерфейса


⭐️ Подборки материалов по этой и другим темам доступны в базе знаний по системному анализу

#развитие #uxui