Merge branch 'master' of http://213.155.192.79:3001/ypv/ISRPO

Лекции/Arkhitektura_Sovremennogo_STAKa/6ThirdLecture.md

@@ -0,0 +1,19 @@
+# Лекция 3: Принципы тестопригодного дизайна: от Dependency Injection до hexagonal architecture
+
+**Тестопригодный дизайн (Testable Design) — это архитектурный подход**, при котором система проектируется таким образом, чтобы ее компоненты могли быть легко, быстро и изолированно протестированы. Высокая связанность (tight coupling) и скрытые зависимости — главные враги тестируемости. Ключевым приемом для борьбы с ними является **Инверсия зависимостей (Dependency Inversion Principle, DIP)**, реализуемая через механизм **Внедрения зависимостей (Dependency Injection, DI)**, который передает зависимости компоненту извне, а не позволяет ему создавать их самостоятельно.
+
+![](images12.png)
+
+
+С технической точки зрения, DI **позволяет заменять реальные реализации зависимостей на тестовые дублеры (test doubles)** — моки (mocks), стабы (stubs), фейки (fakes). Это делает модульные тесты быстрыми (не требуют базы данных или внешнего API) и стабильными (не зависят от внешних сбоев). Архитектурные паттерны, такие как **Гексагональная архитектура (Hexagonal) или Чистая архитектура**, формализуют этот подход, разделяя систему на «ядро» (бизнес-логика) и «адаптеры» (работа с БД, UI, внешними сервисами). Зависимости направляются *извне внутрь* к ядру, которое ничего не знает о деталях реализации адаптеров.
+
+### Таблица 3. Уровни тестирования и соответствующие приемы тестопригодного дизайна
+| Уровень тестирования | Цель | Ключевые приемы дизайна | Инструменты для изоляции |
+|----------------------|------|--------------------------|--------------------------|
+| Модульное (Unit) | Проверить логику отдельного класса/функции в изоляции. | Внедрение зависимостей через интерфейс, принцип единственной ответственности. | Mock-библиотеки (Jest, Mockito, unittest.mock). |
+| Интеграционное | Проверить взаимодействие нескольких компонентов (например, сервиса и репозитория). | Использование in-memory баз данных (SQLite, H2), заглушек для внешних HTTP-сервисов (WireMock). | Тестовые контейнеры (Testcontainers), фикстуры данных. |
+| Контрактное (Contract) | Проверить совместимость интерфейсов между потребителем и поставщиком (микросервисы). | Явное определение и версионирование API-контрактов (OpenAPI/Swagger, gRPC proto). | Pact, Spring Cloud Contract. |
+
+Эффективный тестопригодный дизайн **требует дисциплины на этапе проектирования**. Код, который сложно протестировать, как правило, имеет архитектурные проблемы (нарушение SRP, высокое зацепление). Поэтому написание тестов — не только способ проверки корректности, но и **мощный инструмент обратной связи о качестве архитектуры**. Если для теста требуется неадекватно сложная настройка — это сигнал к рефакторингу.
+
+Таким образом, тестопригодный дизайн — это **не дополнительная нагрузка, а естественное следствие применения SOLID-принципов и модульной архитектуры**. Инвестиции в него на ранних этапах окупаются значительным снижением стоимости изменений и повышением надежности системы на протяжении всего ее жизненного цикла.

Лекции/Arkhitektura_Sovremennogo_STAKa/FirstLecture.md

