Softwaretechnik Projektlayout

[ZuseZ3]

Guten Abend ihr Freunde der Nacht,

ich habe eine kleine Frage bezüglich einem Projektlayout.

Gegeben sei eine Software, die auf oberster Ebene in 4 Bereiche unterteilt wurde, welche zwar zusammenarbeiten (keine Kreis-relationen), aber unabhängig voneinander ausgetauscht werden können.
Diese 4 Bereiche beinhalten jeweils mehreren Klassen.
Zu jeder Klasse wurden verschiedene Testfälle geschrieben.

Es handelt sich um c++ code mit verschiedenen .h und .c++ Dateien.
Nun stellt sich die Frage, wie ich dies aufteile.
Erstelle ich auf oberster Ebene 3 Folder (src, include (.h Dateien) und test), und baue in jeder parallel den Baum aus 4 Bereichen und Klassen in jedem Bereich?
Oder lege ich auf oberster Ebene einfach die 4 Folder an, in jedem einen Unterfolder für die entsprechenden Klassen und in den Unterfoldern die verschiedenen Folder für src, include und test?
Ich tendiere von meinem Gefühl her stark für letzteres, allerdings habe bisher eher die erste Unterteilung bei anderen Leuten gesehen.
Dies verwundert mich. Da ich online sehr variierende Ergebnisse erhalte, wollte ich mal nach eurer Einschätzung fragen.
Liege ich richtig damit für jede Klasse ein src/include/test folder anzulegen?

 

[QuasarAI]

In Java kenne ich es so, dass Klassen im eigenen src folder liegen. Dann gibt es ein test Ordner/Package auf gleicher Ebene. Die Testklassen folgen den Pfadnamen und Klassennamen, nur haben die Testklassen hinten noch ein "Test" beim Namen dran.

Will man ein Feature löschen, dann muss es aus /src/feature und /src/test/feature entfernt werden.

 

[BeBur]

Ich würde das auf oberster Ebene nach den Komponenten anordnen, soweit deine IDE / dein Framework das gut unterstützt. Falls nicht hast du nach hinten raus ggf. viel Ärger mit Namespaces, Pfaden, u.ä.

In diesem Vortrag spricht der sehr bekannte Bob Martin über genau die Unsitte, dass man auf der obersten Ebene rein gar nichts über die Anwendung erfahren kann, nur über das Framework: YT Link

 

[new Account()]

Liege ich richtig damit für jede Klasse ein src/include/test folder anzulegen?

Nein.
Src heißt "Source Code" - alle deine Klassen sind source code, also kommen alle deine Klassen in den Ordner.

Was sind denn überhaupt die 4 Bereiche?
Sind das 4 Sammlungen von Klassen, welche einen Themenbereich abbilden Oder 4 Sammlungen Von Klassen die eine Funktionalität abbilden?
Sind die 4 Bereiche jeweils für andere Projekte wiederverwendbar?

Was heißt zusammenarbeiten?


Egal was die Antwort auf die Fragen ist, würde ich auf Der obersten Ebene src, include, test, etc empfehlen.
Warum?
Dein Projekt ist ein Projekt mit Source Code und einem include Ordner um dein Projekt zu nutzen.
Angenommen dein Code ist eine library und du stellst sie anderen zur Verfügung, stellt sich für die user die Frage: Was soll ich nun includen?
Welchen docs Ordner soll ich nun lesen?

Wenn deine 4 Bereiche größere, wiedervendbare Sammlungen Von Funktionalität darstellen würden, mach einfach 4 Projekte draus, und binde Projekt 1 in Projekt 2 ein.
Vorteil:
Jedes Projekt hat eine Funktionalität, möchte ich diese verwenden, weiß ich auch direkt wie (da Konvention). Wie das Projekt aufgeteilt ist, was dessen Abhängigkeiten sind, wie es intern aufgebaut ist, interessiert mich nicht, Oder?

Src, test, docs, etc. Ist einfach eine Konvention für den User.

Falls noch nicht getan, schau dir mal CMake und Alternativen an.

Ergänzung (6. Januar 2020)

In diesem Vortrag spricht der sehr bekannte Bob Martin über genau die Unsitte, dass man auf der obersten Ebene rein gar nichts über die Anwendung erfahren kann, nur über das Framework: YT Link

Man erfährt das was man als Benutzer erfahren muss:
docs für Dokumentation
tests für Tests
src für SourceCode (um den ich mich nicht kümmern muss)
include für die Header
CMakeLists.txt zum Bauen
README.md für einen Überblick über die Applikation

Ich geh mal auf dein Youtube Video (c.a. Minute 7-11) ein:
1. Man sieht von der Ordnerstruktur, dass es eine Rails App ist. Rhetorische Frage: Warum soll eine Ordnerstruktur das deutlich machen?
Antwort: Wer hat gesagt, dass das die Absicht hinter der Ordnerstruktur ist?

2. Was macht die Applikation - ausgehend von der Ordnerstruktur?
Antwort: Ist der Zweck der Ordnerstruktur aufzuzeigen was die Applikation macht? Nein. Wenn du wissen willst was sie macht, öffne README.md oder den docs Ordner.

3. Man sieht sofort, dass es eine Rails App ist, also ist das das wichtigste Information über die Applikation und der Rest ist uns egal.
Antwort: Sinn?

4. Ordnerstruktur ist die Architektur des Programms
Antwort: Nein?

5. Grundrisskizze einer Bibliothek/Kirche zeigt, dass es eine Kirche ist. Die Ordnerstruktur zeigt meines Programms zeigt es nicht.
Antwort: Dann schau dir eine Skizze der Architektur an - so wie man das bei der Kirche gemacht hat - und nicht die Ordnerstruktur.

