¿Cómo debo organizar mi árbol de fuentes?

El diseño del árbol de origen debe reflejar la arquitectura; como corolario, una arquitectura bien estructurada puede llevar a un diseño de árbol fuente bien estructurado. Le sugiero que lea el patrón de capas POSA1 , intente encajar su arquitectura en una estructura por capas y luego nombre cada una de las capas resultantes, y usar eso como base para su jerarquía de origen. Tomando como referencia una arquitectura de tres niveles :

• presentación / servicio web (presente una interfaz de servicio web a nuestra lógica de negocios)
• logic / * (los módulos de lógica de negocios entran aquí)
• storage / sql (API de almacenamiento de back-end aquí: esto utiliza una interfaz SQL para almacenar en una base de datos)
• util / * (código de utilidad: se puede usar en todas las demás capas, pero eso no hace referencia a util fuera, va aquí)

Tenga en cuenta que las capas no contienen código directamente, sino que se utilizan estrictamente para organizar los módulos.

Dentro de un módulo, uso el siguiente tipo de diseño:

• <module> (ruta al módulo directamente; define la interfaz modular)
• <module>/impl/<implName> (una implementación específica de la interfaz modular)
• <module>/doc (Documentación para usar el módulo)
• <module>/tb (código de prueba de unidad para el módulo)

donde el <module> está ubicado en el repositorio de acuerdo con la capa a la que pertenece.

Realmente no puedo darle muchos consejos relacionados con los proyectos web, pero aquí es cómo estructuro mi árbol en un proyecto de programación (principalmente desde la perspectiva C / C ++):

• /
  • src - Archivos de origen escritos por mí mismo
  • ext: contiene bibliotecas de terceros
    • libname-1.2.8
      • include - Headers
      • lib - Archivos lib compilados
      • Donwload.txt: contiene un enlace para descargar la versión utilizada
  • ide - Almaceno archivos de proyectos aquí
    • vc10 : organizo los archivos del proyecto según el IDE
  • bin : el archivo compilado va aquí
  • build - Los archivos de compilación del compilador
  • doc - Documentación de cualquier tipo
  • README
  • INSTALAR
  • COPIA

Algunas notas:

1. Si estoy escribiendo una biblioteca (y estoy usando C / C ++), primero organizaré mis archivos de origen en dos carpetas llamadas "include" y "src" y luego por módulo. Si es una aplicación, las organizaré solo por módulo (los encabezados y las fuentes irán en la misma carpeta).

2. Los archivos y directorios que enumeré anteriormente en cursiva no agregaré al repositorio de códigos.

Mientras que el Maven Standard Directory Layout es un tipo específico de para Java, pero también puede servir como una buena base para otros tipos de proyectos.

Aquí está la estructura básica (puede reemplazar los directorios 'java' con 'php', 'cpp', etc.):

src/main/java       Application/Library sources 
src/main/resources  Application/Library resources  
src/main/filters    Resource filter files 
src/main/assembly   Assembly descriptors 
src/main/config     Configuration files 
src/main/webapp     Web application sources 
src/test/java       Test sources 
src/test/resources  Test resources 
src/test/filters    Test resource filter files 
src/site            Site 
LICENSE.txt         Project's license 
NOTICE.txt          Notices and attributions required by libraries
README.txt          Project's readme

La estructura básicamente se divide en 'src / main' y 'src / test' y luego se agrupan por tipo.

Realmente no conozco las convenciones, pero todos mis proyectos principales se realizan con Symfony Framework y me he acostumbrado a una estructura de árbol como la siguiente:

raíz /

• aplicaciones
• nombre_aplicación
  • config (archivos de configuración específicos de la aplicación)
  • lib (archivos php específicos de la aplicación)
  • módulos (distribución modular de funcionalidad)
    • nombre_módulo
      • plantillas (html)
      • acciones (código php)
• confing (archivos de configuración del proyecto)
• lib (código php que podría usarse en el proyecto hole)
• modelo (clases que representan la información del proyecto)
  • base
• formulario (archivos php que manejan formularios, esto podría ser bastante difícil de lograr sin Symfony)
  • base (clases de formulario base)
• web
• css
  • imágenes
  • archivo.css
• js
• registro (archivos de registro que pueden generarse)
• datos (información específica de datos, como parches de sql, o lo que sea)
• sql
• complementos (bibliotecas utilizadas que podrían combinarse con cualquier aplicación del proyecto)

Si estás interesado, lee la documentación de Symfony al respecto para obtener más información ( MVC y organización de código en Symfony ).

Idealmente, la organización tiene un repositorio único, cuya estructura está destinada a aumentar el compromiso entre ingeniería y amp; Negocio y promoción reutilización.

...\products\
...\products\productName\
...\products\productName\doc\

