¿Qué es Django?

Django es un framework web de código abierto basado en Python que ayuda a crear aplicaciones web. La popularidad de este framework aumentó rápidamente en los últimos años. Comparado con otros marcos basados en Python como Flask, Django es el más popular entre los desarrolladores de Python. Es compatible con las versiones Python 2.7+ y Python 3.x., actualmente la última versión de Django es la 4.

Recuerde el concepto "Modelos fat, vistas delgadas"

Escribir la lógica de su aplicación en vistas en lugar de modelos significa que ha escrito código que pertenece a su modelo en la vista, haciéndolo "grueso" y su modelo "delgado".

Deberías escribir modelos gordos, vistas flacas.

Divida la lógica en pequeños métodos en sus modelos. Esto le permite usarlo varias veces desde múltiples fuentes (IU de interfaz de administración, IU de front-end, puntos finales de API, múltiples vistas) en unas pocas líneas de código en lugar de copiar y pegar toneladas de código. Entonces, la próxima vez que envíe un correo electrónico a un usuario, amplíe el modelo con una función de correo electrónico en lugar de escribir esta lógica en su controlador.

Esto también hace que su código sea más fácil de probar porque puede probar la lógica del correo electrónico en un solo lugar, en lugar de repetidamente en cada controlador donde esto ocurre.

No use ForeignKey con unique=True

No tiene sentido usar ForeignKey con unique=True ya que existe OneToOneField para tales casos.

Usa .first() en lugar de .get()

En las vistas de Django, debe evitar usar Models.objects.get(condition) en algunos casos, en su lugar debe usar 

Models.objects.filter(condition).first()

Esos algunos casos son básicamente cuando no desea un error del backend cuando no se cumple la condición de obtención. Siempre que desee hacer algo como: 

• Si el objeto existe entonces devuelve el objeto 
• Si el objeto no existe entonces no devuelve nada 

Entonces usa .filter(..condition).first() .

Sin mencionar que siempre puede usar get_object_or_404 (condición), pero esto es cuando necesita arrojar errores 404 en situaciones no encontradas.

Evite la redundancia en los modelos

Si está justificado, puede reemplazar muchos BooleanFields con un campo. En lugar de tener muchos campos como is_verified, is_published, is_draft, podemos reducirlo a un campo como estado.

class Article(models.Model):
    is_published = models.BooleanField(default=False)
    is_verified = models.BooleanField(default=False)
    is_draft = models.BooleanField(default=False)

Supongamos que una lógica de nuestra aplicación es que un artículo no se publica y verifica inicialmente, luego se verifica y se marca como verificado, es decir, is_verified = True y luego se publica. Puede notar que los artículos no se pueden publicar sin ser revisados. Entonces, hay 3 condiciones en total, pero con 3 campos booleanos no tenemos 6 variantes posibles, y debe asegurarse de que no haya artículos con combinaciones de condiciones de campos booleanos incorrectas. Es por eso que usar un campo de estado en lugar de dos campos booleanos es una mejor opción:

class Article(models.Model):
    STATUSES = Choices('new', 'verified', 'published', 'draft')
    status = models.IntegerField(choice=STATUSES, default=STATUSES.draft)

Este ejemplo puede no ser muy ilustrativo, pero imagine que tiene 4 o más de estos campos booleanos en su modelo, y el control de validación para estas combinaciones de valores de campo puede ser realmente tedioso.

Uso de un entorno virtual

Al desarrollar cualquier aplicación basada en Python, la instalación de bibliotecas de terceros es un requisito inseparable. Mantenerlos organizados es algo esencial ya que esos paquetes se actualizan con frecuencia. Cuando desarrollamos varias aplicaciones de Python en la misma máquina local, es muy difícil hacer un seguimiento de todos y cada uno de los paquetes. No es posible usar diferentes versiones de los paquetes para múltiples proyectos. A veces, actualizar un paquete para un proyecto puede romper las configuraciones de otros proyectos.

La solución para el problema anterior es usar entornos virtuales. Para instalar un entorno virtual en Python, siga las instrucciones del anterior enlace.

