Home Blog Schneller Feedback-Zyklus bei der Software-Entwicklung

Schneller Feedback-Zyklus bei der Software-Entwicklung

Feedback-Zyklus

Bei der Produktentwicklung halten wir einen kurzen Feedback-Zyklus für beinahe unerlässlich.

Bei der Software-Entwicklung ist dieses Feedback auch sehr wichtig.

Feedback-Zyklus bedeutet, dass der Handelnde das Ergebnis seines Handelns bewerten kann, um daraus zu lernen und gegebenenfalls auf andere Handlungsoptionen zu schließen.

Im Bereich der Software-Entwicklung bedeutet das, dass die Wirkung einer Quellcode-Änderung im Produkt gesichtet und bewertet wird. Je flinker der Autor also die Effekte und Seiteneffekte im Produkt bewerten kann, desto besser kann er das Ergebnis seines Handelns bewerten.

Es ermöglicht Experimente, Fehler-Analyse und schnelle Implementierung neuer Features.

Es gibt ein paar Regeln, die diesem Feedback-Zyklus zu optimaler Funktion verhelfen.

 

Die Applikation läuft lokal

Ein gelegentlich angetroffenes Anti-Pattern, ist ein Software-Entwicklungs-Workflow der dem folgenden gleicht:

  • die Entwickler erstellen Änderungen im Quellcode,
  • übertragen diese in die Quellcodeverwaltung (z.B. svn oder git),
  • danach läuft ein Build-Prozess,
  • die Änderung wird auf einem Server eingespielt,
  • erst hier kann der Entwickler die Auswirkung der Code-Änderungen sichten und Bewerten.

Was für ein Zeitverlust!

Die Applikation muss lokal laufen können, so dass der Entwickler seine Änderung schnell lokal prüfen kann.

Jede Änderung ist schnell sichtbar

Um dieses Ziel zu erreichen, müssen ein paar typische Fallstricke umgangen werden:

  • lange Build-Prozesse,
  • lokales Applikation Deployment,
  • der Neustart eines lokalen Servers.

In der Java-Welt ist es manchmal noch der Fall, dass ein Entwickler bei jeder Änderung die Applikation als WAR erneut in einen lokal betriebenen Server deployen muss. Diese Art von Arbeitsprozess kostet zu viel Zeit, und bessere Alternativen, die sehr wohl existieren, müssen eingesetzt werden.

Eine mögliche Alternative ist das dynamische Nachladen der geänderten Klassen der Applikation.

Jede Änderung ist schnell getestet

Eine flinke Bewertung der Code-Änderungen wird essentiell durch automatisierte Tests ermöglicht. Diese Tests prüfen optimaler Weise das gewünschte Verhalten der Applikation aus Anwendersicht ab. Das erstrebenswerte Ziel dieser Tests ist eine kurze Laufzeit bei Abdeckung der wichtigsten Funktionen, die dem Anwender zur Verfügung stehen.

Die Ergebnisse zeigen ja, ob die Änderung etwas kaputt gemacht hat.

 

Praktische Lösungen

mit JavaScript

Mit NodeJS und Grunt kann grunt-watch eingesetzt werden, um Änderungen sofort zu testen und zu deployen.

mit Java/Scala

  • Play Framework

Für Java/Scala Entwickler, ist das beste Tool, das wir kennen, das Play Framework.
Jede Änderung ist sofort hot deployed, sogar Konfiguration- oder Datenbank-Schema-Änderungen.

  • JRebel

Wenn Ihr das Play Framework nicht benutzen könnt, z.B. wenn Eure JEE-Applikation als WAR in einem lokalen Tomcat läuft, empfehlen wir, JRebel einzusetzen. JRebel kann in der Java VM Code live ersetzen. Damit spart man den langen Zyklus „WAR Aufbauen, WAR Deployen“.

  • SBT

Das Play-Framework benutzt das Build-Tool sbt, das auch für andere Java/Scala Projekte eingesetzt werden kann.
SBT ist interaktiv und wird einmal gestartet. Danach kann man solche Befehle eingeben:

~testQuick

Das ~ Zeichen bedeutet, dass SBT auf Dateiänderungen lauscht.
Das Kommando testQuick lässt automatisch alle Tests laufen, die mit der Änderung zu tun haben.
Mit diesem Befehl kann man entwickeln und sieht sofort, ob die Tests grün bleiben oder die letzte Code-Änderung erwartetes Verhalten gestört hat.

Zudem optimiert diese Build-Chain die Build-Dauer durch inkrementelle Builds, wodurch der oben beschriebene Feedback-Loop weiter verkürzt wird.

 

Fazit

Kurze Feedback-Zyklen sind in einer Organisation auf allen Ebenen sehr wichtig. Nur so kann man effizient experimentieren, lernen und bessere Produkte entwickeln. Die Investition in das technische Fundament für kurze Feedback-Zyklen amortisiert sich schon nach den ersten automatisierten Tests bei der Entwicklung neuer Features.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

© by leanovate GmbH - Impressum