Правила написания кода Django для чистых проектов, работает с любой архитектурой.
PEP 8 - поддерживаем стандартный стиль PEP8, все программисты его понимают, а поэтому всем будет легко разобраться. Подключение linter желательно: Flake8, PyLint, Black.
DRY - не повторяем код ни в каких случаях! Всегда лучше написать отдельную функцию, чем сделать CTRL+C
Правильное наименование - переменные, классы и функции должны иметь правильные названия, полное отсутствие переменных a, b, с.
Название переменной - отображает значение которое она хранит, то есть, не нужно использовать глаголы в названии, а только существительные.
username = "Andrey" # хорошее название
create_username = "Andrey" # плохо, переменная использует глагол.
a = 1023 # непонятно что за значение хранится
user_balance = 1023 # хорошее название, мы понимаем зачем переменная нужна.
Название функции - отображает действие которое она выполняет. Нужно использовать глагол или как-то показывать что делает функция. Важно, что мы не показываем как функция это делает, то есть не раскрываем внутренности.
def create_user(): # хорошее название.
def new_user(): # плохое название, мы не понимаем что делает функция. Возвращает нового пользователя или берет последнего созданного пользователя?
def a(): # плохое название
Название классов - похоже на название переменных, работает похожим образом.
Название views - начинается с модели, должно заканчиваться на View. Пример: UserCreateView.
Название ViewSet - тоже самое что и во views, только заканчивается на ViewSet. Пример: UserViewSet.
Название приложений - с маленькой буквы во множественном числе.
Сокращения должны отсутствовать полностью. Если у вас есть value, то это не val.
Название файлов - с маленькой буквы во множественном числе.
"products.py" # хорошее
"product.py" # плохое
Использование typings обязательно! Без них с кодом очень сложно разобраться.
Организация кода по приложениям - вы должны логически разделить ваш код на приложения, и сделать так чтобы часть одного приложения не перетекала в другую. То есть, если у вас есть приложение services и приложение cards, то модели, view, логика и все другие аспекты этих приложений должны быть раздельны! Настолько раздельны, что вы можете скопировать папку и перенести ее в другой Django проект таким образом, чтобы все view этого приложения работали без каких-либо проблем.
Настройки - только один файл для настроек! Никаких settings/base.py, settings/production.py и похожих вариантов. Если в вашем Django проекте больше 1 файла для настроек, то вам будет очень сложно добавлять новые переменные и менять старые. Нужно сделать так, чтобы вы могли запустить 1 файл с настройками под production, dev, test и local разработку. Сделать это можно при помощи разных конфигурационных файлов с переменными или похожих if:if DEBUG: добавляем что-то для дебага.
Использование swagger, OpenAPI или любой другой авто-документации обязательно!
Использование Postman или похожей программы для API коллекции обязательно!
Всегда используйте названия аргументов!
def create_user(username: str, password: str) -> User: ...
create_user("Andrey", "123jioajdsr2") # плохо
create_user(username="Andrey", password="123jsidojf42") # хорошо
Чтобы люди всегда использовали названия, вы можете написать функцию так:
def create_user(*, username: str, password: str) -> User: ...
create_user("Andrey", "123jioajdsr2") # ошибка!!!
create_user(username="Andrey", password="123jsidojf42") # все хорошо
Когда мы работаем с кодом, у нас должна идти следующая цепочка:
graph LR
A[Web Server] --> B[WSGI]
B --> C[View]
C --> D[Бизнес логика]
D --> E[ORM]
E --> F[База данных]
Каждая часть отвечает за разные аспекты кода: