update state, api, arch

docs/architecture/01-review.md

@@ -1,5 +0,0 @@
----
-sidebar_position: 1
----
-
-# Обзор архитектур

docs/architecture/05-feature-slice-desing.md

@@ -1,5 +0,0 @@
----
-sidebar_position: 5
----
-
-# Feature slice design

docs/architecture/05-fsd-feature-slice-design.md

@@ -0,0 +1,115 @@
+---
+sidebar_position: 5
+---
+
+# Feature slice design
+
+**Feature Slice Design (FSD)** — это методология проектирования и организации кода во фронтенд-разработке, которая фокусируется на разделении приложения на независимые, функционально завершённые блоки (срезы), каждый из которых соответствует определённой фиче (функциональности) продукта. Этот подход помогает создавать более структурированные, масштабируемые и поддерживаемые приложения.
+
+## Основные идеи FSD:
+1. **Организация по фичам, а не по типам файлов:**
+   - Вместо традиционного разделения на папки типа `components`, `pages`, `store`, код организуется вокруг функциональных блоков (фич).
+   - Например, для фичи "Корзина покупок" создаётся отдельная папка, внутри которой находятся все связанные с ней компоненты, стили, логика и тесты.
+2. **Изоляция функциональности:**
+   - Каждая фича (срез) максимально независима от других. Это позволяет разрабатывать, тестировать и изменять её без влияния на остальные части приложения.
+3. **Переиспользуемость:**
+   - Общие части (например, UI-компоненты или утилиты) выносятся в отдельный слой, который может использоваться несколькими фичами.
+4. **Масштабируемость:**
+   - По мере роста приложения новые фичи добавляются как отдельные модули, что упрощает поддержку и развитие проекта.
+
+### Пример структуры проекта с использованием FSD:
+```
+src/
+│
+├── features/
+│   ├── cart/              # Фича "Корзина"
+│   │   ├── components/    # Компоненты, специфичные для корзины
+│   │   ├── hooks/         # Хуки для корзины
+│   │   ├── store/         # Логика состояния (например, Redux slice)
+│   │   └── index.ts       # Экспорт фичи
+│   │
+│   └── auth/              # Фича "Авторизация"
+│       ├── components/
+│       ├── hooks/
+│       ├── store/
+│       └── index.ts
+│
+├── shared/                # Общие компоненты и утилиты
+│   ├── ui/                # UI-компоненты (кнопки, инпуты и т.д.)
+│   └── lib/               # Утилиты и хелперы
+│
+└── app/                   # Основная логика приложения (роутинг, провайдеры и т.д.)
+```
+### Понятия
+Слои, слайсы и сегменты образуют иерархию, как показано на схеме:
+![](images/05-fsd-1.png)
+
+На картинке выше: три столбика, обозначенные слева направо как `"Слои"`, `"Слайсы"` и `"Сегменты"` соответственно.
+
+Столбик **"Слои"** содержит семь делений, расположенных сверху вниз и обозначенных "app", "processes", "pages", "widgets", "features", "entities" и "shared". Деление "processes" зачеркнуто. Деление "entities" соединено со вторым столбиком "Слайсы", показывая, что второй столбик является содержимым "entities".
+
+Столбик **"Слайсы"** содержит три деления, расположенных сверху вниз и обозначенных "user", "post" и "comment". Деление "post" соединено со столбиком "Сегменты" таким же образом, что и содержимое "post".
+
+Столбик **"Сегменты"** содержит три деления, расположенных сверху вниз и обозначенных "ui", "model" и "api".
+
+### Слои
+Слои стандартизированы во всех проектах FSD. Вам не обязательно использовать все слои, но их названия важны. На данный момент их семь (сверху вниз):
+
+1. **App** — всё, благодаря чему приложение запускается — роутинг, точки входа, глобальные стили, провайдеры и т. д.
+2. **Processes (процессы, устаревший)** — сложные межстраничные сценарии.
+3. **Pages (страницы)** — полные страницы или большие части страницы при вложенном роутинге.
+4. **Widgets (виджеты)** — большие самодостаточные куски функциональности или интерфейса, обычно реализующие целый пользовательский сценарий.
+5. **Features (фичи)** — повторно используемые реализации целых фич продукта, то есть действий, приносящих бизнес-ценность пользователю.
+6. **Entities (сущности)** — бизнес-сущности, с которыми работает проект, например user или product.
+7. **Shared** — переиспользуемый код, особенно когда он отделён от специфики проекта/бизнеса, хотя это не обязательно.
+
+Слои **App** и **Shared**, в отличие от других слоев, не имеют слайсов и состоят из сегментов напрямую.
+
+Фишка слоев в том, что модули на одном слое могут знать только о модулях со слоев строго ниже, и как следствие, импортировать только с них.
+
+### Слайсы
+Дальше идут слайсы, они делят слой по предметной области. Вы можете называть ваши слайсы как угодно, и создавать их сколько угодно. Слайсы помогают не теряться в проекте, потому что группируют тесно связанный по смыслу код.
+
+Слайсы не могут использовать другие слайсы на том же слое, и это обеспечивает сильную связанность кода внутри слайса и слабую сцепленность между слайсами.
+
+### Сегменты
+Слайсы, а также слои App и Shared, состоят из сегментов, а сегменты группируют код по его назначению. Имена сегментов не зафиксированы стандартом, но существует несколько общепринятых имен для наиболее распространенных целей:
+
+- `ui` — всё, что связано с отображением: UI-компоненты, форматтеры дат, стили и т.д.
+- `api` — взаимодействие с бэкендом: функции запросов, типы данных, мапперы.
+- `model` — модель данных: схемы валидации, интерфейсы, хранилища и бизнес-логика.
+- `lib` — библиотечный код, который нужен другим модулям этого слайса.
+- `config` — файлы конфигурации и фиче-флаги.
+Обычно этих сегментов достаточно для большинства слоев, поэтому свои собственные сегменты обычно создают только в Shared или App, но это не жёсткое правило.
+
+### Преимущества
+- **Однородность** \
+  Поскольку структура стандартизирована, проекты становятся более единообразными, что облегчает набор новых участников в команду.
+- **Устойчивость к изменениям и рефакторингу** \
+  Модуль на одном слое не может использовать другие модули на том же слое или слоях выше. \
+  Это позволяет вам вносить изолированные правки без непредвиденных последствий для остальной части приложения.
+- **Контролируемое переиспользование логики** \
+  В зависимости от уровня вы можете сделать код либо очень переиспользуемым, либо очень локальным.\
+  Это сохраняет баланс между соблюдением принципа DRY и практичностью.
+- **Ориентация на потребности бизнеса и пользователей** \
+  Приложение разделено на бизнес-домены, и при именовании поощряется использование терминологии бизнеса, чтобы вы могли делать полезную работу в продукте, не вникая полностью во все другие несвязанные части проекта.
+
+## Когда использовать Feature Slice Design
+- В крупных проектах с большим количеством функциональных блоков.
+- В командах, где разные разработчики работают над разными фичами.
+- Когда требуется высокая степень переиспользуемости и модульности.
+
+## Преимущества FSD:
+- **Упрощение разработки:** Легче фокусироваться на одной фиче, не отвлекаясь на остальные части приложения.
+- **Улучшение поддерживаемости:** Изменения в одной фиче не затрагивают другие.
+- **Гибкость:** Фичи можно легко добавлять, удалять или заменять.
+- **Тестируемость:** Каждая фича может быть протестирована изолированно.
+
+## Когда использовать FSD:
+- В крупных проектах с множеством функциональных блоков.
+- Когда требуется высокая степень переиспользуемости и модульности.
+- В командах, где разные разработчики работают над разными фичами.
+
+## Альтернативы:
+- **Layer-based architecture** (разделение на слои, например, components, pages, store).
+- **Domain-driven design (DDD)** (организация кода вокруг доменных областей).