Hacer un mejor uso de las aplicaciones

Una buena aplicación es una aplicación que escala

Esto puede ser tonto y obvio, pero aun así, recomendaría dividir el proyecto en pequeñas aplicaciones. De esa manera, no solo puede deshacerse de la complejidad, sino que también puede reutilizar la aplicación en cualquier otro escenario de caso de proyecto.

Por ejemplo, está creando una aplicación de redes sociales, por lo que puede crear una aplicación para administrar usuarios, una para administrar publicaciones, otra para blogs, etc.

Mantenga la configuración de producción separada de la de desarrollo

El módulo de configuración de Django es un archivo central en los proyectos de Django. Contiene todos los valores de configuración que su aplicación web necesita para funcionar; configuración de la base de datos, configuración de registro, dónde encontrar archivos estáticos, claves de API si trabaja con API externas y muchas otras cosas.

Nunca use la misma configuración.py para desarrollo y producción.

Así es como se ve la configuración predeterminada del proyecto

|-- /myproject
|   |-- settings.py
|   |-- urls.py
|   |-- wsgi.py
|   |-- asgi.py
|-- manage.py

Aquí hay un mejor enfoque que puede usar para hacer su trabajo:

|-- myproject
|   |-- settings
|       |-- __init__.py
|       |-- base.py
|       |-- development.py
|       |-- production.py
|   |-- urls.py
|   |-- wsgi.py
|   |-- asgi.py
|-- manage.py

__init__.py para declarar la nueva configuración del módulo. (aunque no es necesario para las versiones más nuevas de Django)

Todo su código settings.py predeterminado va en base.py

Ahora puede definir qué configuraciones poner en desarrollo o en producción.

Para desarrollo

from .base import *
DEBUG = True

Para producción

from .base import *
import django_heroku # used only in production of heroku apps
DEBUG = False
ALLOWED_HOSTS = ['localhost', '127.0.01', 'domainforsale.com']
SUPER_SECRET_KEY = 'cant_afford_server_cost'
django_heroku.settings(locals())

¡Oh! y, por cierto, recomendaría enfáticamente usar un archivo .env para almacenar estos valores como DEBUG, ALLOWED_HOSTS, claves API y todo.

Quizás se pregunte: ¿cómo sabe Django qué archivo de configuración cargar en cada entorno? Para eso se usa el archivo __init__.py. Cuando Django busca settings.py, solía cargar al ejecutar el servidor, por ejemplo, ahora encuentra un módulo de configuración en lugar de un archivo settings.py. Pero siempre que sea un módulo que contenga un archivo __init__.py, en lo que respecta a Django, es exactamente lo mismo. Django cargará el archivo __init__.py y ejecutará lo que esté escrito en él.

SI NO FUNCIONA O TIENE UN ERROR, DEBE SER POR UNO DE manage.py, wsgi.py o asgi.py

Debe agregar DJANGO_SETTINGS_MODULE en .env para decirle a Django con qué archivo de configuración ejecutar el servidor.

Use vistas integradas basadas en clases en lugar de crear un desorden

Siempre, siempre, siempre use una vista basada en clases si desea evitar la redundancia. No tiene idea de cuánto tiempo y esfuerzo pueden ahorrarle.

Por ejemplo:

• Use las vistas base siempre que necesite manejar solicitudes básicas de manera ordenada
• Utilice las vistas de visualización genéricas siempre que necesite obtener una lista de datos o una fila específica de la tabla.
• Utilice Vistas de edición genéricas para crear hermosos formularios a través de Vista de formulario para que pueda CREAR, ACTUALIZAR o ELIMINAR datos de la base de datos.
• Utilice vistas de plantilla (parte de la vista base) para el diseño y la manipulación avanzados de plantillas sobre la marcha
• PAGINACIÓN: esta es una de mis características favoritas sobre las vistas, ya no tiene que escribir código para las paginaciones, Django tiene todo para usted.

Articulo recomendado:

https://medium.com/geekculture/django-best-practices-mistakes-7e7ae5dcf89c