1.
Mein Freund,
der Legacy-Code
Mathias Meyer
Peritor GmbH

2.
self
• Chief Cloud Officer bei Peritor GmbH
• Rubyist
• Asynchronist
• Post-Relationalist
• @roidrage
• http://github.com/mattmatt

3.
Peritor
Ruby on Rails
Deployment
Performance-Tuning/-Reviews
Amazon Web Services
Scaling
http://dailyawswtf.com

4.
Peritor

5.
Es war einmal
• Eine elegante Programmiersprache
• Ein wunderbar einfaches Web-Framework

6.
Es war einmal
+ =

7.
Es war einmal
• Beide erreichten den Mainstream
• Beide wurden von vielen Entwicklern gefunden
• Beide sind keine Garantie für guten Code

8.
Es war einmal
Ruby und Rails im Mainstream = Millionen LOLC*
*LOLC: Lines of Legacy Code

9.
Es war einmal
• Millionen LOLC =
• Legacy-Code ist ein Markt

10.
Legacy-Code?
• Code ohne Tests

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

18.
Legacy-Code?
Legacy-Code in Ruby*
5000000
LOLC LOTC
4500000
4000000
3500000
3000000
2500000
2000000
1500000
1000000
500000
0
1995 2000 2005 2010
* Zahlen frei erfunden

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!

26.
Redmine
• app/controllers/issues_controller.rb:
500 Zeilen, 23.5kb, “Nur” ~1000 Zeilen Tests

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?

28.
Wie?
© http://thisiswhyyourefat.com/

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

31.
Tools?

32.
Tools?
• Refactoring-Tools in Ruby? Nada
• Gesunder Menschenverstand
• Know when to stop

33.
Wie?
• Code-Metriken
• Code Lesen
• Exploratives Testen

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

38.
Too. Many. Mocks.
before(:each) do
@fanout = mock("fanout")
@binding = mock("binding", :subscribe => true)
@queue = mock("queue", :bind => @binding, :publish => true)
@amq = mock("AMPQueue", :queue => @queue, :fanout => @fanout)
@serializer = mock("Serializer", :dump => "dumped_value")
@target = mock("Target of Request")
@reaper = mock("Reaper")
Nanite::Reaper.stub!(:new).and_return(@reaper)
@request_without_target = mock("Request", :target => nil, :token => "Token",
:reply_to => "Reply To", :from => "From", :persistent => true, :identity => "Identity")
@request_with_target = mock("Request", :target => "Target", :token => "Token",
:reply_to => "Reply To", :from => "From", :persistent => true)
@mapper_with_target = mock("Mapper", :identity => "id")
@mapper_without_target = mock("Mapper", :request => false, :identity => @request_without_target.identity)
@cluster_with_target = Nanite::Cluster.new(@amq, 32, "the_identity", @serializer, @mapper_with_target)
@cluster_without_target = Nanite::Cluster.new(@amq, 32, "the_identity", @serializer, @mapper_without_target)
Nanite::Cluster.stub!(:mapper).and_return(@mapper)
end
it "should forward requests with targets" do
@mapper_with_target.should_receive(:send_request).with(@request_with_target, anything())
@cluster_with_target.__send__(:handle_request, @request_with_target)
end

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

49.
Worauf fokussieren?

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

54.
Wie verkaufen?
Management Entwickler

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

59.
Danach
Den Beweis antreten

60.
Danach
• Bugs sind kein Weltuntergang, sie kommen vor
• Wenn man sie schneller fixen kann: Win!

61.
Und dann?

62.
Fin
mathias.meyer@peritor.com