Grundlegende Aspekte für jedes Entwicklungsteam

Typsicherheit

Ich arbeite mit JavaScript und empfehle TypeScript, da es im Projekt statische Typisierung hinzufügt. Beim Refactoring des Codes erhalten wir Fehlerprüfungen während der Kompilierung und können so die Arbeit deutlich vereinfachen. Außerdem kann das Importverhalten von relativen auf absolute Pfade umgestellt werden.

Der Hauptvorteil ist das Refactoring. Das Verschieben von Dateien mit absoluten Importen ist weniger fehleranfällig. Es gibt noch viele weitere Vorteile, auf die ich nicht alle eingehe. Wenn du tiefer in das Thema eintauchen möchtest, findest du hier weitere Informationen.

Codeformatierung

Ein Linter analysiert den Code anhand eines Regelsatzes auf Stil- und Programmierfehler. Dadurch wird der Code für das gesamte Team lesbarer und verständlicher. Außerdem spart dies viel Zeit beim Code-Review. Neben einem Linter hilft Prettier den Code wartungsfreundlicher zu gestalten, indem es standardisiert und automatisch formatiert (mithilfe von Hooks).

Verschwendet keine Zeit mit der Formatierung von Code oder dem Diskutieren über die anzuwendenden Regeln. Wählt eine Vorgabe und macht mit was Wichtigerem weiter.

Testen

Tests sollten (fast) nie weggelassen werden. Es gibt viele gute Testbibliotheken, und Vi Test ist eine hervorragende Option. Weitere Informationen findest du in meinem verwandten Artikel, der Jest und Vi Test vergleicht. Er enthält eine Schritt-für-Schritt-Anleitung zur Einrichtung.

Hooks

Husky ist ein Tool, mit dem wir Skripte ausführen können, bevor wir unseren Code committen oder pushen. Dies ist nützlich für unseren Linter und Formatter. Die Regeln werden automatisch angewendet. Du kannst Git-Hooks direkt und ohne diese Abhängigkeit zu Husky verwenden. Egal, welche Methode, Hauptsache die Regeln werden automatisch angewendet. Weitere Informationen hier.

Entwicklung von Feature-Branchs (Git-Flow)

Die Kernidee dieses Flows ist die Entwicklung aller Features in einem dedizierten Branch. Dieses Set-up besteht aus zwei Branches: „main“ und „develop“. Der „main“-Branch enthält den Produktionscode, während der „develop“-Branch als Integrationszweig für neue Funktionen dient.

Anstatt auf diesen beiden Branches zu arbeiten, werden neue Funktionen auf Feature-Branches entwickelt. Feature-Branches werden basierend auf dem „develop“-Branch erstellt. Diese Feature-Branches sollten nach einem bestimmten Muster benannt werden, z. B. nach dem Muster „feature/-short-description“. So sind sie leicht zu identifizieren.

Sobald ein Feature fertiggestellt ist, wird es per Pull Request in den „develop“-Branch gemergt. Während der Entwicklung auf einem Feature-Branch ist es wichtig, den Feature-Branch regelmäßig mit dem „develop“-Branch zu rebasen, um das Risiko von Merge-Konflikten zu minimieren.

Mehr über den Git-Flow-Workflow und den Feature-Branch-Workflow.

Verständliche Commit-Nachrichten schreiben

Gut geschriebene Commit-Nachrichten sollten einem standardisierten Format innerhalb des Teams folgen. So können alle, die die Codebasis einsehen, die Art der vorgenommenen Änderungen leicht nachvollziehen. Jeder kann nachvollziehen, was vorgefallen ist, ohne die Beschreibung in einem Commit lesen zu müssen.

Der Commit besteht aus vier Teilen:

– Commit-Typ
– Scope des Commits (optional, aber oft wünschenswert)
– Inhalt des Commits
– Optionaler Text für weitere Beschreibungen. Geeignet für größere Commits.

Typ
Du kannst eigene Typen verwenden, aber hier sind die Standards, die für die semantische Versionierung funktionieren:

