Projektordner organisieren

5. Juli 2020

Als Entwickler habe ich immer wieder mit verschiedenen Projekten zu tun. Viele davon unterscheiden sich erheblich voneinander, andere sind sehr ähnlich oder hängen miteinander zusammen. Was sie jedoch eint, ist der Umstand, dass ich sie schlecht organisiert hatte. Später fing ich an mir Gedanken über die Ordnerstruktur zu machen und sie, wie der Name schon sagt, zu ordnen. In diesem Beitrag möchte ich diese Organisation näher bringen und erläutern, wie ich zu ihr gelangt bin.

Hintergrund

Dieser Text ist, wie eingangs bereits angedeutet, ein direktes Resultat meiner Erfahrungen. Früher waren meine Dokumente, Ordner und Projekte über das ganze Dateisystem verstreut. Mit der Zeit fiel es mir dadurch immer schwerer sie wiederzufinden und fand manche Dinge auch gar nicht wieder. Erstmals habe ich das Problem adressiert, als ich angefangen habe zu programmieren.

Damals fing ich an alle meine Projekte in einem Ordner zu sammeln. Ich hatte einfach irgendwo einen Ordner namens web liegen. Darin repräsentierte wiederum jeder Ordner eine Website an der ich arbeitete. Das war einfach und erfüllte seinen Zweck, allerdings zeigten sich schnell die Nachteile dieser Struktur:

Wie organisiere ich eine Website, die aus mehreren einzelnen Projekten besteht?
Wie halte ich verschiedene Aufgaben auseinander?
Was mache ich im Falle eines Namenskonflikts?
Ist das eigentlich ein Webprojekt?

Im Laufe der Jahre kamen immer wieder neue Ideen, Technologien und Fragestellungen auf. Entsprechend habe meine Strategie immer wieder angepasst und bin so zu meinem heutigen Setup gekommen. Dieses Setup möchte ich hier nun vorstellen, um ein besseres Verständnis für die Organisation zu schaffen. Und auch wenn der Prozess nie fertig wird, hilft das Modell bestimmt dem Einen oder Anderen bei seinen Aufgaben.

Struktur

Als ersten Überblick visualisiere ich einmal das Ergebnis meines Setups und erkläre es anschließend genauer.

$HOME
└── Entwicklung (1)
    ├── acme-company (2)
    │   ├── github.com
    │   │   └── acme
    │   │       └── open-source-project (3)
    │   ├── gitlab.example.com
    │   │   ├── Project-A
    │   │   │   ├── service-a
    │   │   │   └── service-b
    │   │   └── Project-B
    │   │       ├── service-a
    │   │       ├── […]
    │   │       └── service-n
    │   └── svn.example.com
    │       └── legacy-project
    └── nemoinho (2)
        ├── gitea.nehrke.info
        │   └── nemoinho
        │       └── nehrke.info
        └── github.com
            └── nemoinho
                └── GreasemonkeyHeaderPlugin

Diese Struktur sieht auf den ersten Blick vielleicht gewaltig und komplex aus, aber sie folgt einigen einfachen Regeln. Sie setzt sich nämlich nur aus den folgenden Elementen zusammen:

1	Ein Ordner als Ausgangsbasis
2	Eine oder mehrere Organisationseinheiten
3	Die URL zum Projekt

Die Ausgangsbasis

Als Basis dient mir der Ordner Entwicklung, welcher hervorragend die Struktur von xdg-user-dirs ergänzt. Der Ordner kennzeichnet, anhand seines Namens, klar den Zweck Entwicklungsprojekte zu verwalten.

xdg-user-dirs ist ein Programm von freedesktop.org, welches eine Reihe von Standardordnern verwaltet, um Daten besser zu organisieren.

Die Organisationseinheiten

Innerhalb des Basisordners pflege ich für jede Organisationseinheit einen eigenen Ordner. Dadurch kann ich genau den Kontext eines Projekts festlegen und weiß so genau über dessen Hintergrund bescheid. Für meine privaten Projekte benutze ich zum Beispiel einfach mein Internetsynonym als Organisation. Bei Firmen oder anderen Organisationen benenne ich diese Verzeichnisse in der Regel einfach nach deren Namen. Wichtig ist mir dabei nur konsistent zu bleiben, darum schreibe ich die Ordner stets klein und mit Minuszeichen als Worttrenner. Allgemein gilt aber vor allem sich kurz Gedanken zur Benennung zu machen und einen sinnvollen Namen zu wählen.

Die Projekt URL

Schlussendlich folgt eine URL zum eigentlichen Projekt. Dabei wird versucht die URL zum Remote-Code-Repository abzubilden, auch wenn dieses vielleicht noch nicht existiert.

Beispiel-URL: https://git.org.example.com/Org/Repos/Project.git

Das Protokoll wird ignoriert
Die Domain ist ein Ordner, z.B. git.org.example.com
Jede Ebene der URL vor dem Projekt wird zu einem Ordner
Das Projekt wird geklont

Die nötigen Befehle hierfür sind überschaubar (Ich arbeite viel im Terminal und nutze hauptsächlich bash für so etwas):

mkdir -p ~/Entwicklung/examples/git.org.example.com/Org/Repos
cd $_
git clone https://git.org.example.com/Org/Repos/Project.git

Das Resultat sieht entsprechend so aus:

$HOME
└── Entwicklung
    └── examples
        └── git.org.example.com
            └── Org
                └── Repos
                    └── Project

Weitere Tipps

Es kommt immer mal wieder vor, dass sich ein Projekt nicht eindeutig einer Organisationsstruktur zuordnen lässt. In diesem Fall nutze ich sehr gerne die Möglichkeit von Symlinks im Dateisystem. Hierzu ermittle ich, welcher Organisationseinheit das Projekt eher zuzuordnen ist und speichere es entsprechend hier ab. Anschließend lege ich in der alternativen Organisationseinheit einen gleichartigen Symlink an.

mkdir -p ~/Entwicklung/examples/git.example.com/Repos
cd $_
git clone https://git.example.com/Repos/Project.git
mkdir ~/Entwicklung/alt-org/git.example.com/Repos
ln -s ~/Entwicklung/examples/git.example.com/Repos/Project $_

Das Resultat ist ein übersichtlicher Aufbau, der sich gut in die restlichen Projekte eingliedert:

$HOME
└── Entwicklung
    ├── examples
    │   └── git.example.com
    │       └── Repos
    │           └── Project
    └── alt-org
        └── git.example.com
            └── Repos
                └── Project → ~/Entwicklung/examples/git.example.com/Repos/Project

Dieses Vorgehen kann man auch sinnvoll anwenden, wenn man ein Projekt umbenennen will. Hierbei sind manchmal noch alte Referenzen im System vorhanden, aber wir kommen nicht dazu alles auf einmal aufräumen. In diesem Fall benenne ich das Projekt einfach um und lege einen Symlink an, der vom alten Ort an den neuen Ort verweist.

Fazit

Das System bietet eine Reihe von Vorteilen. Insbesondere ermöglicht mir dieses Vorgehen Metainformationen zuzuordnen. Es bietet aber auch Anwendungen, die weniger offensichtlich sind. Mit dieser Strategie fällt zum Beispiel die Entwicklung mit Go sehr leicht, da die Anforderungen an den GOPATH bereits erfüllt werden. Nachteilig ist eventuell die aufwendige Struktur. Insgesamt denke ich jedoch, dass die Nachteile durch die Vorteile mehr als ausgeglichen werden. Es bedarf lediglich einer kleinen Eingewöhnung um die Vorteile voll auszuschöpfen.