¿Cuál es su estructura de directorio de desarrollo de software?

Question

que han estado experimentando con estructuras de directorios y actualmente estoy usando la siguiente: aplicaciones

 
| 
|_projects__ 
|   | 
|   |_blog.com_ 
|   |   |_mockups 
|   |   |_user stories 
|   |   |_.... 
|   | 
|   |_noteapp__ 
|      |_mockups 
|      |_.... 
| 
|_webs______ 
|   | 
|   |_dev______ 
|   |   |_blog.com_ 
|   |      |_app 
|   |      |_config 
|   |      |_.... 
|   | 
|   |_prod_____ 
|   |   |_blog.com_ 
|   |      |_app 
|   |      |_.... 
|   |_qe_.... 
|   |_uat_.... 
| 
| 
|_desktops__ 
      | 
      |_dev______ 
      |   |_noteapp_ 
      |     |_app 
      |     |_config 
      |     |_.... 
      | 
      |_prod... 
      |_qe.... 
      |_uat.... 

               KEY 
               dev - development 
               prod - production 
               qe - quality engineering 
               uat - user acceptance testing 

Webs tienda web, tienda de aplicaciones de escritorio escritorios. El directorio dev está controlado por la versión, mientras que los otros directorios (prod, qe, uat) almacenan sus versiones actuales respectivas. El directorio del proyecto almacena elementos de proyecto no relacionados con el código.

¿Cuál es la estructura del directorio de desarrollo de software y existe alguna razón por la que recomiende esa estructura?

Answer 1

Soy un gran admirador de sus hojas más granulares, pero en el nivel superior me desempeño mucho mejor teniendo el sistema de archivos organizado por proyecto. Tengo muchas más probabilidades de estar en un directorio de código y pensar: "Oye, ¿cuál era la especificación para esto?" que estar en el directorio de especificaciones y pensar: "¿Para qué proyecto quería la especificación?" Para reorganizar el diagrama:

| 
|___webs____ 
|   | 
|   |_blog.com_ 
|   |   | 
|   |   |_docs_ 
|   |   |  | 
|   |   |  |_mockups 
|   |   |  |_user stories 
|   |   |  |_... 
|   |   | 
|   |   |_code_ 
|   |   |  | 
|   |   |  |_dev_ 
|   |   |  |  | 
|   |   |  |  |_app 
|   |   |  |  |_cfg 
|   |   |  |  |_... 
|   |   |  | 
|   |   |  |_prod_ 
|   |   |  |_qa_ 
|   |   |  |_uat_ 
|   | 
|   |_blah.com_ 
|   |   | 
|   |   |_... 
| 
|_desktop___ 
|   | 
|   |_noteapp__ 
|   |   | 
|   |   |_... 
|   |_... 


               KEY 
               dev - development 
               prod - production 
               qe - quality engineering 
               uat - user acceptance testing 

Dicho esto, la organización en mi oficina sigue sus métodos, y parece apoyar un entorno de desarrollo más bien grande. Personalmente, encuentro realmente frustrante tener que buscar maquetas y otros casos en directorios distintos a aquel en el que está mi proyecto (específicamente, como analista, que tiene especificaciones separadas de los modelos de Marketing, pero estoy divagando), pero a partir de un proceso- El punto de vista de la delegación que separa estos conceptos probablemente tiene mucho sentido.

Sólo mis dos centavos.

Answer 2

Guardo todo en un directorio "c: \ projects" en mi máquina de Windows y ~/projects en nuestros entornos unix-oid (linux & solaris). Debajo tengo un "aprendizaje" (para experimentos de código y directorio de fragmentos /) y luego un directorio para cada proyecto. Después de un tiempo, cuando un proyecto se ha extinguido, borro el almacenamiento local y el código se archiva solo en SVN.

Answer 3

hago lo siguiente:

• Proyectos
  • Proyecto 1
    • Diseño
    • Docs
    • Código
  • Proyecto n
    • Diseño
    • Docs
    • Código
  • no está activo
    • Proyecto 1
      • Diseño
      • Docs
      • Código
    • Proyecto n
      • Diseño
      • Docs
      • Código

para algunos R También me ayuda mucho mantener todos los archivos agrupados por proyecto, y mantener mis proyectos inactivos (aquellos en los que no estoy trabajando actualmente) en una carpeta más abajo. Supongo que me distraigo con ellos de lo contrario.

Answer 4

Tiendo a preferir una estructura de directorios más plana y me gustaría recomendar que sea lo más simple posible. Recuerde que, al menos en Windowsland, hay un límite en la longitud de la línea de comandos. Por lo tanto, tener estructuras muy profundas podría generar algunos errores de construcción desagradables.

Answer 5

Acabo de utilizar un nombre abreviado para cada proyecto y arrojo todos los archivos y directorios relevantes en ese único directorio. Algo como esto:

