Refactoring and Technical Debt

Slide 1

Slide 1 text

REFACTORING das Warum und das Wie

Slide 2

Slide 2 text

Wer wir sind. Architekt seit über 15 Jahren, Schwerpunkte in Integra9onslösungen und Java Front-‐Ends Stefan Siprell Java Guy Apache Member, Karaf Contributor, Integra9ons Experte A. Nierbeck Open-‐Source & OSGI Aﬁcionando Autoren der Präsenta9on

Slide 3

Slide 3 text

Literatur Empfehlungen

Slide 4

Slide 4 text

Legacy Code Legacy Anwendungen fangen als kleine Pﬂanze an, wachsen über die Zeit, entwickeln Zweige, Äste und Wurzeln und irgendwann kann man sie nicht mehr stutzen. Ơ

Slide 5

Slide 5 text

Software Schulden Wird die kurzfris9ge Lieferfähigkeit stets höher bewertet als die langfris9ge Wartbarkeit der SoVware, schleichen sich SoVware Schulden in das System. Tilgt man diese Schulden nicht, werden die Auswirkungen immer deutlicher.

Slide 6

Slide 6 text

Schuldarten Wo sich Schulden auXauen ƃ Ư Entwickler beschließen 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

Slide 7

Slide 7 text

Reaktionen auf Schulden Welche Auswirkungen SoVware Schulden auf Unternehmen haben. 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.

Slide 8

Slide 8 text

Erwartungen und Leistungen SoVware Schulden legen die Entwicklung lahm 0 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.

Slide 9

Slide 9 text

Aus welcher Küche schmeckt das Essen? Kurzes Quizz Saustall Sterile Küche Kreative Chaos Alles liegt lose herum, jeder Griﬀ 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.

Slide 10

Slide 10 text

Wir wollen ein kreatives Chaos Weniger Entropie ist nicht immer besser Software Schulden Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Unkontrolliert Phasen Keine Schulden Ǆ 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.

Slide 11

Slide 11 text

Ad-Hoc Schuldenabbau SoVware Schulden abbauen und fachliches Vermögen erwirtschaVen 01 02 03 04 In der Retrospek9ve besprechen wir auch die Schulden, speziell solche welche uns weh tun. Scrum Retrospektive Wir deﬁnieren 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

Slide 12

Slide 12 text

Refactoring If it s9nks, change it Gradma Beck on diapers

Slide 13

Slide 13 text

Was suchen wir? Eine geeignete Refactoring Methode Um unsere Schulden abzubauen werden wir sehr häuﬁg 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.

Slide 14

Slide 14 text

Tests anlegen Refactoring Test Driven Refactoring Methoden Übersicht Der zentrale 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.

Slide 15

Slide 15 text

Test Driven Refactoring Bewertung Da man sehr eng am bestehenden 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 Ǆ

Slide 16

Slide 16 text

Zielarchitektur bes5mmen Anforderungen festlegen System bauen Migra5on Big Bang Methoden Ü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.

Slide 17

Slide 17 text

Big Bang Bewertung Es wird alles neu geschrieben und die 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 Ǆ

Slide 18

Slide 18 text

Smelly Code iden5fizieren Absichern durch Tests Lokale Op5mierung Bottom Up 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.

Slide 19

Slide 19 text

Bottom Up Bewertung Da man immer nur an sehr kleinen 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 Ǆ

Slide 20

Slide 20 text

1. naive Umsetzung Abnahme Versuch Mängel Iden5fika5on 2. Umsetzung, etc. 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.

Slide 21

Slide 21 text

Mikado Bewertung Sogar wenn regelmäßig und kurzfris9g geschäVliches Feedback kommt, ist es schwer vorherzusehen wann das Refactoring erfolgreich war. Die naive Vorgehensweise erlaubt es schnell erste Resultate zu liefern. Der Greenﬁeld Ansatz erlaubt es neue Designs und Technologien zu verwenden. Risikosteuerung Tempo Mäch9gkeit Ǆ

Slide 22

Slide 22 text

Vergleich Wie schneiden die Methoden ab? Risikosteuerung Big Bang birgt 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

Slide 23

Slide 23 text

Der Wunsch-Mix Wir sind fast da! Wir suchen weiterhin nach einer geeigneten Refactoring Methode. Mit einer Mäch9gkeit wie Big Bang, einem Mikado Tempo und dem geringen Risiko des Test-‐Driven Refactoring.

Slide 24

Slide 24 text

Legacy Refactoring Für Wunder muss man beten, für Veränderungen aber arbeiten.  Thomas von Aquin

Slide 25

Slide 25 text

Die Herausforderung Wie müssen wir agil refactoren? Um ein entsprechendes 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.

Slide 26

Slide 26 text

Strangling Application Die Lösung Eine Strangling Vine wächst in den 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!

Slide 27

Slide 27 text

Befriede Anwendung Strangling Application Wie die Strangling Applica9on zum Erfolg führt Herrsche Herrsche Einzelne Domänen / Assets werden nun führend in einem neuen System gepﬂegt. 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

Slide 28

Slide 28 text

Strangling Application Bewertung Das Risiko ist sehr gering, da die 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 Ǆ

Slide 29

Slide 29 text

Tipps und Tricks! Fragt Anwender nach der gewünschten Lösung 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

Slide 30

Slide 30 text

Ausblick Technologien Nutzt Pla\ormen wie Spring 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

Slide 31

Slide 31 text

Los Geht’s Kein Grund nicht anzufangen Dr Seuss Author “If things start happening, don't worry, don't stew, just go right along and you'll start happening too.” “ ”