SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
11.
Legacy-Code?
• Stuff that other people wrote.
http://www.c2.com/cgi/wiki?LegacyCode
12.
Legacy-Code?
• Technical Debt
Niedrige Kosten/Aufwand am Anfang, im Laufe
der Zeit steigend
13.
Legacy-Code?
• Code der in Production ist.
(Mathias Meyer, 2009)
14.
Legacy-Code?
• Ergo:
Code den ihr tagtäglich produziert.
15.
Legacy-Code?
• Code den keiner gern anfässt.
• Code der schwer zu ändern ist.
• Code der fehleranfällig ist.
• Code der stetig verschlimmbessert wird.
16.
Legacy-Code?
• Änderungen werden mit der Zeit exponentiell
teurer
• Änderungen führen zu mehr Bugs
• Änderungen brechen existierenden Code
17.
Legacy-Code?
• Negativ vorbelastet
• Riesige Codewürste, unstrukturiert, ungetestet
• Sch***code
• Code-Smells ist noch gelinde ausgedrückt
• Broken-Windows passt schon eher
19.
Warum?
• Mangelnde Erfahrung
• Entwickler bringen Java, C, PHP, Perl, etc. in
ihren Ruby-Code ein
• Mangelndes Interesse
• “Keine Zeit”
• “Feature-Druck”
20.
Warum?
• Weil Leute immer noch
keine Tests schreiben
• Tests: Oftmals schon der
halbe Weg zum Glück
• Refactoring ohne Tests:
Die Welt des Schmerzes
21.
Eine Geschichte
• Ein Controller
• Er möchte unerkannt bleiben
• Er war die Ausgeburt aller Ängste vor Legacy-
Code
22.
Eine Geschichte
• ~1300 Zeilen
• Für mehrere Wochen auf Abspeckkur
geschickt
• Auf 200 Zeilen, 3 neue Controller, und den
meisten Code ins Model abgeschoben
23.
Das will ich auch!
• Legacy-Code muss nichts schlechtes sein
• Auch wenn er so aussieht
• Legacy-Code kann schlimm aussehen, aber es
liegt an euch wie ihr ihn hinterlasst
• TODOs im Code vermeiden, lieber fixen
24.
Wie?
• Offensichtliches
• Test all the fucking time, as much and as
widely as you can
• Refactor like a pr0n star
• Pair a lot of the time
• Agile, XP, Scrum, oh my!
• Man kann es nicht oft genug sagen
25.
Wie?
• Given enough eyeballs, all bugs are shallow.
• And all code will be awesome.
• Nicht immer!
27.
Wie?
• Wie gehe ich mit solchem Code um?
• Wie gehe ich ein Refactoring an?
• Wie ziehe ich eine Test-Suite auf?
• Wie rechtfertige ich große Änderungen?
29.
Halbwahrheiten
• Der große Wurf wird nicht auf einmal gelingen
• Ein großes Refactoring einplanen ist der Weg
ins Verderben
• Stetige Verbesserung ist der Weg der Weisen
30.
Wie?
• Know your enemy, because knowing is half the battle
34.
Code-Metriken
• Mit Statistiken stark riechende Stellen finden
• Hohe Signal-Noise-Ratio
• Zu einfach den Fokus zu verlieren
• Einzig nützlich: Test-Coverage als Peildaumen
35.
Code Lesen
• Use the source, Luke
• Notwendiges Übel
• Knowing!
• Con:Verlieren in Details immer zu einfach
36.
Exploratives Testen
• Spezifische Teile des Codes mit Tests abdecken
• Zeile für Zeile, Feature für Feature
• Pro: Test-Suite wächst und ist bereit zum
Refactoring
• Sehr hoher Lerneffekt, viele Wtf-Momente
garantiert
37.
Subkategorie: Mocks/Stubs
• Pro: Nützlich gegen unliebsame Abhängigkeiten
• Con: Kann zur Sucht, zum Dauerzustand
werden
• Zuviele Mocks verstecken das Wesentliche
• Fantasy Testing
39.
Parallele Welten
• Notfallwaffe
• Code auseinandernehmen und parallel neu
aufbauen (aus existierendem)
• Ja, zuerst auch ohne Tests, wenn’s sein muss
• Test-Suite aufbauen mit den verschobenen
Code-Teilen
• Eltern haften für ihre Kinder
40.
Test-Suite Aufbauen
• Jetzt? Ja!
• Für die ganze Code-Basis? Nein!
• Klein anfangen,Vorher Hände waschen!
• Tests schreiben für Funktionalität die durch
neue Features zerbrechen kann
• Skaliert nicht bei großen Geschwüren
41.
Technik
• Sollbruchstellen finden
• Dependencies idenfizieren, wenn möglich
aufbrechen
• Sollbruchstellen mit Tests abdecken
• Refactor!
• Rinse and repeat
42.
Technik in Rails
• RESTful als Guideline, nicht als Mantra
• Controller aufbrechen
• Zuviele Actions bedeuten zuviele potentielle
Ressourcen
• Code raus aus den Controllern, sie müssen
dumm sein
• resource_controller, make_resourceful, etc.
43.
Technik in Rails
• Tests von oben nach unten
• Controller-Tests decken das wichtigste ab
• Views nicht vergessen
• Unit-Tests sollten daraus entstehen
• Models != ActiveRecord
• Neue Models braucht das Land
44.
Technik in Rails
• Dependencies von Controllern nicht vergessen
• Views
• Helper
45.
The Enterprise Way
• Versteck den Legacy-Code hinter noch mehr
Legacy-Code
• ESB
• SOA
• EAI
46.
SOAESBEAIOMGWTF!
• SOA: Legacy-Code as a Service
• Wenn schon, dann eine einfache REST-API
• Legacy-Code wird z.B. zum Web-Service
47.
SOAESBEAIOMGWTF!
• EAI: Enterprise Application Integration
• Versteckt Code hinter Messaging-Backends
• Dröger Name, großer Effekt
• Entkoppelt alten von neuem Code
• Erspart nicht das Refactoring, macht es aber
potentiell einfacher
48.
SOAESBEAIOMGWTF!
• ESB: Enterprise Service Bus
• ESB = EAI + SOA + XML + OMG + Magic
• Unentdecktes Land unter Rubyists
50.
Refactoringchen
• Refactor as you go
• Code der angefasst wird, bekommt Tests
verpasst und wird aufgeräumt
• Sollte selbstverständlich sein
51.
Gezieltes Aufräumen
• Ein dunkle Stelle anpeilen
• Analysieren
• Testen
• Refaktorieren,
• Nochmals testen
• Sinnvoll bei vielen größeren Code Smells
52.
The Big Refactoring
• Sowas wie ein Big Refactoring existiert nicht
• Refactoring ist ein Prozess
• In jeder Iteration Zeit einplanen zum
Aufräumen alten Codes, mit spezifischem Ziel
• Aber: Es ist eine Alternative
53.
The Big Rewrite
• Beliebt bei Entwicklern
• Unbeliebt beim Management, zu Recht
• Funktioniert so gut wie nie
• Oftmals voller Stop der Entwicklung
• Kulmuliert neuen Legacy-Code
• Ergebnis bleibt meist weit hinter Erwartungen
zurück
55.
Wie verkaufen?
• Management: Wir
brauchen mehr
Features
• Entwickler: Wir
brauchen mehr Zeit
zum aufräumen
56.
Wie verkaufen?
• Das klassische Vorurteil
• Es gibt auch einen Mittelweg
57.
Wie verkaufen?
• Gar nicht, einfach machen
• Skaliert nicht für große Umbauten
• Hohes Business-Risiko
• Sollte wohl durchdacht sein
58.
Wie verkaufen?
• Argumente sammeln
• Code-Änderungen werden teurer
• Neue Features fließen langsamer
• Leidenschaftlich, aber nicht trotzig, Konsens
ist trotzdem wichtig
• Wenn gar nichts mehr geht, Notbremse
ziehen