docs/architecture/06-micro-frontend.md

@@ -2,4 +2,115 @@
 sidebar_position: 6
 ---
 
-# Micro frontend
+# Micro frontend
+
+Микрофронтенды (Micro Frontends) — это архитектурный подход, который позволяет разделить фронтенд-приложение на независимые, слабо связанные части, каждая из которых может разрабатываться, тестироваться и развертываться отдельно. Этот подход вдохновлен микросервисной архитектурой и применяется для создания масштабируемых и поддерживаемых фронтенд-приложений.
+
+Основные принципы разделения фронтенд-приложения на микрофронтенды:
+
+## 1. Разделение по бизнес-возможностям (Business Capabilities):
+- Каждый микрофронтенд должен отвечать за конкретную бизнес-возможность или функциональность (например, корзина покупок, профиль пользователя, каталог товаров).
+- Это позволяет командам фокусироваться на своей области ответственности и независимо развивать свои части приложения.
+
+**Пример:**
+- Микрофронтенд "Каталог товаров" отвечает за отображение и фильтрацию товаров.
+- Микрофронтенд "Корзина" отвечает за управление корзиной покупок.
+
+## 2. Автономность (Autonomy):
+- Каждый микрофронтенд должен быть независимым: разрабатываться, тестироваться и развертываться отдельно от других.
+- Это позволяет командам работать независимо, не блокируя друг друга.
+
+**Как достичь:**
+- Использование отдельных репозиториев для каждого микрофронтенда.
+- Независимые CI/CD-пайплайны для сборки и деплоя.
+
+## 3. Изоляция (Isolation):
+- Микрофронтенды должны быть изолированы друг от друга, чтобы изменения в одном микрофронтенде не влияли на другие.
+- Это достигается за счет четких границ между частями приложения.
+
+**Как достичь:**
+- Использование iframe, Web Components или модульных систем (например, Module Federation в Webpack).
+- Минимизация общих зависимостей между микрофронтендами.
+
+## 4. Слабая связанность (Loose Coupling):
+- Микрофронтенды должны взаимодействовать через четко определенные интерфейсы (API, события, сообщения).
+- Это позволяет изменять внутреннюю реализацию одного микрофронтенда, не затрагивая другие.
+
+**Пример:**
+Микрофронтенд "Корзина" может подписываться на события от микрофронтенда "Каталог" (например, "товар добавлен в корзину").
+
+## 5.Единый пользовательский интерфейс (Unified User Interface):
+- Несмотря на разделение, приложение должно выглядеть и работать как единое целое.
+- Это требует согласованности в дизайне, стилях и взаимодействии.
+
+**Как достичь:**
+- Использование общей библиотеки компонентов (например, Storybook).
+- Согласованные стандарты стилей (например, CSS-in-JS, общие переменные).
+
+## 6. Масштабируемость (Scalability):
+- Архитектура должна поддерживать добавление новых микрофронтендов без значительных изменений в существующих частях.
+- Это важно для больших команд и проектов, которые развиваются со временем.
+
+**Как достичь:**
+- Использование модульной системы (например, Webpack Module Federation).
+- Четкие правила интеграции новых микрофронтендов.
+
+## 7. Технологическая независимость (Technology Agnosticism):
+- Разные микрофронтенды могут быть написаны на разных технологиях (React, Vue, Angular и т.д.).
+- Это позволяет командам выбирать подходящие инструменты для своих задач.
+
+**Пример:**
+- Микрофронтенд "Каталог" написан на React.
+- Микрофронтенд "Корзина" написан на Vue.
+
+## 8. Совместное использование ресурсов (Shared Resources):
+- Общие ресурсы (например, библиотеки, стили, утилиты) должны быть вынесены в отдельные модули или пакеты.
+- Это помогает избежать дублирования кода.
+
+**Как достичь:**
+- Создание общей библиотеки компонентов.
+- Использование монорепозиториев (например, Nx, Lerna) для управления общими зависимостями.
+
+## 9. Маршрутизация (Routing):
+- Маршрутизация между микрофронтендами должна быть четко организована.
+- Это может быть реализовано как на уровне клиента (например, с помощью React Router), так и на уровне сервера (например, с помощью Nginx).
+
+**Пример:**
+- Маршрут /catalog загружает микрофронтенд "Каталог".
+- Маршрут /cart загружает микрофронтенд "Корзина".
+
+## 10. Безопасность (Security):
+- Каждый микрофронтенд должен быть защищен от несанкционированного доступа.
+- Это особенно важно, если микрофронтенды взаимодействуют с разными API или сервисами.
+
+**Как достичь:**
+- Использование CORS, JWT-токенов и других механизмов безопасности.
+- Изоляция данных между микрофронтендами.
+
+## Пример архитектуры микрофронтендов:
+1. **Микрофронтенд "Каталог":**
+   - Отвечает за отображение товаров и фильтров.
+   - Написан на React.
+   - Взаимодействует с API каталога.
+2. **Микрофронтенд "Корзина":**
+   - Отвечает за управление корзиной покупок.
+   - Написан на Vue.
+   - Взаимодействует с API корзины.
+3. **Микрофронтенд "Профиль":**
+   - Отвечает за управление профилем пользователя.
+   - Написан на Angular.
+   - Взаимодействует с API профиля.
+4. **Общая библиотека компонентов:**
+   - Содержит общие UI-компоненты (кнопки, формы, заголовки).
+   - Используется всеми микрофронтендами.
+
+## Преимущества микрофронтендов:
+1. Независимость команд: Команды могут работать над своими частями приложения, не блокируя друг друга.
+2. Гибкость в выборе технологий: Каждая команда может использовать подходящие для её задач технологии.
+3. Масштабируемость: Легко добавлять новые функции или микрофронтенды.
+4. Упрощение поддержки: Меньшие и более простые части кода легче поддерживать.
+
+## Недостатки микрофронтендов:
+1. Сложность интеграции: Требуется четкая организация взаимодействия между микрофронтендами.
+2. Дублирование кода: Возможно дублирование общих ресурсов, если они не вынесены в отдельные модули.
+3. Производительность: Загрузка нескольких микрофронтендов может увеличить время загрузки приложения.

