Добавить VIPER чеклист

VIPER-%D1%87%D0%B5%D0%BA%D0%BB%D0%B8%D1%81%D1%82.md

@@ -0,0 +1,51 @@
+Чеклист для VIPER:
+
+### **1. View (ViewController)**
+- [ ] **Не содержит бизнес-логики**. ViewController отвечает только за отображение данных и управление пользовательским интерфейсом.
+- [ ] **Работает только с ViewModel**. Данные передаются в виде ViewModel, подготовленной Presenter.
+- [ ] **Инициирует запросы напрямую в Interactor**. ViewController передает запросы на действия пользователя напрямую в Interactor.
+- [ ] **Получает данные от Presenter**. После обработки запроса Interactor передает данные в Presenter, а Presenter передает их обратно в ViewController.
+- [ ] **Соблюдает принципы Single Responsibility**. ViewController отвечает только за отображение данных и взаимодействие с пользователем.
+
+### **2. Interactor**
+- [ ] **Содержит бизнес-логику**. Interactor обрабатывает запросы, выполняет бизнес-логику и взаимодействует с Entity.
+- [ ] **Получает запросы от View напрямую**. Все запросы на обработку данных поступают в Interactor напрямую от ViewController.
+- [ ] **Обрабатывает данные и передает результаты в Presenter**. После обработки данных Interactor передает результаты в Presenter для подготовки данных к отображению.
+- [ ] **Не имеет прямого доступа к UI**. Interactor взаимодействует с Presenter и Entity, не имея доступа к View.
+- [ ] **Асинхронные операции**. Любые длительные операции (например, сетевые запросы, работа с базой данных) должны выполняться в Interactor.
+
+### **3. Presenter**
+- [ ] **Получает данные от Interactor**. После выполнения бизнес-логики Interactor передает данные Presenter.
+- [ ] **Подготавливает данные для View**. Преобразует данные в ViewModel для отображения в View.
+- [ ] **Передает данные обратно в View**. После подготовки ViewModel данные передаются в View для отображения.
+- [ ] **Не содержит бизнес-логики**. Presenter только управляет потоком данных и подготовкой ViewModel.
+
+### **4. Entity**
+- [ ] **Содержит только данные и доменную логику**. Entity представляет собой объекты данных, которые могут включать методы для работы с этими данными.
+- [ ] **Не содержит бизнес-логики**. Entity может включать простую доменную логику, но вся сложная бизнес-логика должна находиться в Interactor.
+- [ ] **Повторно используется в Interactor**. Entity может использоваться в нескольких Interactor'ах, если это необходимо.
+
+### **5. Router**
+- [ ] **Отвечает за навигацию**. Router отвечает за переходы между экранами и сборку модулей.
+- [ ] **Не содержит бизнес-логики или UI-кода**. Router только управляет навигацией и не вмешивается в обработку данных.
+- [ ] **Использует фабрику для создания модулей**. Router должен включать фабрику для создания View, Interactor, Presenter и их связывания.
+- [ ] **Передает данные между модулями**. При переходе на другой экран Router может передавать данные между модулями.
+- [ ] **Изолирует навигацию от View и Presenter**. View и Presenter не должны напрямую управлять навигацией.
+
+### **6. Общие принципы**
+- [ ] **Четкое разделение ответственности**. Каждый компонент VIPER должен четко выполнять свою роль.
+- [ ] **Минимизация зависимостей**. Компоненты должны быть слабо связаны и взаимодействовать через протоколы.
+- [ ] **Использование протоколов для общения**. Для общения между компонентами всегда должны использоваться протоколы.
+- [ ] **Тестируемость**. Каждый компонент должен быть легко тестируемым в изоляции от других.
+- [ ] **Правильное именование**. Имена компонентов и протоколов должны ясно отражать их роль и назначение.
+
+### **7. Архитектурные решения**
+- [ ] **Поддержка модульности**. Каждый экран или функциональность должна быть отдельным модулем VIPER.
+- [ ] **Использование Dependency Injection**. Для внедрения зависимостей рекомендуется использовать DI.
+- [ ] **Сохранение чистоты слоев**. Убедитесь, что бизнес-логика, UI-код и навигация четко разделены по слоям.
+- [ ] **Соблюдение односторонних связей**. Поток данных должен быть направлен только в одну сторону: View → Interactor → Presenter → View.
+
+### **8. Рефакторинг и поддержка**
+- [ ] **Регулярные ревью кода**. Проводите регулярные ревью кода для поддержания чистоты архитектуры.
+- [ ] **Обновление документации**. Документируйте каждый компонент и его взаимодействие с другими.
+- [ ] **Рефакторинг при необходимости**. Не бойтесь рефакторинга при обнаружении нарушений архитектурных принципов.