language-agnostic directory-structure project-structure

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



language-agnostic directory-structure (9)

Guardo todo en un directorio "c: / projects" en mi máquina de Windows y ~ / projects en nuestros entornos unix-oid (linux y 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.

He estado experimentando con estructuras de directorios y actualmente estoy usando el siguiente:

| |_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

Las tiendas web almacenan aplicaciones web y aplicaciones de escritorio de la tienda de escritorio. 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 su estructura de directorio de desarrollo de software y hay alguna razón por la que recomiende esa estructura?

Solo uso un nombre abreviado para cada proyecto y lanzo todos los archivos y directorios relevantes a ese único directorio. Algo como esto:

  • project_name (Nombre del proyecto, "shorthanded")
    • dir1 / (No nombrado así en realidad.)
    • dir2 /
    • dirN /
    • archivo1
    • archivo2
    • archivo3
    • fileN

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 su 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 de mi oficina sigue sus métodos y parece apoyar un entorno de desarrollo más amplio. 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.

Solo mis dos centavos.

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.

Yo hago lo siguiente:

  • Proyectos
    • Proyecto 1
      • Diseño
      • Documentos
      • Código
    • Proyecto n
      • Diseño
      • Documentos
      • Código
    • No activo
      • Proyecto 1
        • Diseño
        • Documentos
        • Código
      • Proyecto n
        • Diseño
        • Documentos
        • Código

Por alguna razó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.

  • src / <- Códigos fuente para múltiples proyectos (abajo)

  • pruebas /

    • test_a <- prueba de módulo para a para I + D (utiliza algunos códigos de la carpeta src)

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

    • ...

  • main_app_folder <- Archivo de proyecto principal para producción (usa la mayoría de los códigos de la carpeta src)

  • doc / <- Documentos

  • herramientas/

    • tool_a <- tool a (usa algunos códigos de la carpeta src)

    • tool_b <- tool b (usa algunos códigos de la carpeta src)

  • Utilidad cleanup.exe / .ini <- para limpiar archivos de compilación temporales.

Project (en main_app_folder, tests o tools) puede ser .vcproj (visual studio c / c ++), .mmp (Symbian makefile), Makefile (linux makefile). 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 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 la funcionalidad completa, 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.

Usualmente uso esta estructura de directorio:

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

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 compartidos // intra-pc / Releases /

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 ...

Tiendo a agrupar todos mis proyectos en tres directorios principales:

  • Diseño web => Para cualquier cosa relacionada con la web;
  • 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 dentro de estas carpetas tengo:

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

Además, cada proyecto se mantiene en un repositorio git, con un archivo doap que lo describe (junto con lo habitual, como README, INSTALL, NEWS, AUTHORS, LICENCE (normalmente apache2), un directorio de documentos y un directorio srcs y, opcionalmente, un directorio de libs y un archivo de compilación). Si hay proyectos conectados, entonces 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 base del software apache para organizar mis proyectos, así que tengo los laboratorios (o investigación), el ático, la incubadora, los archivos dopa, etc. Porque En estos días, soy mayormente un hombre de java, y Apache vino a mi mente ...