Худшие практики в Django, которые вы когда-либо видели

Ответ 1

Слишком много логики в представлениях.

Раньше я писал представления, которые могли бы вписаться в 40 строк. Теперь я рассматриваю более 2-3 уровней отступов, 10 или около того LOC или несколько встроенных комментариев, чтобы иметь запах кода.

Искушение состоит в том, чтобы писать минимальные модели, определять маршрутизацию URL-адресов, а затем делать все остальное в представлении. В действительности вы должны использовать модельные методы, менеджеров, теги шаблонов, контекстные процессоры, представления на основе классов с абстрактными базовыми представлениями... все, чтобы код представления был прост и читабельным. Логика вокруг сохраняющих форм должна идти в Form.save(). Логика, повторяющаяся в начале или в конце нескольких видов, должна идти в декораторах. Повторная логика отображения должна находиться в include d шаблонах, тегах шаблонов и фильтрах.

Длинные просмотры трудно читать, понимать и отлаживать. Научитесь использовать другие инструменты в своем наборе инструментов, которые вы сбережете себе и своей команде много боли.

Ответ 2

Не разбивать содержимое на несколько приложений. Это не столько о повторном использовании, сколько о том, чтобы иметь дюжину моделей и более 100 просмотров в одном приложении, это проклято нечитаемо. Кроме того, мне нравится иметь возможность автоматически сканировать мой urls.py файл, чтобы узнать, где находится URL-адрес, когда у меня есть 100 URL-адресов, которые становятся все сложнее.

Ответ 3

Я попытался добавить элементы к своей сессии, не копируя их, добавляя элементы, а затем добавляя список обратно в сеанс.

Эта ошибка находится на странице NewbieMistakes, поэтому, надеюсь, у меня хорошая компания.

Это правильный способ сделать это, если кому-то интересно.

sessionlist = request.session['my_list']
sessionlist.append(new_object)
request.session['my_list'] = sessionlist

Ответ 4

Я думаю, что самая большая проблема заключается в том, что люди пытаются кодировать, как если бы это была Java/C: они пытаются создать слишком общие приложения, которые никогда не должны меняться при изменении будущих требований (что необходимо для Java/C, поскольку эти приложения не являются так легко изменить/перепроектировать). Какие результаты - это ужасно сложное приложение, которое негибким и невозможно поддерживать.

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

Ответ 5

• Обезвреживание с предварительными и последующими событиями.

  Если вы не можете просто сделать это в save, вам следует, вероятно, пересмотреть то, что вы пытаетесь сделать. В конце концов, это просто реляционная база данных под капотом. Если то, что вы делаете, становится слишком сложным, у вас будут проблемы с отображением ORM.

• Попытка написать uber-generic - одно представление делает все это - функциональность. Функции просмотра - это функции по какой-либо причине. Они могут использовать модули, пакеты, объекты, другие функции и т.д. Они могут быть короткими и похожими, не будучи запахами кода.

  Если вам нужно использовать 10 строк кода для создания объекта uber-generic-do-it-all, и это была бы 12-строчная функция просмотра без объекта uber-generic-do-it-all, тогда Убер-объект не помогает.

• Наложение слишком большого количества сложного класса объектов на классы модели ORM. Если для этого требуются абстрактные базовые классы или метаклассы, это не будет хорошо работать на уровне ORM.

• Невозможно использовать tests.py и тестовый клиент для создания полных модульных тестов того, что он утверждал, что приложение делает.

Ответ 6

Худший момент facepalm... возврат неограниченного запроса, который длился несколько сотен тысяч строк. Это было в редко используемом бите кода, так что это случалось не часто, но когда это было сделано, это сбило сервер.

Всегда убедитесь, что результаты вашего запроса ограничены, то есть:

results = MyModel.query.all()[:100]

не

results = MyModel.query.all()

или используйте итератор:

for result in MyModel.query.iterator():

Ответ 7

Не использовать поля raw_id для ключа для 10000+ объектов, а затем интересно, почему посещение администратора приводит сервер на колени

Ответ 8

Я испытал худшую практику: используйте что-то еще, что идентификатор по умолчанию в качестве первичного ключа модели.

Это выглядело неплохой идеей, но это вызвало некоторые проблемы на веб-сайте администрации, и было трудно восстановить идентификатор как первичный ключ в существующей базе данных.

Я думаю, что нет конкретных случаев, которые достаточно специфичны, чтобы вызвать эти проблемы. Я рекомендую сохранить идентификатор вашей модели по умолчанию.

См. Каков наилучший подход к изменению первичных ключей в существующем приложении Django? для деталей

Ответ 9

Моя худшая ошибка заключалась в использовании абсолютного импорта, например <project_name>.<app_name>.models, а не <app_name>.models. Таким образом, когда я создал ветку и хотел проверить ее в другом каталоге (например, наличие и -stable моего проекта), он не запускался. Мне удалось вернуться в одном проекте и использовать только относительный импорт в одном проекте, но в другом, более крупном, мы должны придерживаться его (у нас есть как абсолютные, так и относительные). Я больше не буду повторять эту ошибку.

Ответ 10

В первую очередь я начинаю писать питон код без чтения PEP. Самое худшее, что я бы назвал:

ПРИМЕЧАНИЕ. Вещи, которые я цитирую здесь, DONT'S

1

foo       =  bar

foobar    =  bar

foobarbuz =  bar

2

foo = "foo"
bar = "bar"
foobar = foo + bar //string concat

3

foo = [1,2,3,4,5,6]
foo_ = []
for bar in foo:
  foo_.append(bar)

4

запись операторов импорта с именем проекта

from projectname.appname.models import model

5

Пытается использовать представление как обычные функции python

Обновление: слишком много логики в представлении, а что-то перемещает к помощнику (utils), я имею в виду, что здесь есть плохая практика для перенаправления. Есть люди, которые пишут вспомогательные функции в представлении.

6

Функция/метод без docstring и использование пространства имен никак не связаны с контекстом.