Mein Freund Der Legacy Code

download Mein Freund Der Legacy Code

of 64

  • date post

    29-Jun-2015
  • Category

    Technology

  • view

    2.803
  • download

    2

Embed Size (px)

description

Slides (in German) from my talk on legacy code at the German Rails-Konferenz.

Transcript of Mein Freund Der Legacy Code

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

2. self Chief Cloud Ofcer bei Peritor GmbH Rubyist Asynchronist Post-Relationalist @roidrage http://github.com/mattmatt 3. PeritorRuby on Rails DeploymentPerformance-Tuning/-Reviews Amazon Web ServicesScalinghttp://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 fr 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 tagtglich produziert. 15. Legacy-Code? Code den keiner gern anfsst. Code der schwer zu ndern ist. Code der fehleranfllig ist. Code der stetig verschlimmbessert wird. 16. Legacy-Code? nderungen werden mit der Zeit exponentiell teurer nderungen fhren zu mehr Bugs nderungen brechen existierenden Code 17. Legacy-Code? Negativ vorbelastet Riesige Codewrste, unstrukturiert, ungetestet Sch***code Code-Smells ist noch gelinde ausgedrckt Broken-Windows passt schon eher 18. Legacy-Code? Legacy-Code in Ruby*5000000LOLCLOTC45000004000000350000030000002500000200000015000001000000 5000000 199520002005 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 nochkeine Tests schreiben Tests: Oftmals schon derhalbe Weg zum Glck Refactoring ohne Tests:Die Welt des Schmerzes 21. Eine Geschichte Ein Controller Er mchte unerkannt bleiben Er war die Ausgeburt aller ngste vor Legacy- Code 22. Eine Geschichte ~1300 Zeilen Fr 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 xen 24. Wie? Offensichtliches Test all the fucking time, as much and aswidely 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 groe nderungen? 28. Wie? http://thisiswhyyourefat.com/ 29. Halbwahrheiten Der groe Wurf wird nicht auf einmal gelingen Ein groes 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 nden Hohe Signal-Noise-Ratio Zu einfach den Fokus zu verlieren Einzig ntzlich: Test-Coverage als Peildaumen 35. Code Lesen Use the source, Luke Notwendiges bel Knowing! Con:Verlieren in Details immer zu einfach 36. Exploratives Testen Spezische Teile des Codes mit Tests abdecken Zeile fr Zeile, Feature fr Feature Pro: Test-Suite wchst und ist bereit zum Refactoring Sehr hoher Lerneffekt, viele Wtf-Momente garantiert 37. Subkategorie: Mocks/Stubs Pro: Ntzlich gegen unliebsame Abhngigkeiten Con: Kann zur Sucht, zum Dauerzustandwerden 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("TargetofRequest") @reaper=mock("Reaper") Nanite::Reaper.stub!(:new).and_return(@reaper) @request_without_target=mock("Request",:target=>nil,:token=>"Token", :reply_to=>"ReplyTo",:from=>"From",:persistent=>true,:identity=>"Identity") @request_with_target=mock("Request",:target=>"Target",:token=>"Token", :reply_to=>"ReplyTo",: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) endit"shouldforwardrequestswithtargets"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, wenns sein muss Test-Suite aufbauen mit den verschobenen Code-Teilen Eltern haften fr ihre Kinder 40. Test-Suite Aufbauen Jetzt? Ja! Fr die ganze Code-Basis? Nein! Klein anfangen,Vorher Hnde waschen! Tests schreiben fr Funktionalitt die durch neue Features zerbrechen kann Skaliert nicht bei groen Geschwren 41. Technik Sollbruchstellen nden Dependencies idenzieren, wenn mglich 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 mssen 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 mehrLegacy-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 Drger Name, groer 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 aufgerumt Sollte selbstverstndlich sein 51. Gezieltes Aufrumen Ein dunkle Stelle anpeilen Analysieren Testen Refaktorieren, Nochmals testen Sinnvoll bei vielen greren Code Smells 52. The Big Refactoring Sowas wie ein Big Refactoring existiert nicht Refactoring ist ein Prozess In jeder Iteration Zeit einplanen zum Aufrumen alten Codes, mit spezischem 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 zurck 54. Wie verkaufen? Management Entwickler 55. Wie verkaufen? Management: Wirbrauchen mehrFeatures Entwickler: Wirbrauchen mehr Zeitzum aufrumen 56. Wie verkaufen? Das klassische Vorurteil Es gibt auch einen Mittelweg 57. Wie verkaufen? Gar nicht, einfach machen Skaliert nicht fr groe Umbauten Hohes Business-Risiko Sollte wohl durchdacht sein 58. Wie verkaufen? Argumente sammeln Code-nderungen werden teurer Neue Features ieen langsamer Leidenschaftlich, aber nicht trotzig, Konsensist trotzdem wichtig Wenn gar nichts mehr geht, Notbremseziehen 59. Danach Den Beweis antreten 60. Danach Bugs sind kein Weltuntergang, sie kommen vor Wenn man sie schneller xen kann: Win! 61. Und dann? 62. Fin mathias.meyer@peritor.com