in Integra9onslösungen und Java Front-‐Ends Stefan Siprell Java Guy Apache Member, Karaf Contributor, Integra9ons Experte A. Nierbeck Open-‐Source & OSGI Aficionando Autoren der Präsenta9on
als die langfris9ge Wartbarkeit der SoVware, schleichen sich SoVware Schulden in das System. Tilgt man diese Schulden nicht, werden die Auswirkungen immer deutlicher.
etwas nicht final zu Ende zu bringen und belasten damit zukünVige Entwicklungen. Technische Es wird immer schwieriger die technische und funk9onale Korrektheit der Anwendung zu verifizieren. Qualitative Integra9on und Ausliefern der Anwendung wird immer riskanter, komplexer und fehleranfälliger. Konfigurative Es ist aufwendiger neue Funk9onen einzubauen, als die Komponente neu zu schreiben. Design Die Verfügbarkeit von geeigneten Personen an einer Pla\orm zu arbeiten nimmt ab und wird teurer. Plattform
Next Generation Experten Schwund Instabile Releases Unbezahlbare Tests Wir schreiben die Anwendung neu indem wir alte Funk9onen auf eine Technologie kopieren. Es wird immer schwieriger und teurer Experten zu ersetzen, so dass der Ausfall von Individuen das Unternehmen existenziell bedrohen kann. Releases erzeugen unverhältnismäßig Fehler und ziehen Ke_en von Folgereleases nach sich -‐ jedes Release benö9g ein Team an Scoaes. Die Kosten der Regressionstests sind nicht mehr bezahlbar, werden immer weiter reduziert, was den AuXau von Schulden weiter beschleunigt.
3 5 8 10 1 2 3 4 5 Geplante Funk9onen Gelieferte Funk9onen Geplante Funktionen Sobald ein bes9mmter Wert an Lieferfähigkeit unterschri_en wird, wird das Business sehr aggressiv reagieren. In der Regel werden damit die Schulden aber nicht abgebaut. Gelieferte Funktionen Die ersten Probleme kann man mit Überstunden kompensieren -‐ sobald das Poten9al aufgebraucht ist, rauscht die Lieferleistung in den Keller. Vorher gibt es keine BereitschaV die Schulden abzubauen.
Küche Kreative Chaos Alles liegt lose herum, jeder Griff kann etwas zum Einstürzen bringen. Man möchte die Küche gar nicht erst betreten. Alles ist so sauber und aufgeräumt, dass nichts grikereit ist und man sich nicht mal traut etwas anzufassen. Alles ist Grikereit, die Kollegen sind eingespielt und man nimmt sich Zeit zum Aufräumen wenn es notwendig ist.
besser Software Schulden Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Unkontrolliert Phasen Keine Schulden DŽ Unkontrolliertes Wachstum SoVware Schulden wachsen, bis das Business sich nicht mehr mit der SoVware beschäVigen möchte. Schuldenzyklus Sta_dessen sollte man die Schulden durchaus im Gefecht entstehen lassen, aber regelmäßig diese Schulden überwachen und abbauen. ◦ Keine Schulden Reflexar9g werden die Entwickler versuchen hoch strukturiert zu arbeiten und überhaupt keine Schulden mehr zu erlauben. Damit würgt man gleichzei9g die Lieferfähigkeit neuer Funk9onen ab.
02 03 04 In der Retrospek9ve besprechen wir auch die Schulden, speziell solche welche uns weh tun. Scrum Retrospektive Wir definieren uns weiterhin darüber, dass wir Funk9onen für das Business liefern. Allerdings können wir in ruhigeren Zeiten unsere SoVware wieder aufräumen, damit wir in der nächsten Phase gut gerüstet sind. Mix für den Sprint festlegen Neue Funk9onen werden geliefert und alte Funk9onen werden nachhal9g verbessert. Lieferung Entsprechend der verfügbaren Entwickler und deren Aufgaben wird das Backlog für den Sprint befüllt. Scrum Planung Gute Basis sind 5 Entwickler für neue Funk9onen und 2 für Schuldenabbau
Schulden abzubauen werden wir sehr häufig exis9erenden Code anfassen müssen, um die gleichen Funk9onen “besser" zu liefern. Besserer Code kann bedeuten, dass er testbarer wird, dass er sich besser integrieren lässt, dass obsolete Technologien ersetzt werden, oder dass neue Funk9onen sich leichter integrieren lassen. Im Prinzip suchen wir eine Refactoring Methode, mit der sich aus dem TagesgeschäV die Schulden inkrementell abbauen lassen.
Punkt dieses Vorgehens ist zuerst die Herstellung von Testbarkeit und dann eines Test Harnesses für den zu testenden Code. Erst wenn dieses besteht, werden Veränderungen am Code (und parallel dem Test Harness) durchgeführt Bei mangelnder Testabdeckung oder Testbarkeit*) der Anwendung ist dieses Vorgehen jedoch mit viel Zeit und Aufwand für die vorgelagerte Aufgaben behaVet. Leider entsteht in diesem Zeitraum kein sichtbarer Nutzen. *) Testbarkeit bezieht sich auf Abdeckung der genutzten Komponenten / Units nicht unbedingt auf LoC.
Code arbeitet, ist das Risiko gering. Wenn die Vorarbeiten aber die Sprints sprengen, entsteht ein implizites Risiko. Da nur unter idealen Umständen keine vorgelagerten Aufwände notwendig sind, ist die Geschwindigkeit eher gering. Sobald ein Modul testbar ist, kann jede Art von Refactoring vorgenommen werden. Risikosteuerung Tempo Mäch9gkeit DŽ
Übersicht Auf Basis einer neuen Zielarchitektur wird die Anwendung vollständig neu geschrieben. Bei Vorhandensein einer vollständigen Funk9onsbeschreibung der Altanwendung, kann dies sofort geschehen. Falls nicht, müssen aus dem Quelltext / Live-‐Betrieb die Anforderungen nachträglich gewonnen werden. Auf Basis der Architektur und den Anforderungen wird das System neu entwickelt. Neben dem Risiko der eigentlichen Entwicklung, der neuen Konzepte und der unvollständigen Anforderungen gibt es ein großes Risiko bei der Migra9on der Umsysteme und der eigenen Daten.
alten Umsysteme und Daten müssen migriert werden. Es ist kein unmi_elbarer Nutzen für den Kunden vorhanden, bis die Gesamte Anwendung deployed wurde und die alte ersetzt. Mit dem Verzicht auf Kompa9bilität und der Einführung einer neuen Architektur ist alles möglich. Risikosteuerung Tempo Mäch9gkeit DŽ
Methoden Übersicht Code kann beim Entwickeln zufällig gefunden werden oder es kann auch automa9siert und systema9sch nach solchen Stellen gesucht werden. Wie üblich wird geprüV, ob genügend Tests vorhanden sind. Falls notwendig werden zusätzliche Tests definiert, bevor man mit dem Umbau anfängt. Das Bo_om-‐Up Vorgehen eignet sich gut als integriertes Werkzeug, um langfris9g arbeitsintegriert eine höhere Codequalität zu erreichen. Durch Werkzeuge wie Sonar und eine strenge „Defini9on of Done“ kann diese Technik für kleinere Bereiche auch problemlos in das tägliche Arbeiten eines Scrumteams integriert werden.
Fragmenten arbeitet ist das Risiko gering. Die lokale Arbeitsweise kann zu sehr schnellen Ergebnissen führen. Aufgrund der Lokalität ist es sehr schwierig Design oder Infrastruktur zu ändern. Risikosteuerung Tempo Mäch9gkeit DŽ
Mikado Methoden Übersicht Speziell geschaffen für Codebasen in denen Zusammenhänge unbekannt sind, aber konkrete Anforderungen an das Refactoring gestellt werden. Nach diesem Vorgehen wird zuerst die Business Anforderung direkt und naiv umgesetzt. Der erste Code wird dem Product Owner gezeigt. Alle unvollständigen, falschen und fehlenden Anforderungen werden als Mängel iden9fiziert. Im nächsten Schri_ werden dann die Änderungen umgesetzt. Schnell sind erste Ergebnisse sichtbar, allerdings ist das Ende in der Tat nicht absehbar.
kommt, ist es schwer vorherzusehen wann das Refactoring erfolgreich war. Die naive Vorgehensweise erlaubt es schnell erste Resultate zu liefern. Der Greenfield Ansatz erlaubt es neue Designs und Technologien zu verwenden. Risikosteuerung Tempo Mäch9gkeit DŽ
das größte Risiko, während Bo_om-‐Up und Test Driven sehr konserva9v sind. Tempo Big Bang lässt zu lange auf sich warten, während Mikado zwar sehr schnell die Ergebnisse liefert, aber nicht unbedingt die rich9gen. Bo_om-‐Up und Test-‐ Driven liefern akzeptable Ergebnisse. Mächtigkeit In der Mäch9gkeit liegen die meisten Tools in der gleichen Klasse, außer Bo_om-‐Up, welches aufgrund der Arbeitsweise nur sehr kleine Änderungen erlaubt. Test Driven Big Bang Bo3om Up Mikado
Tempo an den Tag zu legen, macht es wenig Sinn Tests für den Legacy Code zu schreiben, die sowieso wieder rot werden -‐ abgesehen davon wird der meiste Code nicht verwendet. Um das Risiko zu reduzieren, dürfen nur inkrementell Teile der Anwendung ausgetauscht werden und es muss immer wieder kurzfris9g Feedback eingeholt werden. Die Mäch9gkeit ist nur zu erreichen, in dem man komple_ losgelöst vom alten Source Code arbeitet.
Kronen australischer Feigenbäumen. Die Pflanze lässt ihre Wurzeln bis auf den Boden runter wachsen und umhüllt dann die Wirtspflanze mit eigenen Trieben, Ästen, Zweigen und Wurzeln. Dabei s9rbt der eigentliche Baum und die Schmarotzer-‐ Pflanze kann nun alleine überleben. Der Vorgang ist inkrementell, umhüllt den Baum ohne Kenntnisse über dessen interne Strukturen zu haben und ersetzt den Baum erst dann vollständig, wenn der Wirt nicht mehr benö9gt wird -‐ Perfekt!
führt Herrsche Herrsche Einzelne Domänen / Assets werden nun führend in einem neuen System gepflegt. Erwünschte Manipula9onen aus der Alt-‐Anwendung kommen über die Event Intercep9on an, unter Umständen müssen Daten auch zurückgespielt werden. Siehe Fowler: Asset Capture Befriede Wurden alle Assets aus der Legacy Anwendung extrahiert, kann der übrig gebliebene “Glue Code” einfach zu einer schlanken Lösung refactored werden. Teile Teile Einzelne Funk9onen werden aus der alten Anwendung herausgelöst. Dies kann auf der DB-‐, Service-‐ oder idealerweise auf der Message-‐Schicht sein. Die Funk9onsaufrufe werden durch ein externes System bedient, und ein Rollback auf die Ursprungsfunk9on ist gegeben. Siehe Fowler: Event Intercep9on
Strangling Applica9on inkrementell erstellt wird und per Feature Flags einzelne Funkionen übernehmen oder wiedergeben kann. Sehr schnell können erste Ergebnisse gewonnen werden, da immer nur einzelne Teile ersetzt werden. Hierdurch ist sichergestellt, dass das Ergebnis auch sofort in Produk9on kann. Die Aufrufseman9k und Datenmodellierung muss eine Zeitlang rückwärtskompa9bel zur Legacy Anwendung bleiben, kann aber immer mehr vernachlässigt werden. Risikosteuerung Tempo Mäch9gkeit DŽ
und baut nicht den Legacy Code nach! Fragen vs Annahmen Denkt an das krea9ve Chaos und liefert mit einem Team erste neue Funk9onen und keine Versprechen! Poli9k? Ist auch nur eine Anforderung! Action vs Conversation Auch wenn das Refactoring mehrere Sprints benö9gt: Liefert nach jeder Itera9on in eine Pre-‐Live mit Produk9onsdaten und -‐requests! Damit wird auch ohne fachlichen Input zumindest die Funk9onsfähigkeit getestet. Test vs Produktion „Refactoring macht Spass.” -‐ Erzählt es den Kollegen! Fun vs Work
Boot, OSGI oder auch JEE um neue Funk9onalität aufzunehmen. Diese lassen sich leicht erweitern, gut deployen und eignen sich für agile Entwicklung. Micro Services Idealer Träger der neuen Anwendung
02 03 04 In der Retrospek9ve besprechen wir auch die Schulden, speziell solche welche uns weh tun. Scrum Retrospektive Wir definieren uns weiterhin darüber, dass wir Funk9onen für das Business liefern. Allerdings können wir in ruhigeren Zeiten unsere SoVware wieder aufräumen, damit wir in der nächsten Phase gut gerüstet sind. Mix für den Sprint festlegen Neue Funk9onen werden geliefert und alte Funk9onen werden nachhal9g verbessert. Lieferung Entsprechend der verfügbaren Entwickler und deren Aufgaben wird das Backlog für den Sprint befüllt. Scrum Planung Gute Basis sind 5 Entwickler für neue Funk9onen und 2 für Schuldenabbau
stefan79
yug1224
o0h
cockscomb
youkidearitai
hollycummins
nrslib
tonkotsuboy_com
mogamit
manfredsteyer
suikabar
terryu16
jnunemaker
nonsquared
geshan
matthewcrist
garrettdimon
michaelherold
eileencodes
addyosmani
denniskardys
chriscoyier
twada