7. Man sieht sofort den Altar, etc. Folge: Man sieht sofort, dass es eine Kirche ist. Implikation: Die Intention der Grundrisskizze ist zu sehen, dass es eine Kirche ist.
Reaktion: Genau...

Kann man den wirklich ernst nehmen?
Ein Link zum Sichtenmodell würde dem bestimmt helfen: https://de.wikipedia.org/wiki/4+1_Sichtenmodell.
Wahrscheinlich würde damit sein ganzes Weltbild zerstört werden.

Ergänzung (6. Januar 2020)

PS:

Es handelt sich um c++ code mit verschiedenen .h und .c++ Dateien.
Nun stellt sich die Frage, wie ich dies aufteile.
Erstelle ich auf oberster Ebene 3 Folder (src, include (.h Dateien) und test), und baue in jeder parallel den Baum aus 4 Bereichen und Klassen in jedem Bereich?

Wenn du ein neues Projekt aufbaust -> lies dich doch gleich in Modules, welche #includdes ersetzen werden, ein und wende das an.

 

[BeBur]

Darüber kann man sicherlich lange und auch ergiebig diskutieren. Hier an der Stelle vielleicht nur ein ganz klein wenig ;-).

Ich mag die Vorstellung 'domain-driven' zu programmieren, vs. 'framework-driven'. Geht auch in die Richtung self-documenting code.
Ich finde bei einem Programm/Projekt sollte direkt ins Auge springen, was die Hauptzwecke des Programmes sind, was die wichtigsten Entitäten und zentralen Datenflüsse sind und Details der Implementierung (Aufteilung in Header und Implementierung z.B.) sollten dem zurückstehen.

Ich denke dabei eher an Stadtkarten als an Gebäudepläne. Die große Übersichtskarte zeigt die wichtigsten Straßen und am Rand, wo ich Detailinformationen zu jedem Quadrant finde.
Was wir machen: Eine Liste der Quadranten nummern und eine readme, was sich in jedem Quadranten befindet.

Beim zweiten Nachdenken: Ich denke wenn der TE unsicher ist, dann sollte er dem faktischen Standard folgen und wie du schon geschrieben hast ein einzelnes Projekt bauen mit der normalen Ordnerstruktur und ggf. einzelne Bestandteile als Module o.ä. extrahieren.

 

[new Account()]

Ich mag die Vorstellung 'domain-driven' zu programmieren, vs. 'framework-driven'. Geht auch in die Richtung self-documenting code.

Self documenting code kannst du immer schreiben.
Hat wenig mit der Ordnerstruktur zu tun.

Bei Domain Driven Design geht es auch eher um die Modellierung von Software und nicht dessen Orderstruktur.
Potentiell Einfluss in die Ordernstruktur haben kann die Nutzung von Frameworks (oder auch Tools).

Folge: Ich verstehe nicht ganz was du sagen möchtest.
Auch hilft "mögen" nicht viel weiter. Manche "mögen" sich gerne selbst Schmerzen zufügen.

Ich finde bei einem Programm/Projekt sollte direkt ins Auge springen, was die Hauptzwecke des Programmes sind, was die wichtigsten Entitäten und zentralen Datenflüsse sind und Details der Implementierung (Aufteilung in Header und Implementierung z.B.) sollten dem zurückstehen.

Dafür hast du ja die README.md.
Guck hier: https://git.pattle.im/pattle/app
Du weißt sofort was der Hauptzweck des Programms ist.
Hier auch: https://github.com/NeuralEnsemble/PyNN, https://github.com/microsoft/vscode
Und egal was du suchst: Du weißt wo du hinmusst.


Zeig mir mal ein Beispiel, wo du den Hauptzweck, die wichtigsten Entitäten, die zentralen Datenflüsse direkt von dem obersten Struktur sichtbar ist.
Wie würdest du überhaupt Datenflüsse im Dateisystem abbilden?

Was wäre der Vorteil daran die wichtigsten Entitäten in die oberste Ebene der Dateistruktur zu packen?

Ich denke dabei eher an Stadtkarten als an Gebäudepläne. Die große Übersichtskarte zeigt die wichtigsten Straßen und am Rand, wo ich Detailinformationen zu jedem Quadrant finde.
Was wir machen: Eine Liste der Quadranten nummern und eine readme, was sich in jedem Quadranten befindet.

Ich verstehe den Vergleich absolut nicht.

Ist das Programm nun eine Stadt?
Und der Source Code sind Unterlagen zu einer Stadt?
Wäre er nicht eher der Bauplan zu der Stadt und nicht die Stadtkarte?

Oder ist der Source Code die Stadt? (Wenn ja: was ist mit Dokumentation?)
Wo sind die Parallelen zwischen Stadt und Source Code

 

[BeBur]

Deine Argumente sind gut und ich denke wir können das bald abschließen hier. Abschließend von mir noch Erläuterungen, da mein letzter Beitrag offenbar nicht gut verständlich war.

Self documenting code kannst du immer schreiben.
Hat wenig mit der Ordnerstruktur zu tun.

Bei Domain Driven Design geht es auch eher um die Modellierung von Software und nicht dessen Orderstruktur.
Potentiell Einfluss in die Ordernstruktur haben kann die Nutzung von Frameworks (oder auch Tools).

Folge: Ich verstehe nicht ganz was du sagen möchtest.

Ich wollte darauf hinaus, dass neben dem Code eben auch die Ordnerstruktur 'self-documenting' sein sollte.

Ich verstehe den Vergleich absolut nicht.

Das Projekt / 'der Projektordner' ist der Stadtplan. Die Ordner (z.B. in der obersten Ebene) sind die Planquadranten. Bei einem Blick darauf sollte man eine Übersicht über die Stadt / das Projekt kriegen können.