@@ -0,0 +1,18 @@
+## Лекция 1: Декларативный рендеринг: от шаблонов к Virtual DOM и реактивным системам
+
+**Декларативный рендеринг представляет собой парадигму описания пользовательского интерфейса**, при которой разработчик определяет *каким должен быть UI в конкретный момент времени* в зависимости от состояния приложения, а не предписывает последовательность команд для его изменения (императивный подход). Современные фреймворки (React, Vue, Svelte) реализуют эту парадигму через абстракцию **Virtual DOM** или компиляцию, что позволяет автоматически и эффективно синхронизировать фактический DOM с изменяющимся состоянием.
+
+![](1_fEhtrrrUj2m2iVqSy7EQCQ.png)
+
+Ключевым инженерным вызовом является **эффективный расчет разницы (diffing) между состояниями UI**. Наивный подход — полная перерисовка при любом изменении состояния — неприемлем для производительности. React и подобные библиотеки используют эвристический алгоритм сравнения двух деревьев Virtual DOM (рекурсивный обход, сравнение по типу элемента и ключу `key`), чтобы вычислить минимальный набор мутаций для реального DOM. Это преобразует проблему обновления интерфейса из задачи изменения DOM (`element.appendChild()`) в задачу обновления данных (состояния).
+
+### Таблица 1. Сравнение стратегий декларативного рендеринга
+| Стратегия | Реализация | Механизм синхронизации | Преимущество |
+|-----------|------------|------------------------|--------------|
+| Virtual DOM & Reconciliation | React, Preact | Сравнение двух VDOM-деревьев, применение патча к реальному DOM | Абстракция над нативным API, кроссплатформенность (React Native). |
+| Компиляция в императивный код | Svelte, Solid.js | Компилятор на этапе сборки генерирует оптимальный код, точечно обновляющий DOM при изменении реактивных переменных. | Накладные расходы в runtime близки к нулю, отсутствие виртуального DOM. |
+| Тонкая реактивность (Fine-grained Reactivity) | Vue 3, MobX | Использование Proxy для отслеживания зависимостей; при изменении данных вызываются только связанные с ними эффекты (рендер-функции). | Более точный контроль над тем, что и когда пересчитывается. |
+
+С архитектурной точки зрения, декларативный подход **неразрывно связан с управлением состоянием (state management)**. UI становится функцией от состояния: `UI = f(state)`. Это **позволяет** четко разделять бизнес-логику (преобразование состояния) и логику представления (отображение), что упрощает тестирование и рассуждения о поведении приложения. Компоненты становятся идемпотентными по отношению к своим пропсам и состоянию.
+
+Таким образом, декларативный рендеринг — это **не просто синтаксический сахар, а фундаментальный сдвиг в модели разработки интерфейсов**, переносящий фокус с механизмов обновления на проектирование потока данных и их трансформации в визуальное представление.

Лекции/Arkhitektura_Sovremennogo_STAKa/FourLecture.md