feat: ein neues Feature oder eine Änderung an einem bestehenden Feature.
fix: Behebung eines Fehlers oder bekannten Problems im Code.
test: Hinzufügen zusätzlicher Tests für bestehende Funktionen.
chore: Aktualisierung von Build-Tools, Aktualisierung von Entwicklungsabhängigkeiten usw.
docs: Aktualisierung der Dokumentation wie „README“

Weiterführende Informationen: The Conventional Commits

Scope
Dies ist ein teaminterner Kontext von Funktionen. Je nach Projekt ist es sinnvoll, Epic-Namen oder Pages innerhalb einer Single-Page-Anwendung zu verwenden.

Der Inhalt
Hier nennst du die Ticketnummer und gibst eine (sehr) kurze Beschreibung des Kontexts an.

Der Text
Hier beschreibst du die Gründe für die Änderung, damit andere Entwickler die Auswirkungen verstehen können.

Ein Beispiel

Eine Commit-Nachricht könnte so aussehen:

feat: #issue-1234 submit button

- feat: add new submit button to sign up form
- test: check if the form can be submitted

Rebasen statt Mergen

Diese Git-Funktion ist praktisch für die Entwicklung von Feature-Branchs. Du kannst Änderungen von einem Branch in einen anderen integrieren. Mit einem Merge erstellst du einen neuen, vorwärtsgerichteten Änderungsdatensatz. Mit Rebase schreibst du den Verlauf neu und verschiebst den Zeitpunkt des Branchings so, als wäre der rebasierte Branch bereits vor Beginn der Feature-Entwicklung vorhanden gewesen. Der Hauptgrund hierfür ist die Aufrechterhaltung eines linearen Projektverlaufs. Hier eine ausführlichere Anleitung zu git rebase und eine Diskussion zu Rebase vs. Merge.

Tagging

Ein Tag ist ein Verweis auf einen bestimmten Commit im Git-Verlauf. Tags erhalten einen Namen. Er kann als Markierung für eine veröffentlichte Version (siehe Semantische Versionierung) dienen. Ein Tag kann sich nicht ändern – er hat keine Commit-Historie. Es gibt zwei Arten von Tags: einfache und kommentierte Tags.

Einfache Tags sind wie Lesezeichen. Ähnlich wie Commit-Nachrichten enthalten kommentierte Tags den Namen des Taggers, die E-Mail-Adresse, das Datum und eine Nachricht, die das Änderungsprotokoll einer bestimmten Version enthalten kann. Weitere Informationen hier.

Semantische Versionierung verwenden

Semantische Versionierung, auch „SemVer“ genannt, ist ein Standard, der die Struktur der Versionsnummer definiert. Sie besteht aus drei Teilen: „Major.Minor.Patch“.

Major wird bei wichtigen Änderungen hochgezählt.
Minor wird hochgezählt, wenn Funktionen abwärtskompatibel hinzugefügt werden.
Patch wird bei abwärtskompatiblen Fixes hochgezählt.

Semantische Versionierung hilft uns, Drittanbietercode zuverlässig zu nutzen. Wenn wir eine externe Bibliothek hinzufügen, definieren wir die zu verwendende Version. Wir haben verschiedene Möglichkeiten, den zulässigen Versionsbereich für Abhängigkeitsaktualisierungen festzulegen:

– Ohne Präfix definieren wir die genaue Version.
– Das Caret-Zeichen ^ ermöglicht kleinere Updates und Patch-Updates.
– Das Tilde-Zeichen ~ ermöglicht nur Patch-Updates.

Abschließende Gedanken

Im Artikel diskutiere ich einige allgemeine Aspekte der Programmierung. Mein wichtigster Punkt ist, Dinge zu automatisieren und sich nur mit relevanten Aspekten zu befassen. Entwickler und ihre Tools sollten sich in erster Linie auf die Entwicklererfahrung (Developer Experience) und in zweiter Linie auf die Produktivität konzentrieren. Wenn eine Änderung, ein Tool oder eine Vereinbarung die Freude an der Arbeit steigern, würde ich dies wichtiger einstufen als die Produktivitätssteigerung.