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

Question

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

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

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

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

или широко, например, с помощью "application ":

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

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

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

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

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