Dmitry Belan
79 lines
8.1 KiB
Markdown
79 lines
8.1 KiB
Markdown
### Задача 11. Рефакторинг системы управления интернет-магазином
|
||
|
||
**Контекст**
|
||
|
||
Вам достался legacy-код системы управления интернет-магазином, расположенный в файле `legacy_shop.py`.
|
||
|
||
Код является абсолютно **монолитным**: вся логика (регистрация пользователей, авторизация, корзина, оформление заказов, расчёт доставки для разных городов, применение промокодов и админ-отчёты) написана сплошным линейным потоком внутри интерактивного CLI-интерфейса. В программе **нет ни одной функции и ни одного класса**. При этом код содержит огромное количество дублирования логики (copy-paste), нарушает стандарты PEP 8, не имеет обработки ошибок и сложен в поддержке.
|
||
|
||
---
|
||
|
||
**Ваша задача:**
|
||
|
||
Провести полный рефакторинг этого кода, разделив его на модули, применив объектно-ориентированное программирование (ООП) и исправив стиль кодирования.
|
||
|
||
#### Шаг 1. Анализ и исправление стиля (PEP 8)
|
||
- Приведите весь код в соответствие со стандартами **PEP 8**:
|
||
- Устраните отсутствие пробелов вокруг операторов (например, `x=y+z`).
|
||
- Исправьте именование переменных на `snake_case`.
|
||
- Уберите «волшебные числа» и жестко захардкоженные пароли (например, пароль админа), вынеся их в константы или конфигурацию.
|
||
|
||
#### Шаг 2. Декомпозиция логики в функции
|
||
- Найдите все повторяющиеся и логически обособленные куски кода и вынесите их в отдельные переиспользуемые функции с понятными названиями.
|
||
- **Особое внимание уделите:**
|
||
- Валидации полей при регистрации пользователя (сейчас проверки скопированы для каждого поля отдельно).
|
||
- Расчету стоимости доставки (уберите дублирование формул для 10+ городов, обобщите логику).
|
||
- Применению промокодов (уберите длинный `if-elif` блок, заменив его на структуру данных/словарь соответствий или единую формулу).
|
||
- Валидации чисел при вводе количества товаров и цен.
|
||
|
||
#### Шаг 3. Проектирование ООП-архитектуры
|
||
#### Шаг 3. Проектирование ООП-архитектуры
|
||
- Вместо хранения сырых словарей (`dict`) и глобальных переменных спроектируйте систему классов. **Создавайте классы там, где они действительно выгодны** (например, там, где необходимо инкапсулировать состояние, защитить данные от некорректного изменения или связать данные с поведением). Подумайте, для каких сущностей достаточно простых структур данных/функций, а для каких необходимы полноценные классы:
|
||
- `Product` — модель товара (id, название, категория, цена, остаток на складе, sku, производитель).
|
||
- `User` — модель пользователя. Подумайте над наследованием: например, выделите базовый класс `User` и наследников `Customer` (клиент) и `Admin` (администратор) с разным уровнем прав, если это упростит разграничение доступа.
|
||
- `Cart` — корзина покупателя, управляющая добавлением товаров, изменением количества и подсчетом промежуточного итога (здесь класс выгоден для управления состоянием).
|
||
- `Order` — заказ пользователя (детали доставки, примененная скидка, стоимость доставки, итоговая сумма, статус).
|
||
- `Database` — сервис для работы с файлами базы данных (`users.json`, `products.json`, `orders.json`). Должен инкапсулировать логику чтения и записи.
|
||
- `Shop` — центральный сервис-фасад, координирующий бизнес-логику магазина.
|
||
|
||
#### Шаг 4. Создание модульной файловой структуры
|
||
Разделите проект на логические части и файлы. Итоговая структура должна выглядеть следующим образом:
|
||
```
|
||
shop/
|
||
├── __init__.py
|
||
├── models/
|
||
│ ├── __init__.py
|
||
│ ├── product.py
|
||
│ ├── user.py
|
||
│ ├── order.py
|
||
│ └── cart.py
|
||
├── services/
|
||
│ ├── __init__.py
|
||
│ ├── shop.py
|
||
│ └── database.py
|
||
├── utils/
|
||
│ ├── __init__.py
|
||
│ └── validators.py
|
||
└── main.py
|
||
```
|
||
- В `main.py` должен остаться только запуск приложения и минималистичный интерактивный CLI-интерфейс, вызывающий методы класса `Shop`.
|
||
|
||
#### Шаг 5. Качество кода и надежность
|
||
- Добавьте осмысленные docstring'и ко всем классам, методам и модулям.
|
||
- Используйте аннотации типов (type hints) для аргументов функций и возвращаемых значений.
|
||
- Добавьте обработку исключений (`try-except`) в места взаимодействия с файловой системой (загрузка/сохранение БД) и при вводе некорректных данных пользователем.
|
||
- **Проверка стиля кода**: Для проверки соответствия стандартам стиля запустите линтер `flake8` в корне проекта:
|
||
```bash
|
||
flake8 shop/
|
||
```
|
||
|
||
---
|
||
|
||
**Критерии оценки:**
|
||
|
||
1. **Работоспособность**: после рефакторинга весь функционал приложения (от регистрации до админских отчетов) должен работать точно так же, как в исходном файле.
|
||
2. **Чистота кода**: отсутствие дублирования логики (DRY), понятные имена переменных и методов. **Команда `flake8 shop/` не должна выводить никаких предупреждений или ошибок.**
|
||
3. **Качество ООП**: грамотное распределение ответственности между классами, использование инкапсуляции (скрытие внутренних данных), осмысленное применение ООП.
|
||
4. **Модульность**: логичное разделение кода по файлам в папке `shop/`.
|
||
|