Flexible Architekturen: Mit Handwerkskunst zukunftssichere Systeme bauen

Entwicklungstechniken

Mit der Architekturvision haben wir festgelegt, was sich im Projekt nicht ändern darf. Jetzt müssen wir dafür sorgen, dass sich der Rest tatsächlich leicht ändern lässt. Dazu benötigen wir passende Entwicklungstechniken, und wir müssen für Entkopplung sorgen.

Testgetriebene Entwicklung

Inheränt in agilen Vorgehensweisen ist die Notwendigkeit, existierenden Code zu ändern. Nach jeder Änderung das komplette System manuell zu testen, führt zu stetig wachsenden Testaufwänden. Wir benötigen also eine möglichst hohe Abdeckung durch automatisierte Tests. Richtig durchgeführte testgetriebene Entwicklung (TDD – Test-driven Development) führt aus dem Stand heraus zu einer Testabdeckung von mind. 80 %, in der Regel sogar über 90 %. Eine so hohe Testabdeckung ist durch das nachträgliche Schreiben der Tests faktisch nicht erreichbar. Gleichzeitig erzeugt TDD inkrementell den Softwareentwurf und führt zu zwei unabdingbaren Eigenschaften:

  1. Redundanzfreiheit
  2. Entkopplung

Leider ist TDD nicht so einfach zu erlernen. Es gehört deutlich mehr dazu, als lediglich den Test vor der Implementierung zu erstellen [5], [6]. Es ist ein Perspektivwechsel notwendig. Wir schreiben nicht mehr Tests im klassischen Sinne, sondern ausführbare Anforderungsspezifikationen.

Pair Programming

Code-Reviews sind erwiesenermaßen ein effektives Mittel, um Fehler zu entdecken und die Codequalität zu verbessern [7]. Das klassische Code-Review ist ein nachgelagertes Verfahren zur Qualitätssicherung. Pair Programming zieht das Code-Review in den Entwicklungsprozess hinein und verhindert, dass die typischerweise bei Code-Reviews entdeckten Mängel überhaupt entstehen. Dazu arbeiten zwei Entwickler gemeinsam an einem Rechner an einer gemeinsamen Aufgabe. Die beiden Entwickler sind in einem Dialog, und die Tastatur wechselt häufig (alle paar Minuten) zwischen den Partnern.

Pair Programming erfordert etwas mehr Zeit bei der Entwicklung, liefert aber besseren Code und produziert weniger Fehler [8], [9]. Pair Programming zu erlernen ist für viele Entwickler schwieriger, als es auf den ersten Blick vielleicht erscheint. Wer jahrelang alleine vor sich hin entwickelt hat, tut sich häufig schwer damit, seine Gedanken ständig mit anderen zu teilen. Dazu kommt die unterbewusste Angst, nicht so gut zu sein, wie man selbst glaubt. Ron Jeffries sagt dazu „Du bist nicht so gut wie du glaubst, aber auch nicht so schlecht wie du befürchtest.“

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.