Подтвердить что ты не робот

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

Я начинаю Python и Django.

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

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

  • Сначала настройте файл settings.py
  • Настроить models.py для компоновки структуры данных
  • Создание файлов шаблонов
  • Определить виды/страницы
  • SyncDB
  • и т.д.

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

Спасибо.

4b9b3361

Ответ 1

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

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

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

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

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

Ответ 2

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

Есть два требуемых шага.

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

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

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

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

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

Вы делаете это так.

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

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

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

  • Определите достаточно "приложений", чтобы удовлетворить первый выпуск вариантов использования. Определите структуру URL. Прохладный URL-адрес не изменяется.

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

  • Создайте второй вариант использования: модели (включая безопасность), admin, urls, тесты, формы, представления и шаблоны.

...

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

Ответ 3

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

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

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

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

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

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

Ответ 4

Всегда старайтесь помнить о правиле DRY. Например, зачем писать 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'),
)

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

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

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

Ответ 5

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

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

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

В общем, я делаю настройки, модели, syncdb, views, urls, templates, collectstatic, graphics/aesthetics

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

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

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

Ответ 6

вот что я делаю вообще,

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

как только вы закончите реализацию с завершающим концом

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