Direkt zum Hauptinhalt springen

Felix Nehrke

Ich schreibe hier über Softwareentwicklung und Softwarearchitektur.

english

Projektordner organisieren

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 wieder zu finden und wunderte mich manchmal über den Ort wo ich Ordner fand. Erstmals habe ich das Problem addressiert, 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, worin wiederum jeder Ordner eine Website repräsentierte, die ich geschrieben habe, oder an der ich arbeitete. Das war einfach und erfüllte seinen Zweck, allerdings zeigten sich schnell die Nachteile dieser Struktur:

Im Laufe der Jahre kamen immer wieder neue Ideen, Technologien und Fragestellungen auf, weshalb ich meine Strategie immer wieder angepasst habe, sodass ich zu meinem heutigen Aufbau gekommen bin. Obwohl der Prozess noch nicht abgeschlossen ist denke ich trotzdem, dass dieser Beitrag hilft, ein besseres Verständnis für die Organisation zu erlangen.

Struktur

Um einen Überblick meines Setups zu erhalten visualisiere ich es hier einmal und erkläre anschließend, wie es zustande kommt.

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

Diese Struktur sieht auf den ersten Blick vielleicht erstmal gewaltig, komplex oder übertrieben aus, aber sie folgt einigen einfachen Regeln. Sie setzt sich im allgemeinen 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 der Ordner Entwicklung. Dieser Ordner ergänzt hervorragend die Struktur von xdg-user-dirs und kennzeichnet klar den Ordner in dem ich meine Entwicklungsprojekte ablege.

xdg-user-dirs ist ein Programm, welches eine Reihe von Standardordnern verwaltet, um Daten besser zu organisieren. Es wird von freedesktop.org entwickelt, einer Organisation die Normen rund um graphische Computersysteme erarbeitet. Diese Normen werden von diversen Programmen in der Linux-Welt berücksichtigt und lassen sich in der Regel ohne Probleme auch auf macOS und Windows anwenden.

Die Organisationseinheiten

Innerhalb des Basisordners pflege ich für jede Organisationseinheit einen eigenen Ordner. Das ermöglicht mir genau zu festzulegen, ob es sich um ein privates Projekt, ein Firmenprojekt, ein Kundenprojekt oder auch ein Open-Source-Projekt handelt. Hierbei empfiehlt es sich Gedanken zur Benennung der Organisationseinheit zu machen. Für meine privaten Projekte benutze ich dabei einfach mein Internetsynonym. Bei Firmen oder anderen Organisationen benenne ich diese Verzeichnisse in der Regel einfach nach deren Name in kleinen Buchstaben und mit Minuszeichen als Worttrenner.

Die Projekt URL

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

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

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

Die Befehle, die hierfür nötig sind, sind überschaubar (Ich 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 Softlink an.

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

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

$HOME
└── Entwicklung
    ├── examples
    │   └── git.org.example.com
    │       └── Org
    │           └── Repos
    │               └── Project
    └── alternative-organisation
        └── git.org.example.com
            └── Org
                └── Repos
                    └── Project → ~/Entwicklung/examples/git.org.example.com/Org/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 ein Reihe von Vorteilen. Insbesondere ermöglicht 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 aufwändige Struktur. Allerdings denke ich, dass dieser Umstand vernachlässigbar ist und es lediglich einer Eingewöhnung bedarf, um anschließend die Vorteile zu genießen.