it-swarm-eu.dev

Wie soll ich meinen Quellbaum organisieren?

Ich bin ein einzelner Entwickler, der hauptsächlich an Webprojekten (W/LAMP) und manchmal an C/C++ (Nicht-GUI) -Projekten von etwa durchschnittlichem Umfang arbeitet.

Ich habe oft Probleme mit der Strukturierung meines Quellcodebaums. Tatsächlich schließe ich ein Projekt normalerweise nicht ab, ohne den gesamten Baum zu entleeren und die Teile drei- bis viermal neu anzuordnen, was sehr viel Aufwand erfordert und darüber hinaus das Endergebnis wie ein Kompromiss erscheint.

Manchmal habe ich eine Überklassifizierung der Quelle - einen sehr langen Baum von Ordnern und Unterordnern. In anderen Fällen konzentriere ich einfach alle Dateien in einem bestimmten Ordner, basierend auf dem größeren Zweck, dem sie dienen, und führe dadurch zu "chaotischen" Ordnern in der Quelle.

Ich würde fragen wollen:

  • Gibt es Prinzipien/Logik/Best Practices, die mir helfen können, meinen Quellbaum besser zu strukturieren?
  • Gibt es grafische/grafische Techniken (z. B. DFD im Falle eines Datenflusses), mit denen ich meinen Quellbaum anhand der Analyse des Projekts im Voraus visualisieren kann?
  • Welche Strategie zur Strukturierung des mit dem Projekt verbundenen Multimedia-Dateibaums?

Über das Kopfgeld: Ich schätze bestehende Antworten mit den Mitgliedern, die ihre eigenen Praktiken teilen. Ich möchte jedoch allgemeinere und lehrreichere Antworten (oder Ressourcen) und mehr Antworten der Mitglieder fördern.

91
check123

