Django 30. Рефакторинг и допущенные ошибки

Ошибки - неотъемлемая часть программирования. Как ни старайся, всё равно допустишь ошибки, которые по началу сочтёшь мелкими и незначительными, а по факту они соберутся в "снежный ком".

Приступив к написанию одного из следующих постов, я обнаружил несколько неудобных моментов в своём коде. Этого можно было бы избежать изначально, но невнимательность сделала своё дело.

В этом посте я проведу небольшой рефакторинг, а вернее даже, реорганизацию своего кода (и чуть-чуть скреплю это "костылями" и "синей изолентой").

Директория с шаблонами.

Начнём с простого. Сейчас есть всего одно приложение blog и директория с шаблонами находится в нём, но в будущем (и как следовало бы, в прошлом) будет несколько приложений. Каждое будет отвечать за свою область и у всех будут свои шаблоны. Делать в каждом приложении свою директорию с шаблонами не очень красиво, удобнее всё собрать в одном месте.

К слову, это даже было предусмотрено. Изначально в посте по первоначальной настройке, мы добавили в параметр TEMPLATES строку - 'DIRS': [BASE_DIR / 'templates'],.

Решение проще некуда. Достаточно просто вынести директорию templates из директории приложения в директорию уровнем выше, где находится файл manage.py.

В ней находится директория blog, отвечающая за шаблоны приложения blog. В дальнейшем будут другие директории одноимённые используемым приложениям.

Документирование.

Классов, методов и функций становится всё больше, порой даже можно забыть зачем писал что-то. По-хорошему нужна хотя бы минимальная документация для класса и методов в нём.

Задача простая и поправимая, главное не забыть писать комментарии к чему-либо сразу при написании.

Разделение на приложения.

Добрались до главной ошибки.

В Django принято разделять логические участки на отдельные приложения, например, приложение для блога, приложение для API, приложение для аутентификации и профиля пользователя и так далее.

Моя ошибка заключается в том, что я блог и API уместил в одном приложении блога. Это не критичная ошибка, всё работает, однако это создаёт проблему навигации по коду. Код разрастается, состоит из блоков для разных задач.

Для исправления этой ситуации, я создам новое приложение api_app и перенесу в него всё, что связано с API. И всё бы ничего, но у меня есть несколько моделей и они содержат данные в БД. Простого способа перенести модель из приложения в приложение с сохранением данных в новой таблице я не нашёл. Однако есть один, весьма простой, но "костыльный" способ.

Если вы ещё только в процессе разработки сайта, не "пихайте" всё в одно приложение. Продумайте "на берегу" структуру и будущие модули. Я этого не сделал, теперь буду городить "костыли". Главное вовремя найти ошибку, исправить её и выучить урок.

Создание нового приложения.

Создадим новое приложение api_app выполнив команду python manage.py startapp api_app.

Переходим сразу в settings.py и добавляем новое приложение в INSTALLED_APPS.

И создадим файл urls.py в директории приложения api_app.

Перенос моделей и файлов.

Далее необходимо перенести всё связанное с API из приложения blog в приложение api_app.

Начнём с модели. Полностью вырезаем код необходимых моделей и переносим его в файл models.py в новом приложении.
Проверяем, не осталось ли каких-либо связей в других моделях относительно перенесённых. Если остались, правим импорты.

Затем в класс Meta перенесённых моделей добавляем новый пункт app_label и указываем имя старого приложения.
Таким образом код у нас находится в новом приложении, но модель считается моделью старого приложения и таблицы БД не будут перезаписаны. Если у вас нет данных в БД, пометку делать не нужно.

Далее переносим из файла admin.py связанные классы. Правим импорты.

Переносим файлы api.py и serializers.py. Правим импорты.

Переносим URL-паттерны для API из файла urls.py в новое приложение. Правим импорты и переходим в файл urls.py, находящийся в директории проекта. Добавляем новый паттерн path('api/', include('api_app.urls', namespace='api_app')),.

Применяем миграции. Результатом должно быть отсутствие новых миграций.

Готово. Всё должно работать, как и раньше.

Завершение.

Да, модели хоть и находятся на новом месте, но относятся к старому. Возможно в будущем, углубившись в Django я найду решение с "безболезненным" переносом данных модели. Но пока оставлю так, как говорится "надо было думать раньше".

Возможно, в моём коде есть ещё ошибки которые я не замечаю, буду рад если укажете на них в комментариях.