It's better to use apps.get_model, which guarantees the Model's fields will reflect the fields in the database even if models.py is vastly out of step with the database.

It's good to, as a minimum, specify noop in RunPython so the migration can be skipped when going backwards, and even better to specify a function that undoes the migration.

Hard-coding static asset urls is brittle because the place the files are stored depends on the `STATICFILES_STORAGE` used - so if in prod the storage backend uploads to S3 or even renames the file then this hard-coded URL will break.

Using "{% static ... %}" solves that as it knows exactly where the files are stored.

The order of middleware affections the outcome.

Some middleware are dependant on the functionality of other middlware. For example a middleware that requires usage of request.session should come after the SessionMiddleware.

URL names must be unique otherwise reverse('url_name') and {% url 'url_name' %} will link to the "wrong" page half of the time.

Using reverse(...) is better than using reverse_lazy(...) when the url is being reversed after URLConf has been loaded.

Incorrectly ordered middleware can stop the middleware working as intended.

Incorrectly ordered middleware can stop the middleware working as intended.

Hard-coding urls makes changing URLs harder, and makes linking to the wrong page easier - so harms maintainability.

unique_for_date/month/year is very brittle and over time will likely be a source for unexpected behaviour.

Using from django.conf import settings simplifies the code and makes it more maintainable.

Using TextField for very long string fields would simplify the code and make is easier to maintain.

NullBooleanField is deprecated and will be removed a future version of Django.

Stating defaults add complexity when reading the code but does not change Django's behaviour.

Stating defaults add complexity when reading the code but does not change Django's behaviour.

If null is True and blank is False then validation becomes more complex.

A non-unique primary key allows the same value to be used for multiple records thus multiple results could be returned for Model.objects.get(pk=1).

The TEMPLATE setting is a list of the template engines used when finding template files and rendering them.

The DIRS key within the TEMPLATE list denotes the directories where the engine should look for template source files.

DIRS must be absolute paths. Relative paths will not work.

The TEMPLATE setting is a list of the template engines used when finding template files and rendering them.

The DIRS key within the TEMPLATE list denotes the directories where the engine should look for template source files.

DIRS must be forward slashes, even in Windows. Forward slashes do not need escaping, and they are cross Operating System compatible.

ORM queries and Python code are made more complex because values will sometimes be None and other times str.

ORM queries are more readable and relationships more explicit when related_name is specified.

Increasing standardisation and predictability of your code style helps other developers read your code.

Predictable project structure and following common patterns simplifies maintenance of a codebase.

Django developers come to expect Admin-related objects to be in admin.py. Failure to do this will result in more time spent looking for where code lives.

A taller Model with many fields may be more difficult to maintain than a shorter Model with fewer fields.

Taller models.py with many Models may be more difficult to maintain than shorter models.py with fewer Models.

Taller models.py with many Models may be more difficult to maintain than shorter models.py with fewer Models.