@@ -0,0 +1,19 @@
+## Лекция 4: Оркестрация контейнеров: от cgroups до declarative deployment в Kubernetes
+
+**Оркестрация контейнеров — это процесс автоматизации развертывания, масштабирования, управления сетью и обеспечения отказоустойчивости контейнеризированных приложений**. Решение этой задачи выросло из необходимости управлять сотнями и тысячами изолированных процессов (контейнеров), работающих в распределенном кластере машин. Kubernetes (K8s), ставший отраслевым стандартом, абстрагирует отдельные физические или виртуальные машины в единый **вычислительный ресурсный пул**, предоставляя API для декларативного описания желаемого состояния приложения.
+
+![](image13.png)
+
+Фундаментальной технологической основой является **изоляция процессов на уровне ОС** через механизмы ядра Linux: **cgroups (control groups)** для ограничения ресурсов (CPU, memory) и **namespaces** для изоляции сетевого стека, файловой системы и процессов. Контейнер (например, Docker) — это упакованный процесс со своей средой, использующий эти механизмы. **Kubernetes не создает контейнеры**, а работает с ними как с атомарными единицами развертывания, упакованными в **Pod** — минимальную deployable unit, которая может содержать один или несколько тесно связанных контейнеров.
+
+### Таблица 4. Основные объекты Kubernetes и их аналогии
+| Объект Kubernetes | Абстракция / Аналог | Декларативная цель | Кто обеспечивает? |
+|-------------------|---------------------|-------------------|-------------------|
+| Pod (Под) | Виртуальный «хост» для контейнеров. | Запустить одну или несколько контейнеров на одном узле с общим сетевым пространством и хранилищем. | Kubelet (агент на узле). |
+| Deployment (Развертывание) | Declaration of Replica Set для stateless-приложения. | Поддерживать заданное количество идентированных реплик Pod'ов, обеспечивая rolling updates и rollback. | Deployment Controller (часть Control Plane). |
+| Service (Сервис) | Стабильная сетевая endpoint и балансировщик нагрузки. | Предоставить стабильный DNS-имя и IP для доступа к динамическому набору Pod'ов (по селектору labels). | kube-proxy (сетевой прокси на узлах). |
+| ConfigMap / Secret | Внешняя конфигурация и чувствительные данные. | Отделить конфигурацию от образа контейнера. Предоставить ее Pod'ам в виде переменных окружения или файлов. | Kubelet (монтирует данные в Pod). |
+
+Ключевой парадигмой K8s является **декларативное управление состоянием через control loop**. Пользователь описывает желаемое состояние в YAML-манифесте (например, `replicas: 3`). **Контроллеры (controllers)** в Control Plane (например, Deployment Controller) постоянно наблюдают за реальным состоянием кластера и, обнаружив расхождение (например, упал 1 Pod), выполняют действия для приведения реальности к декларации (запускают новый Pod). Этот принцип делает систему самоисцеляющейся (self-healing) и предсказуемой.
+
+Таким образом, оркестрация контейнеров с помощью Kubernetes — это **эволюция абстракций управления вычислительными ресурсами**, поднимающая уровень абстракции от отдельных машин и скриптов развертывания до глобального «операционной системы для дата-центра», где приложение определяется его желаемым состоянием, а система гарантирует его поддержание.

Лекции/Arkhitektura_Sovremennogo_STAKa/SecondLecture.md

@@ -0,0 +1,18 @@
+# Лекция 2: Согласованность в распределенных системах: теорема CAP и практические паттерны
+
+**Согласованность в распределенных системах определяет гарантии**, которые система дает относительно того, когда операция записи становится видимой для последующих операций чтения. Классическая теорема CAP (Brewer) постулирует, что в условиях сетевого раздела (Partition tolerance) распределенная система может обеспечить только либо **Согласованность (Consistency)**, либо **Доступность (Availability)**, но не оба свойства одновременно. На практике большинство современных систем выбирают вариант **PA/EL** (Availability + Partition Tolerance с отложенной согласованностью), реализуя модель **согласованности в конечном счете (Eventual Consistency)**.
+
+![](i.webp)
+
+С инженерной точки зрения, выбор модели согласованности **определяет архитектуру и сложность** системы. Сильная согласованность (как в CP-системах: ZooKeeper, etcd) достигается через консенсус-алгоритмы (Raft, Paxos), блокирующие запись до репликации на кворум узлов, что снижает доступность при сетевых проблемах. В основе **Eventual Consistency** лежат асинхронная репликация и разрешение конфликтов. Системы вроде DynamoDB или Cassandra используют механизмы вроде Vector Clocks, Last Write Wins (LWW) или пользовательских функций слияния (CRDTs — Conflict-free Replicated Data Types) для согласования расходящихся версий данных.
+
+### Таблица 2. Паттерны обеспечения согласованности в различных сценариях
+| Паттерн | Пример использования | Механизм | Компромисс |
+|---------|---------------------|----------|------------|
+| Кворумная запись/чтение (Read/Write Quorum) | DynamoDB, Cassandra | Запись считается успешной при подтверждении от `W` узлов, чтение запрашивает `R` узлов, где `R + W > N`. Гарантирует актуальность данных. | Увеличивает latency, так как требует ответа от нескольких узлов. |
+| Лидер-фолловер с синхронной репликацией | PostgreSQL с синхронной репликой | Запись фиксируется только после подтверждения от синхронной реплики. Обеспечивает сильную согласованность и надежность. | Доступность теряется, если реплика недоступна; производительность записи падает. |
+| Компенсирующие транзакции (Saga Pattern) | Микросервисная архитектура | Длинная бизнес-транзакция разбивается на этапы, каждый со своей локальной транзакцией. В случае сбоя запускаются компенсирующие транзакции для отката. | Сложность реализации, система в целом становится лишь в конечном счете согласованной. |
+
+Практический выбор всегда является **компромиссом, основанным на бизнес-требованиях**. Нужна ли абсолютная консистентность для финансового баланса (да) или допустима задержка в несколько секунд для количества лайков (нет). Понимание этого **позволяет** **выбирать подходящие инструменты** и проектировать корректные протоколы взаимодействия между сервисами.
+
+Таким образом, управление согласованностью — это **критический навык для архитектора распределенных систем**, требующий глубокого понимания не только теоретических пределов (теорема CAP, FLP), но и практических механизмов их обхода в реальных, неидеальных условиях.

