Warum?
• Mangelnde Erfahrung
• Entwickler bringen Java, C, PHP, Perl, etc. in
ihren Ruby-Code ein
• Mangelndes Interesse
• “Keine Zeit”
• “Feature-Druck”
Warum?
• Weil Leute immer noch
keine Tests schreiben
• Tests: Oftmals schon der
halbe Weg zum Glück
• Refactoring ohne Tests:
Die Welt des Schmerzes
Eine Geschichte
• Ein Controller
• Er möchte unerkannt bleiben
• Er war die Ausgeburt aller Ängste vor Legacy-
Code
Eine Geschichte
• ~1300 Zeilen
• Für mehrere Wochen auf Abspeckkur
geschickt
• Auf 200 Zeilen, 3 neue Controller, und den
meisten Code ins Model abgeschoben
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
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
Wie?
• Given enough eyeballs, all bugs are shallow.
• And all code will be awesome.
• Nicht immer!
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?
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
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
Code Lesen
• Use the source, Luke
• Notwendiges Übel
• Knowing!
• Con:Verlieren in Details immer zu einfach
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
Subkategorie: Mocks/Stubs
• Pro: Nützlich gegen unliebsame Abhängigkeiten
• Con: Kann zur Sucht, zum Dauerzustand
werden
• Zuviele Mocks verstecken das Wesentliche
• Fantasy Testing
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
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
Technik
• Sollbruchstellen finden
• Dependencies idenfizieren, wenn möglich
aufbrechen
• Sollbruchstellen mit Tests abdecken
• Refactor!
• Rinse and repeat
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.
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
Technik in Rails
• Dependencies von Controllern nicht vergessen
• Views
• Helper
The Enterprise Way
• Versteck den Legacy-Code hinter noch mehr
Legacy-Code
• ESB
• SOA
• EAI
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
Refactoringchen
• Refactor as you go
• Code der angefasst wird, bekommt Tests
verpasst und wird aufgeräumt
• Sollte selbstverständlich sein
Gezieltes Aufräumen
• Ein dunkle Stelle anpeilen
• Analysieren
• Testen
• Refaktorieren,
• Nochmals testen
• Sinnvoll bei vielen größeren Code Smells
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
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
Wie verkaufen?
• Gar nicht, einfach machen
• Skaliert nicht für große Umbauten
• Hohes Business-Risiko
• Sollte wohl durchdacht sein
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