docs/architecture/07-tdd.md

@@ -2,4 +2,66 @@
 sidebar_position: 7
 ---
 
-# Test driven development
+# Test driven development
+
+TDD (Test-Driven Development) — это методология разработки программного обеспечения, в которой написание тестов предшествует написанию кода. Основная идея TDD заключается в том, что разработчик сначала пишет тест для новой функциональности, а затем реализует код, который делает этот тест успешным. Этот процесс повторяется для каждой новой функции или улучшения.
+
+TDD основан на нескольких ключевых принципах, которые помогают создавать качественный, поддерживаемый и надежный код. Рассмотрим основные принципы TDD:
+
+## 1. Красный — Зеленый — Рефакторинг (Red — Green — Refactor):
+Это основной цикл TDD, который состоит из трех этапов:
+
+1. **Красный (Red):**
+   - Написание теста для новой функциональности, который изначально не проходит (тест "красный", так как функциональность ещё не реализована).
+   - Это помогает четко определить требования к коду.
+2. **Зеленый (Green):**
+   - Написание минимального количества кода, необходимого для того, чтобы тест прошел (тест становится "зеленым").
+   - На этом этапе важно не добавлять лишнюю функциональность.
+3. **Рефакторинг (Refactor):**
+   - Улучшение кода без изменения его поведения (например, устранение дублирования, улучшение читаемости).
+   - Рефакторинг выполняется только после того, как все тесты проходят.
+
+## 2. Тестируемый код:
+- Код, написанный с использованием TDD, изначально проектируется так, чтобы его можно было легко тестировать.
+- Это часто приводит к более модульной и слабо связанной архитектуре.
+
+## 3. Постепенное развитие (Incremental Development):
+- Функциональность добавляется небольшими шагами, каждый из которых сопровождается тестами.
+- Это позволяет избежать создания сложных и труднотестируемых систем.
+
+## 4. Тесты как документация:
+- Набор тестов служит живой документацией для кода, показывая, как он должен работать.
+- Это особенно полезно для новых разработчиков, которые могут быстро понять, что делает код.
+
+## 5. Минимальный рабочий код (Minimal Working Code):
+- На этапе "зеленого" теста пишется только тот код, который необходим для прохождения теста.
+- Это помогает избежать переусложнения и добавления ненужной функциональности.
+
+## 6. Частые запуски тестов:
+- Тесты запускаются после каждого изменения кода, чтобы убедиться, что новая функциональность не сломала существующую.
+- Это помогает быстро находить и исправлять ошибки.
+
+## 7. Покрытие кода тестами (Code Coverage):
+- TDD стремится к максимальному покрытию кода тестами, чтобы минимизировать вероятность ошибок.
+- Однако важно помнить, что 100% покрытие не всегда гарантирует отсутствие багов.
+
+## Преимущества TDD:
+1. Высокое качество кода:
+   - Код, написанный с использованием TDD, обычно более надежен и меньше подвержен ошибкам.
+2. Упрощение рефакторинга:
+   - Наличие тестов позволяет безопасно вносить изменения в код, не боясь сломать существующую функциональность.
+3. Четкие требования:
+   - Тесты помогают четко определить, что именно должен делать код.
+4. Раннее обнаружение ошибок:
+   - Ошибки обнаруживаются на ранних этапах разработки, что снижает стоимость их исправления.
+5. Улучшение архитектуры:
+   - Код становится более модульным и слабо связанным, так как он изначально проектируется для тестирования.
+
+## Недостатки TDD:
+1. Дополнительные затраты времени:
+   - Написание тестов требует времени, что может замедлить начальные этапы разработки.
+2. Кривая обучения:
+   - TDD требует определенного уровня навыков и дисциплины, что может быть сложно для новичков.
+3. Не всегда подходит:
+   - TDD может быть избыточным для небольших проектов или прототипов.
+