Лекции/Arkhitektura_Sovremennogo_STAKa/ThirdLecture.md

@@ -0,0 +1,19 @@
+# Лекция 3: Принципы тестопригодного дизайна: от Dependency Injection до hexagonal architecture
+
+**Тестопригодный дизайн (Testable Design) — это архитектурный подход**, при котором система проектируется таким образом, чтобы ее компоненты могли быть легко, быстро и изолированно протестированы. Высокая связанность (tight coupling) и скрытые зависимости — главные враги тестируемости. Ключевым приемом для борьбы с ними является **Инверсия зависимостей (Dependency Inversion Principle, DIP)**, реализуемая через механизм **Внедрения зависимостей (Dependency Injection, DI)**, который передает зависимости компоненту извне, а не позволяет ему создавать их самостоятельно.
+
+![](images12.png)
+*Ключевые слова для поиска изображения: dependency injection test double mock stub, hexagonal architecture ports and adapters*
+
+С технической точки зрения, DI **позволяет заменять реальные реализации зависимостей на тестовые дублеры (test doubles)** — моки (mocks), стабы (stubs), фейки (fakes). Это делает модульные тесты быстрыми (не требуют базы данных или внешнего API) и стабильными (не зависят от внешних сбоев). Архитектурные паттерны, такие как **Гексагональная архитектура (Hexagonal) или Чистая архитектура**, формализуют этот подход, разделяя систему на «ядро» (бизнес-логика) и «адаптеры» (работа с БД, UI, внешними сервисами). Зависимости направляются *извне внутрь* к ядру, которое ничего не знает о деталях реализации адаптеров.
+
+### Таблица 3. Уровни тестирования и соответствующие приемы тестопригодного дизайна
+| Уровень тестирования | Цель | Ключевые приемы дизайна | Инструменты для изоляции |
+|----------------------|------|--------------------------|--------------------------|
+| Модульное (Unit) | Проверить логику отдельного класса/функции в изоляции. | Внедрение зависимостей через интерфейс, принцип единственной ответственности. | Mock-библиотеки (Jest, Mockito, unittest.mock). |
+| Интеграционное | Проверить взаимодействие нескольких компонентов (например, сервиса и репозитория). | Использование in-memory баз данных (SQLite, H2), заглушек для внешних HTTP-сервисов (WireMock). | Тестовые контейнеры (Testcontainers), фикстуры данных. |
+| Контрактное (Contract) | Проверить совместимость интерфейсов между потребителем и поставщиком (микросервисы). | Явное определение и версионирование API-контрактов (OpenAPI/Swagger, gRPC proto). | Pact, Spring Cloud Contract. |
+
+Эффективный тестопригодный дизайн **требует дисциплины на этапе проектирования**. Код, который сложно протестировать, как правило, имеет архитектурные проблемы (нарушение SRP, высокое зацепление). Поэтому написание тестов — не только способ проверки корректности, но и **мощный инструмент обратной связи о качестве архитектуры**. Если для теста требуется неадекватно сложная настройка — это сигнал к рефакторингу.
+
+Таким образом, тестопригодный дизайн — это **не дополнительная нагрузка, а естественное следствие применения SOLID-принципов и модульной архитектуры**. Инвестиции в него на ранних этапах окупаются значительным снижением стоимости изменений и повышением надежности системы на протяжении всего ее жизненного цикла.