• project_name (Nombre del proyecto, "shorthanded")
  • dir1/(No se nombró así en realidad.)
  • directorio2/
  • dirn/
  • archivo1 archivo2
  • archivo3
  • archivoN

Answer 6

archivos en SVN:

SomeLibraryX 
    SomeLibraryX.sln 
    SomeFunctionA.cs 
    SomeFunctionB.cs 
    .. 

SomeApplicationY 
    SomeApplicationY.sln 
    SomeApplicationY.cs   <-- might use SomeLibraryX as one of the dependencies 

SomeApplicationZ 
.. 

archivos en algunos intra-pc \ lanzamientos compartidos \\ \

SomeApplicationY 1   <-- folder used to execute compiled binary. Contains all the necessary input files needed for execution. 
    Model     <-- all input files like xml:s and 3ds:s 
    Textures     <-- all pictures 
    Depencies    <-- all dependency executables and dlls 
    SomeApplicationY.exe  <-- main exe 
    SomeApplicationY.ini  <-- execution parameters file, that can be drag&dropped onto main exe 

SomeApplicationY 2 
    Model 
    Textures 
    Depencies 
    SomeApplicationY.exe 
    SomeApplicationY.ini 

SomeApplicationY 3   <-- the last demo-release of this project that is currently under construction (used for executing and debugging the exe) 

    Model 
    Textures 
    Depencies 
    SomeApplicationY.exe 
    SomeApplicationY.ini 

SomeApplicationZ 1 
... 

Answer 7

• src \ < - Los códigos de fuente para varios proyectos (continuación)

• pruebas \

  • test_a < - prueba de módulo para a para r & d (utiliza algunos códigos de la carpeta src)

  • test_b < - prueba de módulo para b para r & d (utiliza algunos de los códigos de la carpeta src)

  • ...

• main_app_folder < - archivo de proyecto principal para la producción (utiliza la mayor parte de los códigos de la carpeta src)

• doc \ < - Documentos

• herramientas \

  • tool_a < - herramienta de un (utiliza algunos de los códigos de la carpeta src)

  • tool_b < - herramienta de b (utiliza algunos de los códigos de la carpeta src)

• limpieza. exe/.ini < - utilidad para limpiar archivos de construcción temporales.

Proyecto (en main_app_folder, pruebas o herramientas) se pueden .vcproj (Visual Studio C/C++), .mmp (Symbian makefile), Makefile (Makefile Linux). Cada proyecto tiene su propio archivo .cpp principal, que siempre contiene un conjunto mínimo de funcionalidades, todo lo demás tiende a ser más o menos reutilizable (en src \ folder).

La diferencia entre la aplicación de prueba y la aplicación de la herramienta es que la herramienta muestra algo más o menos útil, mientras que la prueba solo verifica si funciona o no.

La diferencia entre la prueba y la aplicación principal es que la aplicación de prueba no contiene toda la funcionalidad, también la aplicación de prueba podría habilitar algunas # definiciones especiales necesarias para la prueba. Normalmente, la aplicación de prueba reduce el conjunto de la aplicación principal sin #define adicional.

Answer 8

normalmente utilizo esta estructura de directorios:

• proj_name
  • código
    • src
    • prueba
    • acumulación
  • diseño
  • doc
  • herramientas

Answer 9

tiendo a agrupar todos mis proyectos en tres directorios principales:

• Diseño Web => para la web todo lo relacionado;
• Programación => Para cualquier cosa que no esté relacionada con la web (incluso si tiene capacidades de red);
• Investigación => Para cualquier cosa donde tenga que leer documentos para poder hacerlo;

Entonces en esas carpetas que tienen:

• Incubadora => Para los nuevos proyectos o para proyectos que adoptar;
• Retiro (o ático) => Para proyectos que están inactivos;
• n directorios para cada uno de mis proyectos activamente desarrollados;

también cada proyecto se mantiene en un repositorio git, con un archivo doap describiéndola (junto con el material habitual, como README, INSTALAR, noticias, autores, LICENCIA (por lo general apache2), un dir docs, y la Sociedad Nacional dir y opcionalmente un libs dir y un archivo de compilación). Si hay proyectos conectados, el archivo doap dice algo al respecto (o simplemente creo una carpeta para el proyecto raíz y coloco todos los proyectos relacionados en ella). La única excepción a estos dos párrafos anteriores, son algunos proyectos en el ático (algunos de los escritos en Delphi 2 ...).

Además, solo se almacenan las fuentes, ya que puedo crear binarios rápidamente de ellas.

PD: Si esto te recuerda algo que sabes, es porque me he inspirado en la fundación de software apache para organizar mis proyectos, así que tengo los laboratorios (o investigación), el ático, la incubadora, los archivos dopa , etc. Porque soy mayormente un hombre de java en estos días, y Apache vino a mi mente ...