árboles de códigos fuente: anchos o profundos

Question

Después de escribir algunas aplicaciones appengine de python, me encuentro dividido entre dos enfoques para organizar mi árbol de códigos fuente: ancho o profundo.

Para ser más concretos, considere una aplicación interna para una pequeña tienda de consultoría para administrar las operaciones comerciales, como la administración de contactos, el seguimiento de proyectos & informes y la administración de empleados. La aplicación podría usar entidades clave como: empresa, usuarios, contactos, clientes, proyectos, partes de horas, etc. Sin entrar en detalles, uno puede imaginar que estos modelos son transversales a través de las funciones del sitio web. Esto probablemente significa que hay un acoplamiento.

En este ejemplo, es preferible organizar en una manera profunda, por ejemplo:

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

o una amplia-manera, por ejemplo, por "aplicación":

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

sé todo diseño implica compensaciones, por lo que al responder puede indicar su preferencia y algún razonamiento (por ejemplo, suposiciones, preocupaciones de modulación, límites de estructura, problemas de escalabilidad, consideraciones de mantenimiento de código, impacto de la estructura del equipo de desarrollo, etc.).

Answer 1

Advertencia: No he trabajado específicamente en Python. Habiendo dicho eso ...

Ancho, y le diré por qué: nunca está de más ser capaz de eliminar cosas rápidamente. En mi carrera a menudo me piden que agregue cosas y me dan un cronograma relativamente razonable sobre el cual hacerlo, pero cuando algo necesita ser eliminado, la solicitud casi nunca viene con análisis de impacto o tiempo para perder el tiempo. Cuando se separan los módulos funcionales principales, generalmente se termina con un diseño mucho menos acoplado. Puede ser un verdadero dolor en el culo, pero para aquellos momentos en los que absolutamente tiene que desconectar el módulo de orden de trabajo para el final de la semana, es un salvavidas.

Answer 2

Una estructura de carpetas demasiado profunda la hace confusa. Demasiado ancho lo hace confuso. Prefiero mantener un equilibrio entre ellos. En el proyecto en el que estoy trabajando, no teníamos idea de lo que necesitaríamos, así que no creamos prematuramente una estructura de carpetas masiva. Después de todo, solo comenzamos con 5 archivos, por lo que realmente no teníamos una necesidad de para una estructura de carpetas. A medida que el proyecto se hizo más grande, organizamos cosas para mantenerlo ordenado a medida que avanzábamos; no hay carpetas que tengan más de 10 archivos, agrupando cosas en carpetas claramente. Tardaría unos minutos en moverlo por completo. Ahora tenemos más de cien archivos, y siempre está claro dónde están las cosas. Mi recomendación es hacer algo similar: mantenerlo ordenado, no ir demasiado lejos ni con la profundidad ni con el ancho, o las cosas se complicarán demasiado.

Answer 3

En su caso, creo que el modelo "ancho" es mejor. Debería intentar crear sus aplicaciones para que sean reutilizables incluso si no planea reutilizarlas en ningún lugar, ya que esto fomentará un acoplamiento más flexible entre diferentes aplicaciones y facilitará el mantenimiento a largo plazo.

Answer 4

En realidad, prefiero una mezcla. El software se divide en componentes horizontales y verticales.
Los componentes horizontales son reutilizables en todos los módulos y representan un código común para ser reutilizado que no es específico de la aplicación, sino que es específico de la arquitectura.
Tengo carpetas para utilidades comunes, marcos, bibliotecas de infraestructura reutilizables, como Persistencia, Comunicaciones, Seguridad, registro, etc. ...

Los componentes verticales son los Casos de uso individuales. Para cada caso de uso, tengo una carpeta que tiene UI, Servidor y bajo UI tengo vistas y controladores. El modelo a menudo se comparte entre los dos.

Si su proyecto es realmente grande, probablemente tenga diferentes áreas de responsabilidad, como control de inventario, ventas, administración de contactos, informes, etc. Agregue estos a su estructura de carpetas y coloque los casos de uso que se aplican debajo de ellos.

Siéntase libre si hay alguna reutilización para mover cualquier componente por el árbol.