Refactoring and Technical Debt

Transcript

1. REFACTORING das  Warum  und  das  Wie
2. 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  Aficionando Autoren  der  Präsenta9on
3. Literatur Empfehlungen
4. Legacy Code Legacy  Anwendungen  fangen  als  kleine   Pflanze  an,  wachsen  über  die  Zeit,   entwickeln  Zweige,  Äste  und  Wurzeln   und  irgendwann  kann  man  sie  nicht   mehr  stutzen. Ơ
5. 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.
6. 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
7. 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.
8. 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.
9. Aus welcher Küche schmeckt das Essen? Kurzes  Quizz Saustall Sterile 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.
10. 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 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.
11. 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  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
12. Refactoring If  it  s9nks,  change  it   Gradma  Beck  on  diapers
13. Was suchen wir? Eine  geeignete  Refactoring  Methode   Um  unsere  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.
14. 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.
15. 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 DŽ
16. 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.  
17. 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 DŽ
18. 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.
19. 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 DŽ
20. 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.
21. 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  Greenfield  Ansatz  erlaubt  es  neue  Designs   und  Technologien  zu  verwenden. Risikosteuerung Tempo Mäch9gkeit DŽ
22. 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
23. 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.
24. Legacy Refactoring Für  Wunder  muss  man  beten,  für   Veränderungen  aber  arbeiten.
 Thomas  von  Aquin
25. 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.
26. 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!
27. 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   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
28. 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 DŽ
29. 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
30. 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
31. 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.” “ ”
32. 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  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
33. Danke…