docs/architecture/08-dev-principles.md

@@ -0,0 +1,155 @@
+---
+sidebar_position: 8
+---
+
+# Принципы разработки
+Источник: DeepSeek \
+Дополнительный источник: [https://habr.com/ru/companies/itelma/articles/546372/](https://habr.com/ru/companies/itelma/articles/546372/)
+
+## YAGNI
+_You Aren’t Gonna Need It / Вам это не понадобится_
+
+Принцип YAGNI (англ. You Aren’t Gonna Need It — «Вам это не понадобится») — это концепция из методологии разработки программного обеспечения, которая гласит, что не следует добавлять функциональность в код до тех пор, пока она действительно не потребуется. Этот принцип является частью экстремального программирования (XP) и тесно связан с другими принципами, такими как KISS (Keep It Simple, Stupid) и DRY (Don’t Repeat Yourself).
+
+### Основные идеи YAGNI:
+1. **Избегание преждевременной оптимизации:**
+   - Не стоит тратить время на написание кода, который, возможно, никогда не будет использован.
+   - Это помогает избежать усложнения системы и снижает вероятность внесения ошибок.
+2. **Фокус на текущих требованиях:**
+   - Разработчики должны сосредоточиться на реализации только тех функций, которые необходимы прямо сейчас.
+   - Это позволяет быстрее выпускать рабочие версии продукта и получать обратную связь от пользователей.
+3. **Упрощение кода:**
+   - YAGNI способствует написанию более простого и понятного кода, так как в нем отсутствуют лишние элементы.
+   - Это облегчает поддержку и модификацию кода в будущем.
+4. **Экономия времени и ресурсов:**
+   - Не нужно тратить время на разработку и тестирование функциональности, которая может оказаться ненужной.
+   - Это позволяет сосредоточиться на действительно важных задачах.
+
+### Преимущества YAGNI:
+- Снижение сложности кода.
+- Уменьшение времени на разработку.
+- Более гибкая реакция на изменения требований.
+- Упрощение тестирования и поддержки.
+
+### Когда YAGNI не применим:
+- Если есть четкое понимание, что функциональность точно понадобится в ближайшем будущем.
+- Если добавление функциональности позже будет значительно дороже или сложнее.
+
+### Дополнительно
+Этот принцип прост и очевиден, но ему далеко не все следуют. Если пишете код, то будьте уверены, что он вам понадобится. Не пишите код, если думаете, что он пригодится позже. \
+Этот принцип применим при рефакторинге. Если вы занимаетесь рефакторингом метода, класса или файла, не бойтесь удалять лишние методы. Даже если раньше они были полезны – теперь они не нужны. \
+Может наступить день, когда они снова понадобятся – тогда вы сможете воспользоваться git-репозиторием, чтобы воскресить их из мертвых.
+
+## DRY
+_Don’t Repeat Yourself / Не повторяйтесь_
+
+Принцип DRY (англ. Don’t Repeat Yourself — «Не повторяйся») — это один из ключевых принципов разработки программного обеспечения, который направлен на минимизацию дублирования кода. Основная идея заключается в том, что каждая часть знания или логики в системе должна иметь единственное, однозначное и авторитетное представление в коде.
+
+### Основные идеи DRY:
+1. **Устранение дублирования:**
+   - Если один и тот же код или логика повторяются в нескольких местах, это увеличивает сложность поддержки и повышает риск ошибок.
+   - Вместо этого следует выносить повторяющийся код в отдельные функции, модули или классы.
+2. **Единая точка изменения:**
+   - Если логика должна быть изменена, это нужно сделать только в одном месте, а не во всех местах, где она используется.
+   - Это упрощает поддержку и снижает вероятность ошибок.
+3. **Повышение читаемости и поддерживаемости:**
+   - Код становится более компактным и понятным, так как логика не размазана по всей кодовой базе.
+
+### Преимущества DRY:
+1. **Снижение ошибок:**
+   - Меньше вероятность того, что изменения в логике будут внесены только в одном месте, а в других — забыты.
+2. **Упрощение поддержки:**
+   - Легче вносить изменения, так как логика сосредоточена в одном месте.
+3. **Улучшение читаемости:**
+   - Код становится более структурированным и понятным.
+4. **Экономия времени:**
+   - Не нужно копировать и вставлять код, а также тестировать его в нескольких местах.
+
+### Когда DRY не следует применять слепо:
+1. **Избыточная абстракция:**
+   - Иногда попытка устранить дублирование может привести к созданию сложных и ненужных абстракций, которые усложняют понимание кода.
+2. **Микрооптимизации:**
+   - Не стоит применять DRY для устранения дублирования, если это незначительные фрагменты кода, которые вряд ли будут изменяться.
+3. **Разные контексты:**
+   - Если дублирующийся код используется в разных контекстах и может изменяться независимо, то его объединение может привести к проблемам.
+
+### Связь с другими принципами:
+- **KISS (Keep It Simple, Stupid):** DRY помогает упрощать код, устраняя ненужное дублирование.
+- **YAGNI (You Aren’t Gonna Need It):** DRY не следует применять для создания абстракций, которые могут понадобиться в будущем, но не нужны сейчас.
+
+### Дополнительно
+Эта концепция была впервые сформулирована в книге Энди Ханта и Дэйва Томаса «Программист-прагматик: путь от подмастерья к мастеру».\
+Идея вращается вокруг единого источника правды (single source of truth — SSOT). Что это вообще такое? \
+Дублирование кода – пустая трата времени и ресурсов. Вам придется поддерживать одну и ту же логику и тестировать код сразу в двух местах, причем если вы измените код в одном месте, его нужно будет изменить и в другом. \
+В большинстве случаев дублирование кода происходит из-за незнания системы. Прежде чем что-либо писать, проявите прагматизм: осмотритесь. Возможно, эта функция где-то реализована. Возможно, эта бизнес-логика существует в другом месте. Повторное использование кода – всегда разумное решение.
+
+## KISS
+_Keep It Simple, Stupid / Будь проще_
+
+Принцип KISS (англ. Keep It Simple, Stupid — «Делай проще, тупица») — это концепция в разработке программного обеспечения, которая подчеркивает важность простоты и минимализма в проектировании и реализации систем. Основная идея заключается в том, что простые решения чаще всего являются лучшими, так как их легче понимать, поддерживать и модифицировать.
+
+### Основные идеи KISS:
+1. **Упрощение кода:**
+   - Код должен быть настолько простым, насколько это возможно, но не проще.
+   - Сложные конструкции и избыточные абстракции следует избегать.
+2. **Минимизация сложности:**
+   - Чем проще система, тем меньше вероятность возникновения ошибок и тем легче её поддерживать.
+   - Простота также облегчает понимание кода новыми разработчиками.
+3. **Фокус на решении задачи:**
+   - Не стоит добавлять функциональность, которая не требуется для решения текущей задачи.
+   - Это связано с принципом **YAGNI** (You Aren’t Gonna Need It).
+4. **Избегание «умного» кода:**
+   - Код, который выглядит «умным» (например, с использованием сложных языковых конструкций или оптимизаций), часто сложен для понимания и поддержки.
+   - Лучше писать код, который легко читать и понимать.
+
+### Преимущества KISS:
+1. **Упрощение поддержки:**
+   - Простой код легче понимать и изменять, что снижает затраты на поддержку.
+   - Снижение вероятности ошибок:
+   - Чем меньше сложность, тем меньше вероятность допустить ошибку.
+2. **Ускорение разработки:**
+   - Простые решения быстрее реализуются и тестируются.
+3. **Улучшение читаемости:**
+   - Код становится более понятным для других разработчиков, что особенно важно в командной работе.
+
+### Когда KISS не следует применять слепо:
+1. **Оптимизация производительности:**
+   - Иногда для достижения необходимой производительности требуется более сложный код.
+   - Однако даже в таких случаях следует стремиться к балансу между простотой и эффективностью.
+2. **Специфические требования:**
+   - В некоторых случаях сложные решения могут быть оправданы, если они соответствуют бизнес-требованиям или ограничениям системы.
+
+### Связь с другими принципами:
+- **YAGNI (You Aren’t Gonna Need It):** KISS поддерживает идею о том, что не следует добавлять ненужную функциональность.
+- **DRY (Don’t Repeat Yourself):** KISS помогает избегать избыточного дублирования, но не за счет усложнения кода.
+- **SOLID:** KISS дополняет принципы SOLID, делая акцент на простоте и ясности кода.
+
+### Дополнительно
+Этот принцип был разработан ВМС США в 1960 году. Этот принцип гласит, что простые системы будут работать лучше и надежнее.\
+Применительно к разработке ПО он значит следующее – не придумывайте к задаче более сложного решения, чем ей требуется.\
+Иногда самое разумное решение оказывается и самым простым. Написание производительного, эффективного и простого кода – это прекрасно.
+
+## SOLID
+Принципы SOLID — это набор из пяти ключевых принципов объектно-ориентированного программирования и проектирования, которые помогают создавать гибкие, поддерживаемые и масштабируемые программные системы. Аббревиатура SOLID была введена Робертом Мартином (известным также как Uncle Bob) и расшифровывается следующим образом:
+
+### Simple responsibility principle (принцип единой ответственности)
+У класса должна быть только одна причина для изменения, то есть у него должна быть только одна ответственность или работа. Этот принцип помогает сделать занятия более целенаправленными, более понятными и менее подверженными ошибкам.
+
+### Open – Closed Principle (Принцип открытости/закрытости)
+Программные сущности должны быть открыты для расширения, но закрыты для модификации. Это означает, что вы должны иметь возможность добавлять новые функции в систему, не изменяя существующий код.
+Мы можем расширить функциональный компонент и добавить новый компонент пользовательского интерфейса, не затрагивая первый/базовый компонент. Это реализация открытости для расширения, но закрытости для модификации.
+
+### Liskov Substitution principe (принцип замены Лискова)
+Объекты суперкласса должны быть заменяемы объектами его подклассов без нарушения корректности программы. Другими словами, подклассы должны иметь возможность заменять свои базовые классы без возникновения ошибок.
+
+### Interface segregation principle (Принцип разделения интерфейсов)
+Клиентов не следует заставлять зависеть от интерфейсов, которые они не используют. Вместо этого интерфейсы следует разделить на более мелкие, более целенаправленные интерфейсы, соответствующие потребностям клиента.
+
+### Dependency inversion principle (Инверсия зависимости)
+Высокоуровневые модули не должны зависеть от низкоуровневых модулей. Вместо этого, оба должны зависеть от абстракций. Это помогает в разъединении модулей, делая их более пригодными для повторного использования и более простыми для тестирования.
+
+### Преимущества SOLID:
+1. **Гибкость:** Код становится проще расширять и модифицировать.
+2. **Поддерживаемость:** Упрощается понимание и исправление ошибок.
+3. **Тестируемость:** Код, соответствующий SOLID, легче тестировать.
+4. **Масштабируемость:** Система становится более устойчивой к изменениям и росту.