Лекции/Arkhitektura_Sovremennogo_STAKa/ThirdLecture1.md

@@ -0,0 +1,19 @@
+# Лекция 3: Принципы тестопригодного дизайна: от Dependency Injection до hexagonal architecture
+
+**Тестопригодный дизайн (Testable Design) — это архитектурный подход**, при котором система проектируется таким образом, чтобы ее компоненты могли быть легко, быстро и изолированно протестированы. Высокая связанность (tight coupling) и скрытые зависимости — главные враги тестируемости. Ключевым приемом для борьбы с ними является **Инверсия зависимостей (Dependency Inversion Principle, DIP)**, реализуемая через механизм **Внедрения зависимостей (Dependency Injection, DI)**, который передает зависимости компоненту извне, а не позволяет ему создавать их самостоятельно.
+
+![](images12.png)
+*Ключевые слова для поиска изображения: dependency injection test double mock stub, hexagonal architecture ports and adapters*
+
+С технической точки зрения, DI **позволяет заменять реальные реализации зависимостей на тестовые дублеры (test doubles)** — моки (mocks), стабы (stubs), фейки (fakes). Это делает модульные тесты быстрыми (не требуют базы данных или внешнего API) и стабильными (не зависят от внешних сбоев). Архитектурные паттерны, такие как **Гексагональная архитектура (Hexagonal) или Чистая архитектура**, формализуют этот подход, разделяя систему на «ядро» (бизнес-логика) и «адаптеры» (работа с БД, UI, внешними сервисами). Зависимости направляются *извне внутрь* к ядру, которое ничего не знает о деталях реализации адаптеров.
+
+### Таблица 3. Уровни тестирования и соответствующие приемы тестопригодного дизайна
+| Уровень тестирования | Цель | Ключевые приемы дизайна | Инструменты для изоляции |
+|----------------------|------|--------------------------|--------------------------|
+| Модульное (Unit) | Проверить логику отдельного класса/функции в изоляции. | Внедрение зависимостей через интерфейс, принцип единственной ответственности. | Mock-библиотеки (Jest, Mockito, unittest.mock). |
+| Интеграционное | Проверить взаимодействие нескольких компонентов (например, сервиса и репозитория). | Использование in-memory баз данных (SQLite, H2), заглушек для внешних HTTP-сервисов (WireMock). | Тестовые контейнеры (Testcontainers), фикстуры данных. |
+| Контрактное (Contract) | Проверить совместимость интерфейсов между потребителем и поставщиком (микросервисы). | Явное определение и версионирование API-контрактов (OpenAPI/Swagger, gRPC proto). | Pact, Spring Cloud Contract. |
+
+Эффективный тестопригодный дизайн **требует дисциплины на этапе проектирования**. Код, который сложно протестировать, как правило, имеет архитектурные проблемы (нарушение SRP, высокое зацепление). Поэтому написание тестов — не только способ проверки корректности, но и **мощный инструмент обратной связи о качестве архитектуры**. Если для теста требуется неадекватно сложная настройка — это сигнал к рефакторингу.
+
+Таким образом, тестопригодный дизайн — это **не дополнительная нагрузка, а естественное следствие применения SOLID-принципов и модульной архитектуры**. Инвестиции в него на ранних этапах окупаются значительным снижением стоимости изменений и повышением надежности системы на протяжении всего ее жизненного цикла.

