Alle Technologien

// technologien

Tooling

Werkzeuge entscheiden nicht über die Qualität einer Anwendung, aber darüber, wie teuer Änderungen daran werden. Versionierung, Nachvollziehbarkeit und automatisierte Prüfung sind die Grundlage dafür, dass auch nach Monaten noch klar ist, warum etwas so gebaut ist.

// einsatz

Wie ich das einsetze

  • Jede Änderung nachvollziehbar

    Kleine Commits mit verständlicher Beschreibung. Wer später sucht, warum eine Zeile existiert, findet die Antwort im Verlauf statt in Vermutungen.

  • Arbeit in Zweigen

    Neue Funktionen entstehen getrennt vom Hauptstand und werden erst zusammengeführt, wenn sie geprüft sind. Der Hauptstand bleibt jederzeit auslieferbar.

  • Prüfen vor dem Zusammenführen

    Typprüfung, Linting und Tests laufen automatisch vor der Übernahme. Was durchfällt, wird nicht zusammengeführt.

  • Entwurf als gemeinsame Grundlage

    Vorlagen aus Figma dienen als Abgleich für Abstände, Zustände und Zwischengrößen – und als Ort, an dem Rückfragen geklärt werden, bevor sie im Code auftauchen.

// im detail

Die einzelnen Technologien

  • Git

    Versionsverwaltung als Grundlage von allem: Verlauf, Zweige und die Rücknahme einzelner Änderungen. Das Repository ist zugleich die Übergabe – der komplette Stand liegt darin und nicht auf einem einzelnen Rechner.

  • GitLab

    Repository-Plattform mit Merge Requests, Pipelines und Aufgabenverwaltung an einem Ort. Praktisch, weil Diskussion, Prüfung und Auslieferung nicht auf drei Werkzeuge verteilt sind.

  • Code Reviews

    Zweiter Blick vor dem Zusammenführen – im Solo-Projekt als strukturierter Durchgang anhand des Diffs. Die meisten Fehler fallen beim Lesen auf, nicht beim Schreiben.

  • Figma

    Gemeinsamer Ort für Entwürfe und Abstimmung. Ich setze Vorlagen daraus um und melde zurück, wo Angaben fehlen: Verhalten bei langen Texten, leeren Listen oder Fehlern.

  • Testing

    Automatisierte Tests für die Teile, deren Ausfall wehtut: Berechnungen, Berechtigungen, Schnittstellen. Nicht jede Zeile braucht einen Test – aber alles, was still falsch sein kann.

// auswahl

Wonach ich auswähle

  1. 01

    Was passiert, wenn es bricht?

    Der Umfang an Tests richtet sich danach, was ein Fehler kostet. Bei Zahlungen und Berechtigungen mehr, bei einer Textseite weniger.

  2. 02

    Wie viele Hände arbeiten daran?

    Je mehr Beteiligte, desto mehr zahlt sich ein formalisierter Ablauf aus. Allein genügt ein leichterer – aber nicht gar keiner.

  3. 03

    Bleibt es nach der Übergabe bedienbar?

    Werkzeuge, die nur ich bedienen kann, verschieben das Problem nach hinten. Der Ablauf muss dokumentiert und ohne mich fortführbar sein.

// faq

Häufige Fragen

Bekomme ich Zugriff auf das Repository?

Ja. Der Code liegt in einem Repository, auf das du Zugriff bekommst – damit ist der komplette Stand samt Verlauf jederzeit bei dir und nicht nur bei mir.

Wird alles getestet?

Nein, das wäre auch nicht wirtschaftlich. Getestet wird, was still falsch sein kann: Berechnungen, Berechtigungen, Schnittstellen und Abläufe, die nicht offensichtlich scheitern.

Arbeitest du mit bestehenden Abläufen?

Ja. Wenn ein Team bereits mit GitHub, Jira oder einem eigenen Ablauf arbeitet, füge ich mich ein, statt eine zweite Welt daneben aufzumachen.

// passend dazu

Wo das zum Einsatz kommt

Passt das zu deinem Vorhaben?

Welche Technologie sinnvoll ist, ergibt sich aus dem Vorhaben – nicht andersherum. Beschreib kurz, was entstehen soll; du bekommst eine Einschätzung dazu, was dafür passt und was nicht.

// weitere

Weitere Bereiche