Что такое хороший рабочий процесс Django?

Question

Я новичок в Python и Django.

Когда вы начинаете новый проект, что вы делаете прежде, чем погрузиться в код?

Например, можно сделать следующие шаги:

1. Сконфигурировать настройкиСначала файл .py
2. Настройка файла models.py для структуры данных
3. Создание файлов шаблонов
4. Определение представлений / страниц
5. Syncdb
6. и т. Д.

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

Спасибо.

Answer 1

Следуйте гибкому подходу.Завершите один маленький кейс от начала до конца .От моделей до тестов и опыта пользователей.Тогда основывайтесь на этом.Итерация.

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

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

Автоматическая миграция схемы, автоматизированная система сборки, автоматическое обновление и развертывание.Джанго не имеет к этому никакого отношения.Используйте pip , ткань , hudson , саржа и юг соответственно.

Будьте осторожныне обременять себя всем этим сразу, тем более что вы говорите, что начинаете.

Answer 2

необходимые шаги для приложения Django?

Есть два необходимых шага.

Запишите настройки.Напишите urls.py

Остальные шаги необязательны.

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

Плохая политика.Вам не нужен контрольный список функций Django.Вам нужна коллекция сценариев использования или пользовательских историй, которые вы должны реализовать.

По какой-то причине вы пропустили две наиболее важные и ценные особенности Django.Настройте интерфейс администратора по умолчанию и напишите модульные тесты.По умолчанию интерфейс администратора имеет очень высокое значение.Модульное тестирование является абсолютно центральным.

Вы делаете это следующим образом.

1. Соберите варианты использования.

2. Приоритетность вариантов использования.

3. Определите актеров.Классы акторов становятся группами в модели безопасности.

4. Определите достаточно «приложений», чтобы удовлетворить первый выпуск вариантов использования.Определите структуру URL.Классные URL не меняются.

5. Создайте первый вариант использования: модели (включая безопасность), администратор, URL, тесты, формы, представления и шаблоны.Обратите внимание, что это имена файлов (models.py, admin.py, ...) за исключением шаблонов.Также обратите внимание, что формы и администратор должны быть определены в отдельных модулях, даже если это не требуется.Также обратите внимание, что шаблоны будут разделены между общим каталогом шаблонов для материалов верхнего уровня и шаблонами приложений.

6. Создание второго варианта использования: модели (включая безопасность), администратор, URL-адреса, тесты, формы, представления и шаблоны.

...

n.Пакет для выпуска.Настройте параметры.Настроить базу данных и мод-wsgi

Answer 3

Лично я не могу сделать шаблон без написания представлений (если это не черновик фотошопа), но в целом я так и поступаю после того, как у меня есть план .

Что чрезвычайнодля меня важно , чтобы я не погружался головой в код и тратил время на макетирование структуры модели на основе "экранов" или "страниц", которые увидит пользователь.

После того, как я определил пользовательский интерфейс, я убедился, что бэкэнд достаточно устойчив, чтобы справиться с этим опытом.Если я не визуализирую пользовательский опыт, упускаются детали, которые, безусловно, выполнимы в оболочке, но не идеальны для веб-сайта, администратора django по умолчанию и т. Д.

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

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

Образованное предположение - хорошее начало.Не думайте и не предполагайте слишком много, но определенно имейте четкое представление о том, как ваши пользователи будут взаимодействовать с вашим сайтом на этапе 1.

Answer 4

здесь я делаю что-то общее,

• настройка основных параметров
• настройка root url.py
• настройка параметров, url.py для статического (медиа) файлы
• создание модели
• sync db
• запись представлений (при необходимости используйте простой шаблон)

после завершения работы с серверной частьюреализация

• думать о пользовательском интерфейсе
• подготовить стили, сценарии
• начать работу над реализацией шаблона

Answer 5

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

Например, я часто занимаюсь разработкой непосредственно на сервере развертывания (большая часть моей работы направлена ​​на проекты в интрасети, поэтому нет угрозы безопасности и т. Д.). Но когда я делаю это, мне действительно нужно убедиться, что настройки и URL-адреса настроены в первую очередь и что настроены gunicorn и nginx.

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

Обычно я делаю настройки, модели, syncdb, представления, URL-адреса, шаблоны, collectstatic, графику / эстетику

В общем, я оставляю свой base.html очень простым, пока все остальное не работает, затем я добавляю css / js и т. Д.

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

Удачи, надеюсь, ты научишься любить Джанго!

Answer 6

Всегда старайтесь помнить о сухом правиле. Например, зачем писать RequestContext каждый новый вид определяется, где вы можете просто написать функцию один раз, которая добавит ее для вас. Хорошее описание здесь другая тема .

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

Как правило, хорошее правило, и как я пишу свои приложения, это правило маленьких шагов. Начните с написания настроек и URL, затем добавьте одну модель и один вид. Когда это работает, измените - добавьте другие модели или другие виды. Вы даже не заметите, когда ваш проект станет больше и больше.

И последнее полезное правило для наглядности всего источника. Храните файлы в папках. Если у вас есть два дочерних сайта на основе одного (например, «учетные записи» и «блоги»), создайте два одинаковых имени каталогов. Не забудьте поместить файл init .py в каждый каталог. Это действительно легко забыть. С этой практикой легко написать модели и представления, посвященные каждой категории. Кстати, хорошая практика - хранить URL как в древовидной структуре. Основной urls.py должен содержать только ссылки, подобные этой:

(r'^accounts/', include('your_main_name.accounts.urls')),

и, конечно, все медиа, статические, CSS и так далее. В справочнике учетных записей хранятся:

urlpatterns = patterns('your_main_name.accounts.views',
    url(r'^$', 'index', name='index'),
)

со всеми подкаталогами представлений.

Последнее - сохраняйте код чистым с помощью версии actall django. Помните, что скоро выйдет 3.0.

Надеюсь, это поможет.