
Du möchtest wissen, wie man ein neues Coding Projekt strukturiert?
Das ist Deine Anleitung!
Starten wir!
-
1
Häufige Fragen
- 1.1 Warum brauche ich im Projekt eine Struktur?
- 1.2 Woran soll ich mich orientieren?
- 1.3 Wie lang soll eine Datei sein?
- 1.4 Wie vermeide ich zyklische Abhängigkeiten?
- 1.5 Wie behalte ich die Übersicht?
- 1.6 Neuer Ordner oder neues Repository?
- 1.7 Wo speichere ich mein Projekt ab?
- 1.8 Wie visualisiere ich die Ordner am besten?
- 1.9 Wie dokumentiere ich die Struktur?
- 1.10 Wie benenne ich die Ordner – deutsch oder englisch?
- 1.11 Wie viele Ordner sind sinnvoll?
- 2 Grundlegende Struktur
Häufige Fragen
Warum brauche ich im Projekt eine Struktur?
Jedes Projekt beginnt klein und eine Struktur erscheint überflüssig. Nach wenigen Tagen ist aus dem kleinen (Hobby) Projekt eine riesiger Codewust geworden.
Du solltest jedes Projekt in Ordner und Abschnitte strukturieren, um spätere Probleme zu vermeiden. Selbst kleine Sammlungen an „unzusammenhängenden“ Skripts kannst Du zu einer Toolbox zusammenfassen, die Du als Bundle einfach sortieren / transportieren kannst.

Woran soll ich mich orientieren?
Das Einfachste ist, mit dem Sortiersystem anderer zuarbeiten, welche schon länger die Programmiersprache oder Framework nutzen. Viele Frameworks initialisieren mit einem Skript eine Menge an Dateien oder Ordner, um einen Start zu erhalten.
Statt Angst vor dem weißen Bildschirm zu haben, sind erste Layouts und Templates im Framework beinhaltet. Ein anderer Weg ist es sich, ein Git-Repo eines erfolgreichen „kleinen“ Projekts zu kopieren und dies so zu modifizieren, dass diese Deine Erwartungen entsprechen.
Wie lang soll eine Datei sein?
Dateien sollten nur die Funktionen beinhalten, diese sie beschreiben. Die Datei FileAccess.go sollte nur Funktionen beinhalten, die den Zugriff einer Datei auf der Festplatte steuern.
500 – 1000 Zeilen sind eine gute maximale Länge für ein Coding Script. Jetzt kannst Du überlegen, ob Du die Datei splittest. Wenn Du häufig am Scrollen bist, ist eine Teilung sinnvoll.

Wie vermeide ich zyklische Abhängigkeiten?
Visualisiere Dir einen Baumstruktur / Graph von Deinen Importen. Jede Datei hat zu Beginn (bei Java, TypeScript / Golang) eine Liste an importierten externen und internen Bibliotheken. Achte darauf, dass Du keine Kreise baust, indem Du Dir eine Baumstruktur vorher aufzeichnest. Wo sollen die Funktionen gespeichert werden – welche Funktionen werden, wo gebraucht? Zyklen solltest Du vermeiden, indem Du Funktionen verschiebst. Macht in Deinem Fall ein Helper-Skript Sinn?

Wie behalte ich die Übersicht?
Eine gute IDE ist die Grundlage für eine gute Übersicht. Links solltest Du den Baum mit den Dateien eingeblendet haben. Diese beinhaltet die Ordnerstruktur und die Dateien. Wechsel zwischen den Dateien hin und her oder nutze den Shortcut (Strg + P bei Visual Studio Code).
Schließe Baumpfade / Ordnerpfade, an denen Du nicht mehr arbeitest, um die Übersicht über den Teilbereich zu behalten.
Unter der Ordner-Baumdarstellung findest Du ein Inhaltsverzeichnisses / „Outline“. Dort sind alle Funktionen und globale Variablen gelistet. Benenne Funktionen, die ähnliche Aufgaben machen ähnlich und positioniere diese untereinander. Jetzt merkst Du schnell, wenn Funktionen in einer Datei gelandet sind, die thematisch nicht zusammenpassen.
Neuer Ordner oder neues Repository?
Hier ist Fingerspitzen Gefühl gefragt. User Interface und Backend trennt man normalerweise in verschiedenen Repos, aber ein einfacheres Deployment für Neueinsteiger kann auch hilfreich sein. Je nach Anwendungsfall ist eine Trennung sinnvoll: Ein Repo pro Microservice mit klar definierten Umfang.
Wo speichere ich mein Projekt ab?
Code gehört immer in Repositorien mit einem Versionierungsprogramm wie Git. Der Vorteil ist, dass viele Personen im gleichen Code arbeiten können. Selbst als Einzelkämpfer ergibt die Software Git Sinn, um den Zwischenstand des Coding zu sichern und zu einer stabilen Version zurückzukommen.
In der Open Source Welt nutzen die Teilnehmer die Software Git, um neue Ideen mit einem Merge Request dem Hauptprojekt hinzuzufügen. Jeder Starter eines Repos (Maintainer) entscheidet, ob das Feature / Verbesserung sinnvoll ist oder nicht.

