Quelle est la structure de votre répertoire de développement logiciel?

Question

J'expérimentent des structures d'annuaire et suis actuellement en utilisant celui-ci:

 
| 
|_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 applications web magasin, magasin de postes de travail des applications de bureau. Le répertoire dev est contrôlé par la version, tandis que les autres répertoires (prod, qe, uat) stockent leurs versions actuelles respectives. Le répertoire du projet stocke les éléments de projet non liés au code.

Quelle est la structure de votre répertoire de développement logiciel et y a-t-il une raison pour laquelle vous recommandez cette structure?

Answer 1

Je suis un grand fan de vos feuilles plus granulaires, mais au niveau supérieur, je fais beaucoup mieux d'avoir le système de fichiers organisé par projet. Je suis beaucoup plus susceptible d'être dans un répertoire de code et de penser, "Hey, quelle était la spécification pour cela?" que d'être dans le répertoire spec et de penser, "Pour quel projet ai-je besoin de la spécification?" Pour réorganiser votre diagramme:

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

Cela dit, l'organisation à mon bureau suit vos méthodes, et semble soutenir un environnement de développement largish. Personnellement, je trouve vraiment frustrant d'avoir à chercher des maquettes et d'autres cas dans d'autres répertoires que mon projet (en particulier, en tant qu'analyste, avoir des spécifications séparées des modèles marketing, mais je m'écarte), mais d'un processus ... Le point de vue de la délégation qui sépare ces concepts a probablement beaucoup de sens.

Juste mes deux cents.

Answer 2

Je stocke tout dans un répertoire "c: \ projects" sur ma machine Windows et ~/projets sur nos environnements unix-oid (linux & solaris). En dessous, j'ai un "apprentissage" (pour les expériences de code et des extraits/répertoire) et ensuite un répertoire pour chaque projet. Après un certain temps, lorsqu'un projet est terminé, j'efface le stockage local et le code est archivé uniquement dans SVN.

Answer 3

Je fais ce qui suit:

• Projets
  • Projet 1
    • Conception
    • Docs
    • code
  • Projet n
    • design
    • Docs
    • code
  • Inactive
    • Projet 1
      • Conception
      • Docs
      • code
    • Projet n
      • design
      • Docs
      • code

Pour certains r eason ça m'aide beaucoup à garder tous les fichiers groupés par projet, et à garder mes projets inactifs (ceux sur lesquels je ne travaille pas actuellement) dans un dossier plus bas. Je suppose que je suis distrait par eux autrement.

Answer 4

J'ai tendance à préférer une structure de répertoire plus plate et je vous recommande de la garder aussi simple que possible. Rappelez-vous que, au moins dans Windowsland, la longueur de la ligne de commande est limitée. Ainsi, avoir des structures très profondes peut engendrer des erreurs de construction désagréables.

Answer 5

Je viens d'utiliser un nom en désavantage pour chaque projet et de lancer tous les fichiers et répertoires pertinents dans ce répertoire. Quelque chose comme ceci:

• project_name (Nom du projet, "en désavantage numérique")
  • dir1/(non nommé comme celui-ci dans la réalité.)
  • dir2/
  • Dirn/
  • fichier1
  • fichier2
  • file3
  • fileN

Answer 6

fichiers dans svn:

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

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

SomeApplicationZ 
.. 

fichiers dans certains partagés \\ \ intra-pc de presse \

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 \ < - Les codes sources pour plusieurs projets (ci-dessous)

• essais \

  • test_a < - test de module pour a pour r & d (utilise certains des codes du dossier src)

  • test_b < - test de module b pour r & d (utilise certains des codes de dossier src)

  • ...

• main_app_folder < - fichier de projet principal pour la production (utilise la plupart des codes du dossier src)

• doc \ Documents < -

• tools \

  • tool_a < - outil un (utilise certains des codes de dossier src)

  • tool_b < - outil b (utilise certains des codes de dossier src)

• nettoyage. exe/.ini < - utilitaire pour nettoyer les fichiers de construction temporaires.

projet (en main_app_folder, des tests ou des outils) peuvent être .vcproj (visual studio c/C++), .mmp (Symbian makefile), Makefile (Makefile de linux). Chaque projet a son propre fichier .cpp principal - contenant toujours un ensemble minimal de fonctionnalités, tout le reste a tendance à être plus ou moins réutilisable (dans src \ folder).

La différence entre l'application de test et l'application de l'outil est que cet outil affiche quelque chose de plus ou de moins utile, tandis que le test vérifie seulement si cela fonctionne ou non. La différence entre le test et l'application principale est que l'application de test ne contient pas toute la fonctionnalité, aussi l'application de test peut activer certains # define nécessaires pour le test. Normalement, l'application de test est un ensemble réduit d'application principale sans #define supplémentaire.

Answer 8

J'utilise habituellement cette structure de répertoire:

• nom_proj
  • Code
    • src
    • Test
    • build
  • conception
  • doc
  • outils

Answer 9

J'ai tendance à regrouper tous mes projets dans trois répertoires principaux:

• = Webdesign> Pour tout web lié;
• Programmation => Pour tout ce qui n'est pas lié au Web (même s'il possède des capacités réseau);
• Recherche => Pour quoi que ce soit où je dois lire des articles pour le faire;

Puis dans ces dossiers que j'ai:

• incubateur => Pour les nouveaux projets ou des projets que j'adoptez;
• Retraite (ou atic) => Pour les projets qui sont inactifs;
• n répertoires pour chacun de mes projets de développement actif;

De plus, chaque projet est maintenu dans un dépôt git, avec un fichier doap décrivant (ainsi que les trucs habituels, comme README, INSTALL, NEWS, AUTEURS, LICENCE (généralement apache2), un dir docs, et SRCs dir et éventuellement un répertoire libs et un fichier de construction). Si des projets sont connectés, le fichier doap en dit quelque chose (ou je crée simplement un dossier pour le projet racine et y place tous les projets associés). La seule exception à ces deux paragraphes ci-dessus, sont quelques projets dans l'atic (certains d'entre eux puis écrits en Delphi 2 ...).

De plus, seules les sources sont stockées, car je peux rapidement en créer des binaires. PS: Si cela vous rappelle quelque chose que vous connaissez, c'est parce que je me suis inspiré de la fondation apache software pour organiser mes projets, j'ai donc les labs (ou la recherche), l'atic, l'incubateur, les fichiers doap , etc Parce que je suis surtout un homme java ces jours-ci, et apache est venu à l'esprit ...