Худшие практики в Джанго, которые вы когда-либо видели [закрыто]

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

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

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

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

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

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

, а не:

results = MyModel.query.all()

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

for result in MyModel.query.iterator():

Я в первую очередь ошибаюсь, начав писать код на Python без чтения PEP. Худшее, что я хотел бы процитировать:

ПРИМЕЧАНИЕ. Здесь я цитирую

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

Попытка использовать представление как обычный питон functions

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

6

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

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

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

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

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

Слишком много логики во взглядах.

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

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

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

1. Обезьяна с предварительно сохраненным и после сохранения событий.

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

2. Пытаться написать Uber-Generic - один вид делает все это - функциональность. Просмотр функций являются функциями по причине. Они могут использовать модули, пакеты, объекты, другие функции и т. Д. Они могут быть короткими и похожими без него, не являясь запахом кода.

   Если вам нужно использовать 10 строк кода для построения объекта Uber-Generic-do-все, и это было бы функцией просмотра 12 линейки без объекта Uber-Generic-Do-Al-All, затем Убер-объект не помогает.

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

4. Неспособность использовать Tests.cy и тестовый клиент для создания полных тестов единиц того, что он утверждает, что приложение делает.

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

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

Я думаю, что не существует конкретного случая, достаточно конкретного, чтобы вызвать эти проблемы. Я рекомендую оставить id вашей модели таким, какой он есть по умолчанию.

Подробнее см. Как лучше всего изменить первичные ключи в существующем приложении Django?

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

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