Das Quellbaumlayout sollte die Architektur widerspiegeln. Als Konsequenz kann eine gut strukturierte Architektur zu einem gut strukturierten Quellbaumlayout führen. Ich empfehle, das POSA1-Ebenenmuster zu lesen, zu versuchen, Ihre Architektur in eine Ebenenstruktur einzupassen, dann jede der resultierenden Ebenen zu benennen und diese als Grundlage für Ihre Quellhierarchie zu verwenden. Nehmen Sie eine gemeinsame dreistufige Architektur als Basis:

  • präsentation/WebService (Präsentieren einer Web-Service-Schnittstelle zu unserer Geschäftslogik)
  • logik/* (Geschäftslogikmodule gehen hier rein)
  • storage/sql (Back-End-Speicher-APIs hier - dies verwendet eine SQL-Schnittstelle zum Speichern in einer Datenbank)
  • util/* (Utility-Code - kann von allen anderen Ebenen verwendet werden, bezieht sich jedoch nicht auf util, siehe hier)

Beachten Sie, dass die Ebenen keinen Code direkt enthalten, sondern ausschließlich zum Organisieren von Modulen verwendet werden.

Innerhalb eines Moduls verwende ich das folgende Layout:

  • <module> (Pfad zum Modul direkt; definiert modulare Schnittstelle)
  • <module>/impl/<implName> (eine spezifische Implementierung der modularen Schnittstelle)
  • <module>/doc (Dokumentation zur Verwendung des Moduls)
  • <module>/tb (Unit-Test-Code für das Modul)

bei dem die <module> befindet sich im Repository entsprechend der Ebene, zu der es gehört.

25
Aidan Cully

Ich kann Ihnen nicht wirklich viele Ratschläge zu Webprojekten geben, aber so strukturiere ich meinen Baum in einem Programmierprojekt (hauptsächlich aus C/C++ - Perspektive):

  • /
    • src - Von mir selbst geschriebene Quelldateien
    • ext - Enthält Bibliotheken von Drittanbietern
      • libname-1.2.8
        • include - Überschriften
        • lib - Kompilierte lib-Dateien
        • Donwload.txt - Enthält einen Link zum Herunterladen der verwendeten Version
    • ide - Ich speichere Projektdateien hier
      • vc1 - Ich ordne Projektdateien abhängig von der IDE an
    • bin - Kompilierte exe geht hier
    • build - Die Build-Dateien des Compilers
    • doc - Dokumentation jeglicher Art
    • README
    • INSTALLIEREN
    • KOPIEREN

Ein paar Anmerkungen:

  1. Wenn ich eine Bibliothek schreibe (und C/C++ verwende), organisiere ich meine Quelldateien zuerst in zwei Ordnern mit den Namen "include" und "src" und dann nach Modulen. Wenn es sich um eine Anwendung handelt, werde ich sie nur nach Modulen organisieren (Header und Quellen befinden sich im selben Ordner).

  2. Dateien und Verzeichnisse, die ich oben in kursiv aufgeführt habe, werden dem Code-Repository nicht hinzugefügt.

49
Paul

Das Maven Standard Directory Layout ist zwar spezifisch für Java, kann aber auch als gute Grundlage für andere Arten von Projekten dienen.

Hier ist die Grundstruktur (Sie könnten die 'Java'-Verzeichnisse durch' php ',' cpp 'usw. ersetzen):

src/main/Java       Application/Library sources 
src/main/resources  Application/Library resources  
src/main/filters    Resource filter files 
src/main/Assembly   Assembly descriptors 
src/main/config     Configuration files 
src/main/webapp     Web application sources 
src/test/Java       Test sources 
src/test/resources  Test resources 
src/test/filters    Test resource filter files 
src/site            Site 
LICENSE.txt         Project's license 
NOTICE.txt          Notices and attributions required by libraries
README.txt          Project's readme

Die Struktur gliedert sich grundsätzlich in 'src/main' und 'src/test' und wird dann nach Typ gruppiert.

15
Michal Miller

Im Idealfall verfügt die Organisation über ein einziges Repository, dessen Struktur das Engagement zwischen Engineering und Business verbessern und die Wiederverwendung fördern soll.

...\products\
...\products\productName\
...\products\productName\doc\

...\systems\
...\systems\systemName\
...\systems\systemName\doc\
...\systems\systemName\res\
...\systems\systemName\build\
...\systems\systemName\test\

...\library\
...\library\libraryName\
...\library\libraryName\doc\
...\library\libraryName\build\
...\library\libraryName\test\

...\devops\

Produkte

Ein Ordner pro Produkt; Hilft bei der Kommunikation, wie die Software das Geschäft unterstützt.

Im Idealfall ist jedes "Produkt" kaum mehr als eine Konfigurationsdatei, die angibt, welche Systeme aufgerufen werden sollen und wie sie konfiguriert werden sollen. Der doc-Unterordner kann die oberste Kurzbeschreibung\spec & jegliches Werbematerial usw. enthalten.

Durch die Trennung von Produkten und Systemen kommunizieren wir das Potenzial der Wiederverwendung an die kundenorientierte Seite des Geschäfts und bauen Silos pro Produkt auf. (Dies steht im Gegensatz zum Ansatz der "Produktlinie" für dasselbe Problem.)

Systeme

Ein Ordner pro System; Hilft bei der Kommunikation der primären Funktionen und der Gelegenheit/des Werts des Inhalts des Repositorys.

  1. "Konfigurationsverwaltungs" -Dateien, die Build- und Bereitstellungsumgebungen angeben.
  2. Testkonfiguration auf Systemebene (kann eine erhebliche Menge sein).
  3. Logik und Funktionalität auf höchster Ebene; Das schwerste Heben erfolgt durch Bibliotheksfunktionen.

Bibliothek

Wiederverwendbare Komponenten, die von verschiedenen Systemen aufgerufen werden. Die meisten Entwicklungsaktivitäten konzentrieren sich eher auf die Produktion von Bibliotheken als auf Systeme, sodass die Wiederverwendung in den Entwicklungsprozess "eingebunden" wird.

devops

Build, Continuous Integration und andere Funktionen der Entwicklungsautomatisierung.

Schlussfolgerung

Der Quellbaum ist ein Schlüsselelement der Dokumentation und prägt den Ansatz, die Struktur und die Psychologie der Geschäftsbeziehung mit seiner proprietären Technologie.

Die Treiber für diesen Ansatz werden in meiner Antwort auf diese Frage etwas ausführlicher erläutert: https://softwareengineering.stackexchange.com/questions/43733/who-organizes-your-matlab-code/59637#59637

6
William Payne

Ich weiß nicht wirklich über Konventionen Bescheid, aber alle meine Hauptprojekte werden mit Symfony Framework durchgeführt und ich habe mich an eine Baumstruktur wie die folgende gewöhnt:

wurzel/

  • apps
  • app Name
    • config (app-spezifische Konfigurationsdateien)
    • lib (app spezifische PHP-Dateien)
    • module (modulare Funktionsverteilung)
      • modulname
        • vorlagen (HTML)
        • aktionen (PHP-Code)
  • confing (Projektkonfigurationsdateien)
  • lib (PHP-Code, der in Hole Project verwendet werden könnte)
  • modell (Klassen, die die Projektinformationen darstellen)
    • base
  • form (PHP-Dateien, die Formulare verarbeiten, dies könnte ohne Symfony ziemlich schwierig zu erreichen sein)
    • basis (Basisformklassen)
  • web
  • cSS
    • bilder
    • file.css
  • js
  • log (Protokolldateien, die möglicherweise generiert werden)
  • daten (datenbezogene Informationen wie SQL-Patches oder was auch immer)
  • sql
  • plugins (verwendete Bibliotheken, die mit jeder App des Projekts zusammengeführt werden können)

Wenn Sie interessiert sind, lesen Sie bitte die Symfony-Dokumentation zu diesem Thema, um weitere Informationen zu erhalten ( MVC und Code Organization on Symfony ).

5
guiman

Was ich für jedes Projekt versuche, ist ähnlich wie:

  • src - Quelldateien, ein Ordner für jeden Namespace/jedes Paket zum einfachen Abrufen von Dateien (sogar Header-Dateien für C/C++)
  • ext - Für externe Bibliotheken/Bibliotheken von Drittanbietern ist es einfach, externe Geräte (z. B. SVN-Repositorys) hinzuzufügen. Im Inneren ein Ordner für jede Bibliothek (Binärdateien und Include-Dateien)
  • bin - für erstellte Binärdateien, könnte schnell zur Veröffentlichung exportiert werden
    • inc - für C/C++ - Headerdatei (kopiert von IDE/makefile/etc ...)
  • out - für alle vorübergehend generierten Dateien (.class, .obj etc ...) und es könnte ignoriert werden (zum Beispiel von SVN)
  • doc - für jede Dokumentation, die normalerweise mit Doxygen erstellt wird
  • res - Durch Platzieren von Ressourcen können Textquelldateien und vom Programm verwendete Binärressourcen getrennt werden. Ich habe nicht wirklich eine bestimmte Hierarchie.
    • config - für einige Konfigurationsdateien
    • zeichnbar - für einige Bilder oder Symbole

Alle IDE-Dateien oder Makefiles werden direkt im Stammverzeichnis gespeichert, wenn Sie nur eine davon verwenden.

3
Ninfomane

Ich mache so etwas. Funktioniert gut für ein plattformübergreifendes Spiel, das ich in meiner Freizeit mache. Leider sind die Dinge in der Arbeit viel weniger organisiert ...

Output                      <-- Build outputs
Docs
External
   <libname>
      Include
      Lib
Data
<ProjectName>.xcodeproj
<ProjectName>VS2010
Source
Temp                        <-- Intermediate stuff from builds and other tools
Tools
2
Colonel Panic

Ich mag die auf dieser Seite vorgestellten Ideen www.javapractices.com/topic/TopicAction.do?Id=205 . Grundsätzlich wird empfohlen, Ihr Projekt in Features (oder Module, Komponenten) zu organisieren. Zusätzlich zu den dort dargelegten Gründen:

  1. Weniger kognitive Belastung, wenn Sie über den Umfang des Codes nachdenken, an dem Sie arbeiten, da Sie die Garantie haben, dass jeder Code in der Funktion, an der Sie arbeiten, "funktionsprivat" ist.
  2. Es gibt ein zusätzliches Sicherheitsgefühl, wenn Sie garantiert sind, dass Sie nur Code für eine bestimmte Funktion ändern. Sie werden beispielsweise nichts anderes als die Funktion, an der Sie arbeiten, beschädigen. Auch dies liegt am "Feature-Private".
  3. Weniger kognitive Belastung einfach, da für ein bestimmtes Paket weniger Dateien angezeigt werden. Ich bin sicher, jeder hat ein Paket gesehen, das mehr als 15 Dateien enthält.

Beachten Sie, dass dies auf Java -Pakete (auch bekannt als Namespaces)) ausgerichtet ist. Für große Projekte empfehle ich aus den gleichen Gründen, das Projekt in mehrere Projekte (wie in mehreren Maven-Projekten) zu unterteilen, die a darstellen Business Feature. Für Maven-Projekte empfehle ich diese Lesen .

Bisher folgen die Projekte, an denen ich beteiligt war/bin, diesen nicht. Es gibt viele Gründe, aber hier einige:

  1. Das Missverständnis von Java Standardzugriffsmodifikator (am meisten missverstandener Zugriffsmodifikator gemäß diesem Buch )
  2. "Argumentum ad populum": Vorherrschende Kultur von Paket für Schicht (wahrscheinlich verursacht durch Grund Nr. 1)

Ich denke, es gibt eine verpasste Gelegenheit, Komplexität zu vermeiden, wenn die Organisation der Projektquellen zu Beginn des Projekts nicht ernst genommen wird, wie der Architekt Alexander sagte:

"Wie jeder Designer Ihnen sagen wird, sind es die ersten Schritte in einem Designprozess, die am meisten zählen. Die ersten Striche, die die Form erzeugen, tragen das Schicksal der anderen in sich." - Christopher Alexander

Abhängig von der Größe und Komplexität eines Projekts kann die verpasste Gelegenheit, Kosten oder ROI zu senken, sehr groß sein. (Ich bin daran interessiert, eine Studie zu sehen, um die genauen Zahlen dafür zu sehen)

2
thirdy

Für meine Teams versuchen wir, eine projektübergreifende Standardstruktur durchzusetzen, damit es einfach ist, Dinge zu finden, wenn das Team den Kontext wechselt, und um zu vermeiden, dass jedes Mal neu gelernt werden muss. Nicht alle Projekte benötigen alle Systeme, daher beginnen wir mit dem minimalen Satz.

/ Quelle/Komponente/Sprache

/ Quelle/Komponente/Drittanbieter /

/Dokumentationsanforderungen

/ Dokumentation/Design

/ Tests/Automatisiert/Einheit

/ Tests/Automated/ToolName

/ Tests/Handbuch

Dies führt zu einigen Überschneidungen, insbesondere unter dem Code und den Bibliotheken von Drittanbietern, aber zumindest vergessen wir nie die Antwort auf etwas wie "Was verwendet der RogueWave-Editor?"

2

Meine Empfehlung ist, eine Vielzahl von Frameworks oder Engines herunterzuladen und zu sehen, wie große Entwicklungsteams mit dem Layout ihrer Ordner umgegangen sind.

Es gibt so viele Möglichkeiten, Dateien zu organisieren, dass es besser ist, eine auszuwählen und bei jedem Projekt daran festzuhalten. Halten Sie sich bis zur Fertigstellung oder Überarbeitung an eine bestimmte Konvention, um Fehler zu vermeiden und unnötige Zeit zu verlieren.

Sie können Laravel-, Symphony- oder Codeigniter-Frameworks für Webprojekte herunterladen, um ein sofort funktionierendes Ordnerlayout zu erhalten.

Also werde ich versuchen, ein Ordnerlayout zu vermitteln, das jeder Entwicklung gemeinsam ist:

MVC (Model View Controller) bietet ein gutes Organisationsparadigma.

Root-Quellcode könnte src (C++) oder app (Webentwicklung) sein

Eine Dateistruktur, die kein klares Ziel für die Klassen hat, die sie gruppiert, führt definitiv zu Verwirrung. Es geht nicht nur darum, Code zu organisieren, sondern kann auch automatische Lader, Klassenfactory, lokalen Wrap-Speicher, Remote-Speicher und Namespace unterstützen.

Diese Ordnerstruktur wurde von Laravel Framework abgeleitet und vereinfacht. Meine Präferenz für diesen Beitrag ist die Benennung im Plural, aber ich verwende in meinen Projekten einzelne Wörter.


src/storage (Implementierungen von models/file-storage/api/mysql/sql-lite/memcached/redis)

src/repositories (Ein Wrapper von 'Speicherimplementierungen' mit einer Speicherlogik, einer gemeinsamen Schnittstelle und einer Konvention für Rückgabeergebnisse.)

src/services | Logik | Entitäten (App-Geschäftslogik)

src/controller (Wird bei der Webentwicklung verwendet, um Serveranforderungen an Ihre Dienste weiterzuleiten.)

src/modules | systems (Modulare Systeme, die die allgemeine Funktionalität Ihres Frameworks erweitern. Dienste können Module verwenden, jedoch nicht umgekehrt)

src/helpers (Helfer- oder Wrapper-Klassen wie z. B. String-Manipulation. Oft kann dies bei libs | vendor sein, wenn Dritte)

src/types (Benannte Aufzählungen)

public | build | output (web oder c ++)

config (Setup-Dateien. YAML wird für plattformübergreifende Konfigurationsdateien immer beliebter.)

Cache

Protokolle

lang (en/es/ru/...)

Bootstrap (Startet das Framework und die App)

docs (Dokumentation im Markdown-Format .md)

Tests (Unit Testing)

Datenbank/Migrationen (Datenbankstruktur von Grund auf neu erstellen)

Datenbank/Seeds (Füllt Ihre Datenbank mit zu testenden Dummy-Daten)

libs | vendor (alle Software von Drittanbietern. 'libs' unter C++ und 'vendor' normalerweise unter PHP)

Assets | Ressourcen (Bilder/Sounds/Skripte/JSON/beliebige Medien)

2
Heroselohim

Mit objektorientierten Sprachen können Sie Namespaces erstellen. Diese logische Aufschlüsselung, die zum Trennen von Teilen der Anwendung verwendet wird, um eine Kopplung zu vermeiden, ist die Hauptursache für die Aufschlüsselung des Speicherorts logischer Dateien. Die Verwendung der Kopplung als Grund für das Auseinanderbrechen von Namespaces ist ein guter Ausgangspunkt http://en.wikipedia.org/wiki/Software_package_metrics .

Andere haben darüber gesprochen, das Projekt in Bezug auf Build einzurichten, aber sobald Sie sich mit der Quelle selbst befasst haben, geht es darum, was Sinn macht - verwenden Sie einfach, wie Sie den Code trotzdem logisch aufteilen.

1
Travis