Wie visualisiere ich die Ordner am besten?
Die meisten Menschen Sinn visuell orientiert / lernend. Ordnerstrukturen und unterschiedlichen Dateiformate kann Visual Studio Code mit der Erweiterung Material Icon Theme ausschmücken. Das sieht nicht nur optisch gut aus, sondern erlaubt dem Auge ein schnelleres Suchen, weil die markanten kleinen Bilder eine gute Orientierung geben.
Wie dokumentiere ich die Struktur?
Jedes Projekt braucht eine Readme.md auf der ersten Ebene der Struktur. Dort beschreibt der Maintainer grob, worum es in diesem Projekt geht und wie man den Code compiliert. Eine Beschreibung der Struktur ist vom Vorteil, wenn man später noch nachvollziehen will, wo welche Funktionen stehen.
Wie benenne ich die Ordner – deutsch oder englisch?
Die meisten Entwickler, die Programmieren, kommen früher oder später in den Kontakt mit der englischen Sprache. Grundsätzlich ist alles im Programmieren im Englischen gehalten, aber Doku und anderen wichtige Texte sollte mehrsprachig sein, wenn man eine große, breite Masse mit seinem Projekt adressieren will.
Wie viele Ordner sind sinnvoll?
Die 7er-Regel ist eine gute Orientierung, um die maximale Ordneranzahl festzulegen. Jeder Ordner beinhaltet maximal 7 Ordnern und zusätzlich X Dateien. Wenn wir mehr als 7 Ordner haben überlegen wir, ob wir neue Gruppen schaffen und eine weitere Ebene an Ordner einziehen.
Wenn es bei dem Projekt Sinn ergibt 10 Ordner nebeneinander anzulegen, dann mache Dich nicht verrückt. Die willkürliche Zahl ist ein Richtwert, der beschreibt, dass Du es mit Ordner nicht übertreiben sollst.
Grundlegende Struktur
- src: Hier liegt der zentrale Code für die Ansichten z. B. Home, Detail, Einstellung usw.
- helper: Kleine Funktionen, die lästige Dinge erledigen / immer wieder nützlich sind
- docu: Dokumentation, die über die README herausgeht.
- test: Testfälle, die Code in src prüfen
- storage: Ort, wo die Software Daten ausgibt und ausließt.
- Dockerfile: Docker ist zwar kein Muss, aber Industriestandard, um anderen Personen die Software leicht zugänglich zu machen.
- docker-compose: Damit der Docker-Container noch schneller läuft, gebe direkt einen vorkonfigurierten Vorschlag, wie man den Container startet.
- Jenkinsfile: Die Zukunft von Software Projekten läuft in Pipelines ab. Ein Projekt ohne Pipelines ist häufig ungetestet und viele Standardaufgaben sind nicht automatisiert
- Readme.md: … ist der Einstiegspunkt für viele Neulinge. Um was geht es in Deinem Projekt. Dokumentiere hier nur die wesentlichen Aspekte.
- LICENCE: In Deutschland haben wir das „automatische Urheberrecht“, das die Adaption oder Nutzung Deines Codes verbietet. Damit auch international Dein Code genutzt oder mitgearbeitet werden kann, solltest Du dringend eine Lizenz angeben. GPLv3 ist der Weg, wenn Du offen für Zusammenarbeit bist, aber Angst vor „Diebstahl“ durch Konzerne hast.



Schreibe einen Kommentar