Wie ist die Struktur Ihres Softwareentwicklungsverzeichnisses?

Question

Ich habe mit verschiedenen Verzeichnisstrukturen experimentiert und verwende derzeit die folgende:

 |
 |\_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 speichern Webanwendungen, Desktops speichern Desktopanwendungen. Das Verzeichnis dev ist versionskontrolliert, während die anderen Verzeichnisse (prod, qe, uat) die jeweils aktuellen Versionen speichern. Das Projektverzeichnis speichert nicht-codebezogene Projektelemente.

Wie sieht Ihre Verzeichnisstruktur für die Softwareentwicklung aus und gibt es einen Grund, warum Sie diese Struktur empfehlen?

Answer 1

Ich tue Folgendes:

• Projekte
  • Projekt 1
    • Gestaltung
    • Dokumente
    • Code
  • Projekt n
    • Gestaltung
    • Dokumente
    • Code
  • Nicht aktiv
    • Projekt 1
      • Gestaltung
      • Dokumente
      • Code
    • Projekt n
      • Gestaltung
      • Dokumente
      • Code

Aus irgendeinem Grund hilft es mir sehr, alle Dateien nach Projekten gruppiert aufzubewahren und meine inaktiven Projekte (die, an denen ich gerade nicht arbeite) in einem weiter unten liegenden Ordner zu speichern. Ich schätze, dass ich sonst von ihnen abgelenkt werde.

Answer 2

Ich bin ein großer Fan Ihrer detaillierteren Blätter, aber auf der obersten Ebene bin ich viel besser, wenn das Dateisystem nach Projekten organisiert ist. Es ist viel wahrscheinlicher, dass ich mich in einem Code-Verzeichnis befinde und denke: "Hey, was war die Spezifikation dafür?", als dass ich mich im Spec-Verzeichnis befinde und denke: "Für welches Projekt wollte ich die Spezifikation?" Um Ihr Diagramm neu zu ordnen:

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

Davon abgesehen folgt die Organisation in meinem Büro Ihren Methoden und scheint eine größere Entwicklungsumgebung zu unterstützen. Ich persönlich finde es wirklich frustrierend, nach Mockups und anderen Cases in anderen Verzeichnissen als dem zu suchen, in dem sich mein Projekt befindet (insbesondere als Analytiker, der Spezifikationen getrennt von Marketingmodellen hat, aber ich schweife ab), aber aus Sicht der Prozessdelegation ist die Trennung dieser Konzepte wahrscheinlich sehr sinnvoll.

Nur meine Meinung dazu.

Answer 3

Ich bewahre alles in einem "c" auf: \projects " auf meinem Windows-Rechner und ~/projects auf unserer Unix-oid-Umgebung (Linux und Solaris). Darunter habe ich ein "Lern"-Verzeichnis (für Code-Experimente und Schnipsel /Verzeichnis) und dann ein Verzeichnis für jedes Projekt. Nach einiger Zeit, wenn ein Projekt nicht mehr existiert, lösche ich den lokalen Speicher und der Code wird nur noch in SVN archiviert.

Answer 4

• src\ <- Quellcodes für mehrere Projekte (unten)

• Tests

  • test_a <- Modul Test für a für r&d (verwendet einige Codes aus dem Ordner src)

  • test_b <- Modul Test für b für r&d (verwendet einige Codes aus dem Ordner src)

  • ...

• main_app_folder <- Hauptprojektdatei für die Produktion (verwendet die meisten Codes aus dem Ordner src)

• doc\ <- Dokumente

• Werkzeuge

  • tool_a <- tool a (verwendet einige der Codes aus dem Ordner src)

  • tool_b <- tool b (verwendet einige der Codes aus dem Ordner src)

• cleanup.exe / .ini <- Dienstprogramm zum Bereinigen temporärer Build-Dateien.

Projekte (in main_app_folder, tests oder tools) können .vcproj (visual studio c/c++), .mmp (Symbian makefile), Makefile (linux makefile) sein. Jedes Projekt hat seine eigene .cpp-Hauptdatei, die immer einen minimalen Satz an Funktionen enthält, alles andere ist mehr oder weniger wiederverwendbar (im src\-Ordner).

Der Unterschied zwischen einer Testanwendung und einer Werkzeuganwendung besteht darin, dass das Werkzeug etwas mehr oder weniger Nützliches anzeigt, während der Test nur überprüft, ob es funktioniert oder nicht.

Der Unterschied zwischen der Testanwendung und der Hauptanwendung besteht darin, dass die Testanwendung nicht die gesamte Funktionalität enthält und dass die Testanwendung möglicherweise einige spezielle #define aktiviert, die zum Testen benötigt werden. Normalerweise ist die Testanwendung ein reduzierter Satz der Hauptanwendung ohne zusätzliche #define.

Answer 5

Ich verwende normalerweise diese Verzeichnisstruktur:

• projekt_name
  • Code
    • src
    • Test
    • bauen
  • Entwurf
  • doc
  • Werkzeuge