{"id":45223,"date":"2025-05-05T13:50:15","date_gmt":"2025-05-05T11:50:15","guid":{"rendered":"https:\/\/www.happycoders.eu\/effektives-arbeiten-mit-legacy-code-refactoring-und-testen-bestehender-software\/"},"modified":"2026-04-14T22:40:03","modified_gmt":"2026-04-14T20:40:03","slug":"effektives-arbeiten-mit-legacy-code-refactoring-und-testen-bestehender-software","status":"publish","type":"post","link":"https:\/\/www.happycoders.eu\/de\/buecher\/effektives-arbeiten-mit-legacy-code-refactoring-und-testen-bestehender-software\/","title":{"rendered":"Effektives Arbeiten mit Legacy Code. Refactoring und Testen bestehender Software"},"content":{"rendered":"\n

Effektives Arbeiten mit Legacy Code. Refactoring und Testen bestehender Software<\/h1>\n\n\n\n
\n
\n

von Michael C. Feathers<\/p>\n \n

Dass Tests wichtig sind, und dass Test-Driven-Development zu gut getesteter, gut strukturierter Software f\u00fchrt, wei\u00df heutzutage jeder Programmierer. Leider war das nicht immer der Fall. Und so stehen wir oft vor der Herausforderung, ein System ohne Tests \u2013 ein also ein \u201cLegacy System\u201d nach Michael Feathers Definition \u2013 weiterzuentwickeln.<\/p>\n

Doch wie gehen wir vor, wenn wir keine Testabdeckung haben, um sicherzustellen, dass unsere \u00c4nderungen nichts kaputt machen? Und wenn wir andererseits diese Tests nicht schreiben k\u00f6nnen, weil der Code zu komplex ist, viel zu viele Abh\u00e4ngigkeiten enth\u00e4lt und Logik und Pr\u00e4sentation miteinander verwoben sind?<\/p>\n

Was k\u00f6nnen wir tun, wenn wir die zu testende Klasse nicht instanziieren k\u00f6nnen, weil wir ihrem Konstruktor ein Objekt \u00fcbergeben m\u00fcssen, das wir nicht einfach erzeugen k\u00f6nnen? Oder wenn die zu testende Methode auf die Datenbank zugreift \u2013 obwohl dieser Datenbankzugriff f\u00fcr die Funktionalit\u00e4t, die wir testen wollen, nicht notwendig ist?<\/p>\n

Dieses Buch enth\u00e4lt einen Katalog von Mechanismen, um diese Abh\u00e4ngigkeiten zu lokalisieren und aufzubrechen. Und um den Code entsprechend zu modularisieren, wobei Modulgrenzen geschaffen werden \u2013 sogenannte \u201cSeams\u201d (deutsch: \u201cN\u00e4hte\u201d), an denen wir mit unseren Unit-Tests ansetzen k\u00f6nnen.<\/p>\n

Die vorgestellten Strategien erlauben \u00c4nderungen mit minimalen Risiken. Die Refactoring-Features moderner IDEs erlauben es viele dieser \u00c4nderungen vollautomatisch durchzuf\u00fchren. \u00c4nderungen, die es dann erlauben erste Tests zu implementieren, um darauf aufbauend weitreichendere Refactorings durchzuf\u00fchren, die letztendlich die Codebasis in ein besseres Design \u00fcberf\u00fchren.<\/p>\n

Der Autor erkl\u00e4rt alle Strategien anhand hervorragender, praxisnaher Beispiele, die haupts\u00e4chlich in Java und C++ geschrieben sind.<\/p>\n

Leider wurde das Buch seit 15 Jahren nicht aktualisiert. Vor allem unerfahrene Programmierer sollten darauf achten, nicht jede Strategie dogmatisch umzusetzen. F\u00fcr einige Mechanismen gibt es heutzutage bessere Alternativen; einige der Praktiken f\u00fchren zu schlechterem, statt zu besserem Code; und das Thema Threadsicherheit \u2013 ein Kernthema in den meisten heutigen Unternehmensanwendungen \u2013 wird v\u00f6llig au\u00dfer Acht gelassen.<\/p>\n

Beispielsweise braucht man heutzutage nicht mehr f\u00fcr jede zu mockende Klasse ein Interface. Mockito kann problemlos Klassen mocken, also Abh\u00e4ngigkeiten aufl\u00f6sen ohne ein Interface zu extrahieren. Und wer doch ein Interface extrahiert, beachte dabei bitte das Interface Segregation Principle<\/a>! Die Aussage des Autors, \"it's nice to have an interface that covers all<\/em> of the public methods of a class\" (S. 366), steht leider in krassem Widerspruch dazu.<\/p>\n

Den Aufruf abstrakter Methoden aus einem Konstruktor heraus (\"Extract and override factory method\") sollte man besser vermeiden, wenn man nicht pl\u00f6tzlich einem nur teilweise initialisierten Objekt gegen\u00fcberstehen m\u00f6chte. Aus gutem Grund verbietet C++ diese Praktik. F\u00fcnfundf\u00fcnfzig Seiten nach der Einf\u00fchrung dieser Strategie r\u00e4t der Autor schlie\u00dflich vor deren Einsatz auch in Java ab.<\/p>\n

Multithreading ist in fast keinem der \u00e4lteren Klassiker ein Thema. Heutzutage kommt kein Programmierer mehr daran vorbei. Wenn du eine Klasse mit Strategien wie \"Break Out Method Object\" extrahierst, solltest du daher unbedingt einen Hinweis anbringen, dass die Klasse nicht threadsicher ist. (Alternativ kannst du Instanzvariablen durch geeignete Lock-Mechanismen sch\u00fctzen.)<\/p>\n

Trotz der genannten altersbedingten Schw\u00e4chen kann ich das Buch jedem Programmierer empfehlen, der mit Legacy-Code arbeiten muss. Erfahrene Programmierer haben sicherlich die eine oder andere Strategie schon einmal intuitiv angewendet. Andere Techniken m\u00f6gen neu sein. So oder so, die Formalisierung hilft, die Strategien zu festigen, und ihre Namen verbessern die Kommunikation im Team.<\/p>\n

Behalte nur zwei Dinge im Hinterkopf: Das Buch ist 15 Jahre alt, und f\u00fcr jede Regel gibt es eine Ausnahme!<\/p>\n

\ud83c\udfa7 Geeignet als H\u00f6rbuch? Nein, aufgrund zahlreicher Codebeispiele.<\/em><\/p>\n <\/div>\n \n\n \n

\n
\"Effektives<\/a><\/figure>\n \n\n \n

Buch bei Amazon kaufen *<\/a><\/p>\n \n\n \n

Englisches Original bei Amazon:<\/span>Working Effectively With Legacy Code<\/a><\/p>\n \n\n \n

Genres<\/h4>\n \n\n \n

Softwareentwicklung<\/a> Programmierung<\/a> Softwaretests<\/a> Softwarearchitektur<\/a> Agile Entwicklung & Agiles Projektmanagement<\/a> Informatik<\/a> <\/p>\n <\/div>\n <\/div>\n\n\n\n

Andere Empfehlungen aus den Genres dieses Buches<\/h2>\n\n\n\n
\n \n
\n
\"Clean<\/a><\/figure>\n \n\n \n

Clean Code \u2013 Refactoring, Patterns, Testen und Techniken f\u00fcr sauberen Code<\/a><\/p>\n \n\n \n

Robert C. Martin<\/p>\n <\/div><\/div>\n \n \n

\n
\"Design<\/a><\/figure>\n \n\n \n

Design Patterns: Entwurfsmuster als Elemente wiederverwendbarer objektorientierter Software<\/a><\/p>\n \n\n \n

Erich Gamma, Richard Helm, Ralph E. Johnson, John Vlissides<\/p>\n <\/div><\/div>\n \n \n

\n
\"Refactoring:<\/a><\/figure>\n \n\n \n

Refactoring: Wie Sie das Design bestehender Software verbessern<\/a><\/p>\n \n\n \n

Martin Fowler<\/p>\n <\/div><\/div>\n \n \n

\n
\"Clean<\/a><\/figure>\n \n\n \n

Clean Craftsmanship: Best Practices, Standards und Ethik f\u00fcr die Softwareentwicklung<\/a><\/p>\n \n\n \n

Robert C. Martin<\/p>\n <\/div><\/div>\n \n \n

\n
\"Der<\/a><\/figure>\n \n\n \n

Der pragmatische Programmierer: Ihr Weg zur Meisterschaft<\/a><\/p>\n \n\n \n

Andrew Hunt und David Thomas<\/p>\n <\/div><\/div>\n \n \n

\n
\"Growing<\/a><\/figure>\n \n\n \n

Growing Object-Oriented Software, Guided by Tests<\/a><\/p>\n \n\n \n

Steve Freeman und Nat Pryce<\/p>\n <\/div><\/div>\n \n \n

\n
\"Pattern<\/a><\/figure>\n \n\n \n

Pattern Hatching: Design Patterns Applied<\/a><\/p>\n \n\n \n

John Vlissides<\/p>\n <\/div><\/div>\n \n \n

\n
\"Clean<\/a><\/figure>\n \n\n \n

Clean Coder: Verhaltensregeln f\u00fcr professionelle Programmierer<\/a><\/p>\n \n\n \n

Robert C. Martin<\/p>\n <\/div><\/div>\n \n \n

\n
\"Agile<\/a><\/figure>\n \n\n \n

Agile Software Development: Principles, Patterns, and Practices<\/a><\/p>\n \n\n \n

Robert C. Martin<\/p>\n <\/div><\/div>\n \n \n

\n
\"Clean<\/a><\/figure>\n \n\n \n

Clean Architecture \u2013 Gute Softwarearchitekturen: Das Praxis-Handbuch f\u00fcr professionelles Softwaredesign. Regeln und Paradigmen f\u00fcr effiziente Softwarestrukturierung.<\/a><\/p>\n \n\n \n

Robert C. Martin<\/p>\n <\/div><\/div>\n \n \n

\n
\"Domain-Driven<\/a><\/figure>\n \n\n \n

Domain-Driven Design: Tackling Complexity in the Heart of Software<\/a><\/p>\n \n\n \n

Eric Evans<\/p>\n <\/div><\/div>\n \n \n

\n
\"Implementing<\/a><\/figure>\n \n\n \n

Implementing Domain-Driven Design<\/a><\/p>\n \n\n \n

Vaughn Vernon<\/p>\n <\/div><\/div>\n \n \n

\n
\"Extreme<\/a><\/figure>\n \n\n \n

Extreme Programming: Das Manifest<\/a><\/p>\n \n\n \n

Kent Beck und Cynthia Andres<\/p>\n <\/div><\/div>\n \n \n

\n
\"Projekt<\/a><\/figure>\n \n\n \n

Projekt Unicorn: Der Roman \u00fcber Entwickler, Digital Disruption und das \u00dcberleben im Datenzeitalter<\/a><\/p>\n \n\n \n

Gene Kim<\/p>\n <\/div><\/div>\n \n \n

\n
\"Das<\/a><\/figure>\n \n\n \n

Das Mindset von DevOps. Accelerate: 24 Schl\u00fcsselkompetenzen, um leistungsstarke Technologieunternehmen zu entwickeln und zu skalieren<\/a><\/p>\n \n\n \n

Dr. Nicole Forsgren, Jez Humble und Gene Kim<\/p>\n <\/div><\/div>\n \n<\/div><\/div>\n\n\n\n

* Hinweis: Wir teilen gerne unsere Lieblingsb\u00fccher mit dir! Als Amazon-Partner verdienen wir eine kleine Provision bei Eink\u00e4ufen, die du \u00fcber unsere Links t\u00e4tigst. Dies hilft uns, weiterhin Inhalte zu erstellen, die dir gefallen.<\/em><\/p>\n