...\systems\
...\systems\systemName\
...\systems\systemName\doc\
...\systems\systemName\res\
...\systems\systemName\build\
...\systems\systemName\test\

...\library\
...\library\libraryName\
...\library\libraryName\doc\
...\library\libraryName\build\
...\library\libraryName\test\

...\devops\

products

Una carpeta por producto; ayuda a comunicar cómo el software es compatible con el negocio.

Idealmente, cada "producto" es poco más que un archivo de configuración que indica qué sistemas invocar y cómo deben configurarse.    La subcarpeta doc podría contener el resumen de nivel superior \ spec & cualquier material promocional etc ...

Al separar los productos y los sistemas, comunicamos el potencial de reutilización al lado del negocio orientado al cliente y desglosamos los silos por producto.    (Esto contrasta con el enfoque de "línea de productos" para el mismo problema)

systems

Una carpeta por sistema; Ayuda a comunicar las capacidades primarias y amp; oportunidad / valor de los contenidos del repositorio.

1. Archivos de "administración de configuración" que especifican build & entornos de despliegue.
2. Configuración de prueba a nivel del sistema (podría ser una cantidad significativa).
3. Lógica de nivel superior & funcionalidad; el trabajo más pesado realizado por las funciones de la biblioteca.

library

Componentes reutilizables invocados por varios sistemas.    La mayoría de las actividades de desarrollo se organizan en torno a la producción de bibliotecas, en lugar de sistemas, por lo que la reutilización está "integrada" en el proceso de desarrollo.

devops

Compilación, integración continua & otra funcionalidad de automatización de desarrollo.

Conclusión

El árbol de origen es una pieza clave de documentación, y da forma al enfoque, estructura y psicología de la relación de la empresa con su tecnología patentada.

Los controladores de este enfoque se explican con mayor profundidad en mi respuesta a esta pregunta: enlace

Lo que estoy tratando de hacer para cada proyecto es similar a:

• src : archivos de origen, una carpeta para que cada espacio de nombre / paquete recupere fácilmente los archivos (incluso los archivos de encabezado de C / C ++)
• ext : para bibliotecas externas / de terceros, es sencillo agregar externos (como los repositorios SVN). En el interior, una carpeta para cada biblioteca (archivos binarios e incluir archivos)
• bin : para binarios construidos, se puede exportar rápidamente para su lanzamiento
  • inc : para el archivo de encabezados C / C ++ (copiado por IDE / makefile / etc ...)
• out : para todos los archivos generados temporalmente (.class, .obj etc ...) y podría ignorarse (por ejemplo, por SVN)
• doc : para cualquier documentación, generalmente generada con Doxygen
• res : al colocar los recursos aquí, es posible separar los archivos de origen de texto y los recursos binarios utilizados por el programa. Realmente no tengo una jerarquía específica dentro.
  • config - para algunos archivos de configuración
  • dibujable : para algunas imágenes o iconos

Todos los archivos IDE o archivos make se guardan directamente en la raíz si solo usas uno de ellos.

Hago algo como esto. Funciona bien para un juego multiplataforma que estoy haciendo en mi tiempo libre. Desafortunadamente en el trabajo, las cosas están mucho menos organizadas ...

Output                      <-- Build outputs
Docs
External
   <libname>
      Include
      Lib
Data
<ProjectName>.xcodeproj
<ProjectName>VS2010
Source
Temp                        <-- Intermediate stuff from builds and other tools
Tools

Para mis equipos, tratamos de imponer una estructura estándar en todos los proyectos para que sea fácil encontrar cosas a medida que el equipo cambia de contexto y para evitar tener que volver a aprender cada vez que lo hacen. No todos los proyectos necesitan todos los sistemas, así que comenzamos con el conjunto mínimo.

  

/ Fuente / Componente / Idioma

     

/ Fuente / Componente / Terceros /

     

/ Documentación / Requisitos

     

/ Documentación / Diseño

     

/ Tests / Automated / Unit

     

/ Tests / Automated / ToolName

     

/ Pruebas / Manual

Esto da como resultado cierta duplicación, en particular bajo el código y las bibliotecas de terceros, pero al menos nunca olvidamos la respuesta a algo como "¿Qué utiliza el Editor de RogueWave?"

Me gustan las ideas presentadas en esta página www.javapractices.com/topic/TopicAction.do?Id = 205 . Básicamente, la recomendación es organizar su proyecto en características (o módulos, componentes). Además de las razones presentadas allí:

1. Menos carga cognitiva cuando piensa en el alcance del código en el que está trabajando, ya que tiene una garantía de que cualquier código en la característica en la que está trabajando es "característica-privada".
2. Hay una sensación de seguridad añadida cuando se le garantiza que solo está modificando el código para una característica determinada. Por ejemplo, no romperás nada más que la característica en la que estás trabajando. Nuevamente, esto se debe a la "característica privada".
3. Menos carga cognitiva simple porque hay menos archivos que puedes ver para un paquete dado. Estoy seguro de que todos han visto un paquete que contiene más de 15 archivos.

