Исходный код деревья: широкие или глубокие

Question

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

Для конкретной задачи рассмотрите внутреннее приложение для небольшого консультационного магазина для управления бизнес-операциями, такими как управление контактами, отслеживание проектов & отчетности и управление сотрудниками. Приложение может использовать ключевые объекты, такие как: компания, пользователи, контакты, клиенты, проекты, расписания и т. Д. Не вдаваясь в подробности, можно представить, что эти модели являются сквозными функциями веб-сайта. Вероятно, это означает, что существует некоторая связь.

В этом примере, является предпочтительным, чтобы организовать в глубокой форме, например:

models/ 
    people.py 
    accounting.py 
    projects.py 
    foo.py 
controllers/ 
    reporting.py 
    employeeops.py 
    accounting.py 
    crm.py 
views/ 
    ... 

или широким образом, например, путем «применения»:

people/ 
    models/ 
    views/ 
    controllers/ 
contact-mgmt/ 
    models/ 
    views/ 
    controllers/ 
time-tracking/ 
    models/ 
    views/ 
    controllers/ 
project-reporting/ 
    models/ 
    views/ 
    controllers/ 

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

Answer 1

Предостережение: Я не работал в python специально. Сказав это ...

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

Answer 2

Слишком глубокая структура папок делает ее запутанной. Слишком широкий, это путает. Я предпочитаю сохранять равновесие между ними. В проекте, над которым я работаю, мы понятия не имели, что нам нужно, поэтому мы преждевременно не создали массивную структуру папок. В конце концов, мы только начали с 5 файлов, поэтому у нас действительно не было для структуры папок. По мере того, как проект становился все больше, мы организовывали вещи, чтобы поддерживать его в чистоте, когда мы шли; нет папок с более чем 10 файлами, четко группируя вещи в папки. Потребуется несколько минут, чтобы переместить все вокруг. Теперь у нас есть более ста файлов, и всегда ясно, где это происходит. Моя рекомендация - делать что-то похожее - держите его аккуратным, не заходите слишком далеко ни по глубине, ни по ширине, иначе вы будете слишком усложнять ситуацию.

Answer 3

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

Answer 4

На самом деле я предпочитаю микс. Программное обеспечение разделено на горизонтальные и вертикальные компоненты.
Горизонтальные компоненты многократно используются во всех модулях и представляют собой обычный код, который будет использоваться повторно, а не специфичен для конкретного приложения, а является специфичным для архитектуры.
Итак, у меня есть папки для общих утилит, рамок, многократных библиотек инфраструктуры, таких как стойкость, связь, безопасность, протоколирование и т. Д.

Вертикальные компоненты - это индивидуальные случаи использования. Для каждого варианта использования у меня есть папка с UI, сервером и под UI. У меня есть виды и контроллеры. Модель часто разделяется между ними.

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

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