Python-сообщество

Товарищи, посоветуйте гайдлайн по структуре проекта. Лучше несколько.
А то есть в уме куча кода, который ни во views не запихнешь, ни в functions какой-нибудь. В общем, нужны идеи.

LOMS
Если вы сами не знаете, что куда пихать, кто ж вам тут поможет?
Расскажите хотя-бы, что у вас за проект, что за модули, как они в пакеты собраны.
А без этого, вся структура стандартного джанго-проекта создается командой django-admin startproject и непонятно, что же вам непонятно.

LOMS
Товарищи, посоветуйте гайдлайн по структуре проекта. Лучше несколько. А то есть в уме куча кода, который ни во views не запихнешь, ни в functions какой-нибудь. В общем, нужны идеи.

Старайтесь “кучу кода” реализовывать в методах моделей. ИМХО конечно.

vak
Старайтесь “кучу кода” реализовывать в методах моделей.

Это, видимо, чтобы напрочь исключить повторное использование кода? Или для того, чтобы сделать проект как можно менее переносимым? Не понимаю, объясните, зачем бизнес-логику пихать в модели? Если у вас получается много кода для обработки данных, то ИМХО надо подумать над введение еще одного слоя, возможно отделить доступ к данным от модели домена. Вообще, когда кода становится много и разработчик начинает путаться в структуре проекта, нужно заняться рефакторингом, выделить общий код в отдельные библиотеки, подумать над иерархией классов - выделить АБК, продумать интерфейсы. Нужно заниматься проектированием архитектуры вашего приложения, провести декомпозицию кода, перетрясти дерево наследования, уменьшить связность компонентов, а не пихать все что не попадя в модели.

FishHook
Если вы сами не знаете, что куда пихать, кто ж вам тут поможет?

Кто-кто, да какой-нибудь “best practice”, который(е) я не могу нагуглить самостоятельно. Структура проекта мало роляет, я прошу лишь помощи в поиске статей о структурировании кода в самом обычом django проекте. Наверняка Вы что-то читали или, быть может, даже писали по этому поводу. Вот и мне хотелось бы почитать. По результатам чтения я подхвачу пару годных идей и побегу их применять. Ну или подумаю “вот говно” и пойду гуглить | изобретать свой велосипед.

Ваш опыт тоже ценен. Какой структуры лично Вы придерживаетесь?

LOMS
У вас есть проект, который вы создали с помощью startproject или визардом IDE. В этот проект вы добавляете приложения командой startapp. Обе эти команды создают каталоги с некоторой структурой. У меня получилось вот так

Если у вас получается много вспомогательного кода, то вы выделяете этот код в отдельные модули или пакеты, получаете что-то типа такого

такая структура получилась, потому что нам так удобно, как это будет в случае вашего проекта никакие best practice вас не научат. Это вопрос удобства и рациональной организации вашего рабочего места.
У вас есть компьютер, в нем есть жесткий диск, операционная система по умолчанию вам предлагает некую организацию домашнего каталога: Users/LOMS/Downloads, Users/LOMS/Documents. Но вы наверняка этим не ограничиваетесь, и свою коллекцию фильмов, музыки и фотографий как-то каталогизируете только по вам известным критериям.

FishHook
такая структура получилась, потому что нам так удобно, как это будет в случае вашего проекта никакие best practice вас не научат. Это вопрос удобства и рациональной организации вашего рабочего места.

Не согласен. Постараюсь объяснить.
Утвержение, что никакая структура проекта не может быть идеальной или удобной для всех и что это личное дело каждого разработчика или команды - заведомо верно.
Но любое подобное чтиво может навести на правильные мысли. В одном случае автор описывает, как делать нельзя и с ним можно согласиться в той или иной мере.
В другом случае, автор опишет как он сделал сам и его опыт может быть полезен. Многие элементарные вещи бывает не так просто вывести. Взять тот же трюк с пространством имён в templates, прочитанный очень давно и позднее вошедший в оффициальную документацию, о том, что во многих случаях разумно делать project/app_name/templates/app_name/, не прочтя об этом в какой-то статье давным давно я ещё не скоро пришёл бы к такому самостоятельно, хотя сейчас это кажется очень банальным.
Также чужой положительный или отрицательный опыт может явиться катализатором для новых идей. Подобные статьи никогда не были инструкцией, которой НЕОБХОДИМО следовать, чай не обряды творим.

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

P.S.: кстати, даже скрин структуры проекта мне уже подарил пару идей.

Отредактировано LOMS (Дек. 24, 2016 15:27:16)