Tenga en cuenta que esto se centra en los paquetes Java (también conocidos como espacios de nombres). Para grandes proyectos, recomiendo, por las mismas razones, dividir el proyecto en múltiples proyectos (como en múltiples proyectos de Maven) que representan una característica empresarial. Para proyectos más avanzados, recomiendo este reading .

Hasta ahora, los proyectos en los que estaba / estoy involucrado no siguen estos. Hay muchas razones, pero aquí hay algunas:

1. El malentendido del modificador de acceso predeterminado de Java (el más mal entendido modificador de acceso según este libro )
2. "Argumentum ad populum": cultura predominante de paquete por capa (probablemente causada por la razón # 1)

Creo que hay una oportunidad perdida para evitar la complejidad si la organización de origen del proyecto no se toma en serio al inicio del proyecto, como dijo el arquitecto Alexander:

  

"Como cualquier diseñador le dirá, son los primeros pasos en un diseño   Proceso que cuenta para la mayoría. Los primeros trazos, que crean el   Forma, lleva dentro de ellos el destino del resto. "- Christopher   Alexander

Dependiendo del tamaño y amp; La complejidad de un proyecto, la oportunidad perdida de reducir costos o el retorno de la inversión puede ser realmente grande. (Estoy interesado en ver un estudio para ver los números exactos para esto)

Mi recomendación es descargar una variedad de marcos o motores y ver cómo los enormes equipos de desarrollo manejaron el diseño de sus carpetas.

Hay tantas formas de organizar archivos que es mejor elegir uno e intentar mantenerlo en cualquier proyecto. Apégate a una convención en particular hasta completar o renovar para evitar errores y perder tiempo innecesario.

Puedes descargar los marcos de trabajo de Laravel, Symphony o Codeigniter para que los proyectos web tengan un diseño de carpetas instantáneo que funcione.

Así que intentaré transmitir un diseño de carpetas común a cualquier desarrollo:

MVC (Model View Controller) proporciona un buen paradigma de organización.

El código fuente de la raíz podría ser src (C ++) o aplicación (desarrollo web)

Una estructura de archivos que no tenga un objetivo claro para las clases que agrupa definitivamente causará confusión. No es solo para organizar el código, sino que también puede sustentar cargadores automáticos, clase de fábrica, almacenamiento local envolvente, almacenamiento remoto y espacios de nombres.

Esta estructura de carpetas se deriva y simplifica desde Laravel Framework . Mi preferencia en esta publicación es la denominación en plural, pero uso palabras singulares en mis proyectos.

src / storage (modelos / archivo-almacenamiento / api / mysql / sql-lite / memcached / redis implementaciones)

src / repositories (un contenedor de 'implementaciones de almacenamiento' con alguna lógica de almacenamiento, una interfaz común y una convención de resultados de retorno)

src / services | lógica | entidades (lógica de negocio de aplicaciones)

src / controllers (utilizado en el desarrollo web para enrutar las solicitudes del servidor a sus servicios)

src / modules | sistemas (Sistemas modulares que amplían la funcionalidad general de su marco. Los servicios pueden usar módulos pero no viceversa)

src / helpers (Clases de ayuda o envoltura como, por ejemplo, manipulación de cadenas. Muchas veces esto podría ser en libs | proveedor cuando sea un tercero)

src / types (enumeraciones nombradas)

público | construir | salida (web o c ++)

config (Archivos de configuración. YAML se está volviendo popular para los archivos de configuración multiplataforma)

cache

logs

lang (es / es / ru / ...)

bootstrap (inicia el marco y la aplicación)

documentos (Documentación escrita en formato markdown .md)

pruebas (pruebas unitarias)

base de datos / migraciones (crear una estructura de base de datos desde cero)

base de datos / semillas (llena tu base de datos con datos ficticios para probar)

libs | proveedor (todo el software de terceros. 'libs' en C ++ y 'proveedor' generalmente en php)

activos | recursos (imágenes / sonidos / scripts / json / cualquier medio)

Con los idiomas orientados a objetos, tiene la capacidad de crear espacios de nombres. Ese desglose lógico utilizado para separar partes de la aplicación para evitar el acoplamiento es la fuente principal del desglose de la ubicación del archivo lógico. Usar el acoplamiento como una razón para separar espacios de nombres es un buen lugar para iniciar enlace .

Otros han hablado de configurar el proyecto en relación con la compilación, pero una vez que entras en la fuente en sí, se trata de lo que tiene sentido: solo usa la forma en que lógicamente separas el código de todos modos.