In 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.
Ein gelegentlich angetroffenes Anti-Pattern ist ein Software-Entwicklungs-Workflow, der dem folgenden gleicht:
Was für ein Zeitverlust! Die Applikation muss lokal laufen können, damit der oder die Entwickler:in die Änderung schnell lokal prüfen kann.
Um dieses Ziel zu erreichen, müssen ein paar typische Fallstricke umgangen werden:
In der Java-Welt ist es manchmal noch der Fall, dass ein:e Entwickler:in 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.
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.
Mit NodeJS und Grunt kann grunt-watch eingesetzt werden, um Änderungen sofort zu testen und zu deployen.
Für Java/Scala Entwickler:innen, ist das beste Tool, das wir kennen, das Play Framework. Jede Änderung ist sofort hot deployed, sogar Konfiguration- oder Datenbank-Schema-Änderungen.
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".
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:
~testQuickDas ~ 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.
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.
Du brauchst Unterstützung in der Softwareentwicklung? Jederzeit gern! Schau einfach mal hier vorbei und vereinbare ein unverbindliches Gespräch mit uns.
Rufen Sie uns an: 030 – 555 74 70 0
