Організація коду в додатку

Давайте поговоримо про організацію коду всередині додатку.

Уявіть, що ви готуєте вечерю на кухні. В ідеалі, у вас є різні шафи для каструль, сковорідок, тарілок, а у холодильника — свої полиці для овочів і продуктів. В іншому випадку ви витрачаєте купу часу на пошуки ножа чи солі, а процес приготування перетворюється на хаос.

Те ж саме з кодом. Якщо ви не розбиваєте проєкт на логічні модулі, то з ростом додатку вам буде все складніше знаходити потрібні файли, а нові розробники на проєкті почнуть ставити незручні запитання на кшталт: "А навіщо у нас три views.py?" або "Чому файл із логікою замовлення їжі називається utils.py, а не знаходиться у додатку для доставки?"

Застосовуючи осмислену структуру у вашому додатку, ви:

• Легко знаходите потрібний код і файли.
• Робите додаток читабельним для інших розробників (і для себе через пів року).
• Знижуєте ризик багів, пов'язаних із заплутаною логікою.
• Відкриваєте шлях до модульного тестування.

Важливе правило: організація коду залежить від функціональності додатку. Для невеликих додатків проста структура може бути достатньою, але для великих варто подумати про розділення логіки на модулі.

Основні модулі всередині застосунку

Запустимо команду python manage.py startapp blog. Ми отримуємо "скелет" застосунку з приблизно такою структурою:

blog/
├── migrations/
│   └── __init__.py
├── __init__.py
├── admin.py
├── apps.py
├── models.py
├── tests.py
├── views.py

• migrations/: Улюблені друзі баз даних. У цьому каталозі зберігаються файли міграцій — інструкції щодо зміни структури бази даних відповідно до моделей.

• __init__.py: Просто робить наш каталог Python-пакетом. Не видаляємо.

• admin.py: Тут налаштовується відображення моделей в адмінці. Можна кастомізувати список, додати фільтри і так далі.

• apps.py: Файл конфігурації застосунку, який Django використовує при запуску.

• models.py: Місце, де описуються моделі (тобто, структура даних, яка буде зберігатися в базі).

• tests.py: Порожнє місце для тестів. Про тестування поговоримо пізніше.

• views.py: Той самий файл, де живуть представлення (views).

Якщо все виглядає знайомо, чудово! Але насправді набір цих файлів — лише відправна точка. У реальному проєкті ми можемо (і повинні) додавати нові файли та модулі, щоб зберігати логіку у зрозумілих місцях.

Розділення логіки всередині додатка

Ти, напевно, чув таке поняття, як "спагетті"-код. Це коли представлення, моделі та маршрути в проєкті перемішані, і можуть виглядати як заплутані макарони. Уяви, що у файлі views.py міститься 300 рядків коду — представлення для всього додатка: CRUD для блогу, обробка форми для коментарів, API для лайків і все інше.

Рішення: розділяй логіку на більш дрібні модулі. Замість одного гігантського файлу views.py можна створити папку views/ і рознести все окремо. Наприклад:

blog/
├── views/
│   ├── post_views.py
│   ├── comment_views.py
│   └── like_views.py

Тепер кожне представлення живе у своєму файлі, і шукати їх стало набагато легше. Але це тільки початок.

Приклад структури додатка

Для додатка "Блог" (де є статті, коментарі, автори та лайки) структура може виглядати наступним чином:

blog/
├── migrations/
├── templates/
│   └── blog/
│       ├── post_list.html
│       ├── post_detail.html
│       └── comment_form.html
├── static/
│   └── blog/
│       ├── css/
│       ├── js/
│       └── images/
├── views/
│   ├── post_views.py
│   ├── comment_views.py
│   └── like_views.py
├── forms.py
├── models/
│   ├── post.py
│   ├── comment.py
│   └── author.py
├── urls.py
└── admin.py

Розберемо, чому така структура зручна:

1. Папка views/: представлення розділені за сутностями. Якщо тобі потрібно відредагувати CRUD-компонент для постів — заходь у post_views.py. Мінімальний хаос.

2. Папка models/: тут також усе розділено. Кожна головна сутність додатка (наприклад, Пост, Коментар) має окремий файл моделі. Це особливо корисно, якщо у моделей багато полів і методів.

3. forms.py: усі форми (наприклад, форма для додавання коментаря) зберігаються в одному місці.

4. Папка templates/blog/: Django дозволяє створювати інфернальні папки для шаблонів, але завжди краще тримати всі шаблони в каталозі, що відповідає назві додатка.

5. Папка static/blog/: аналогічно із шаблонами — організовуємо статичні файли в папці, що відповідає додатку.

Цей принцип — розділення за функціоналом і сутностями — є ключовим для побудови акуратного проєкту.

Найкращі практики (Best Practices) з організації

Щоб твій код виглядав так само приємно, як чистий робочий стіл:

• Діли представлення на модулі: якщо додаток стає занадто великим, не бійся ділити код на підкаталоги.
• Розділяй файли моделей: якщо моделей багато, краще винести їх у підкаталог.
• Не зловживай utils.py: завжди є спокуса кинути код "кудись". Краще виписувати окремі модулі для допоміжної логіки (наприклад, services.py або helpers.py).
• Дотримуйся іменування: назви файлів і модулів мають бути інтуїтивними. Краще назвати файл post_views.py, ніж misc_views.py.

Практичні завдання

Завдання 1: Рефакторинг додатку "Блог"

1. Створи в твоєму додатку "Блог" директорії views/ і models/.
2. Перемісти логіку для роботи з постами у файл views/post_views.py.
3. Розділи моделі за сутностями: створи файл models/post.py для моделі поста і models/comment.py для моделі коментарів.
4. Налаштуй імпорти, щоб проект продовжував працювати.

Завдання 2: Структурування шаблонів

1. Створи папку templates/blog/ і перенеси туди всі шаблони, пов'язані з додатком "Блог".
2. Перевір правильність шляхів у представленнях.

Завдання 3: Організація статичних файлів

1. Додай папку static/blog/ і перенеси туди хоча б один CSS-файл.
2. Переконайся, що статичні файли завантажуються коректно.