Лекции/Arkhitektura_Sovremennogo_STAKa/questions.md

@@ -0,0 +1,61 @@
+**Лекция 1: Декларативный рендеринг**
+
+В чем заключается ключевой инженерный вызов при реализации декларативного рендеринга?
+Эффективный расчет разницы (diffing) между состояниями пользовательского интерфейса для минимального обновления DOM.
+
+Какую парадигму описывает декларативный рендеринг в отличие от императивного?
+Парадигму, при которой разработчик описывает, *каким должен быть интерфейс* в зависимости от состояния, а не предписывает пошаговые команды для его изменения.
+
+Как декларативный подход влияет на архитектуру приложения с точки зрения разделения ответственности?
+Он позволяет четко разделить бизнес-логику (управление состоянием) и логику представления (отображение), упрощая тестирование и проектирование.
+
+Какие основные стратегии реализации декларативного рендеринга существуют в современных фреймворках?
+Стратегия Virtual DOM (React), компиляция в императивный код (Svelte) и тонкая реактивность на основе Proxy (Vue 3).
+
+---
+
+**Лекция 2: Согласованность в распределенных системах**
+
+Какое фундаментальное ограничение описывает теорема Consistency Availability Partition Tolerance для распределенных систем?
+В условиях сетевого раздела система может гарантировать либо Согласованность (Consistency), либо Доступность (Availability), но не оба свойства одновременно.
+
+Какую модель согласованности чаще всего применяют на практике и почему?
+Модель согласованности в конечном счете (Eventual Consistency), так как она обеспечивает доступность и отказоустойчивость, что критично для многих современных масштабируемых систем.
+
+Какой механизм используют системы вроде DynamoDB для обеспечения актуальности данных при чтении и записи?
+Механизм кворумов (Read/Write Quorum), где запись и чтение считаются успешными при подтверждении от заданного числа узлов.
+
+Что лежит в основе достижения согласованности в конечном счете?
+Асинхронная репликация данных между узлами и использование механизмов разрешения конфликтов, таких как векторные часы или CRDT.
+
+---
+
+**Лекция 3: Принципы тестопригодного дизайна**
+
+Какие два фактора являются главными препятствиями для тестируемости кода?
+Высокая связанность (tight coupling) компонентов и наличие скрытых зависимостей.
+
+Какой принцип и механизм являются основой для создания тестируемого дизайна?
+Принцип инверсии зависимостей (DIP), реализуемый через механизм внедрения зависимостей (Dependency Injection).
+
+Какую основную цель преследует модульное (unit) тестирование?
+Проверку корректности логики отдельного класса или функции в полной изоляции от внешних зависимостей.
+
+Какие архитектурные паттерны формализуют разделение бизнес-логики и инфраструктурного кода для улучшения тестируемости?
+Гексагональная архитектура (Hexagonal Architecture) и Чистая архитектура (Clean Architecture).
+
+---
+
+**Лекция 4: Оркестрация контейнеров**
+
+Какую основную задачу решает оркестрация контейнеров?
+Автоматизацию развертывания, масштабирования, управления сетью и обеспечения отказоустойчивости контейнеризированных приложений в кластере.
+
+Какие низкоуровневые механизмы ядра Linux обеспечивают изоляцию контейнеров?
+Cgroups (control groups) для ограничения ресурсов и namespaces для изоляции сетевого стека, процессов и файловой системы.
+
+Что является минимальной и неделимой единицей развертывания (deployable unit) в Kubernetes?
+Pod (Под) — абстракция, которая может содержать один или несколько тесно связанных контейнеров.
+
+Какой ключевой принцип управления лежит в основе работы Kubernetes?
+Принцип декларативного управления состоянием через управляющие циклы (control loops), где система автоматически приводит реальное состояние к описанному желаемому.