Themen

Motivation und Voraussetzungen

Warum und wann sollte man refaktorieren?

Strategien und Vorgehen beim Refactoring

Zusammenhang mit Entwurfsmustern

Folien

PDF

• Software wird und muss sich immer wieder verändern,
  da sich die Anforderungen ändern.
• Refactoring ist die Verbesserung der internen Struktur
  existierenden Codes ohne Änderung seiner Funktionalität.
• Zeitdruck ist kein Argument gegen Refactoring.
  Unterlassen verursacht später (erheblich) mehr Aufwand.
• Refactoring sollte langsam, wohlüberlegt und
  sorgfältig durchgeführt werden.
• Gute Tests und eine ausreichende Testabdeckung sind
  zwingende Voraussetzung für erfolgreiches Refactoring.

Eine kommentierte und handverlesene Liste mit weiterführender Literatur zum Thema. Die Auswahl ist zwangsläufig subjektiv.

Der „Klassiker“ zum Thema ist ist das Buch von Martin Fowler [Fowler, 1999Fowler, Martin (1999): Refactoring. Improving the Design of Existing Code, Addison-Wesley Longman, Boston]. Es entstand, bevor testgetriebene Entwicklung wirklich populär wurde, verweist aber gleichwohl auf die Notwendigkeit sauberer Unittests und einer hohen Testabdeckung als Voraussetzung für erfolgreiches Refactoring. (Darüber hinaus ist Fowler schon damals mit dem Konzept der testgetriebenen Entwicklung vertraut.)

Eine gute Zusammenfassung von Refactoring findet sich in Kapitel 25 von [McConnell, 2004McConnell, Steve (2004): Code Complete. A practical handbook of software construction, Microsoft Press, Redmond, Washington]. McConnell fasst hier viele der Strategien aus [Fowler, 1999Fowler, Martin (1999): Refactoring. Improving the Design of Existing Code, Addison-Wesley Longman, Boston] sehr knapp zusammen.

Von Robert Martin gibt es unterschiedlich ausführliche Beschreibungen von Refactoring anhand konkreter Codebeispiele, eher kurz ist Kapitel 5 in [Martin, 2003Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey], ausführlicher Kapitel 14 in [Martin, 2008Martin, Robert C. (2008): Clean Code. A Handbook of Agile Software Craftmanship, Prentice Hall, Upper Saddle River, New Jersey]. Sehr knapp und ohne Beispiele ist Abschnitt 33 in [Hunt, 1999Hunt, Andrew; Thomas, David (1999): The Pragmatic Programmer, Addison-Wesley, Boston]. Wer eine deutsche Beschreibung vorzieht, wird in Kapitel 15 von [Passig, 2013Passig, Kathrin; Jander, Johannes (2013): Weniger schlecht programmieren, O'Reilly, Heidelberg] fündig.

Der Zusammenhang zwischen Entwurfsmustern [Gamma, 1995Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995): Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, Boston] und Refactoring [Fowler, 1999Fowler, Martin (1999): Refactoring. Improving the Design of Existing Code, Addison-Wesley Longman, Boston] wird von Kerievsky [Kerievsky, 2005Kerievsky, Joshua (2005): Refactoring to Patterns, Addison-Wesley, Boston] hergestellt. Er präsentiert in seinem Buch einen Katalog von Refactorings zu, in Richtung von und weg von Entwurfsmustern.

• Fowler, Martin (1999): Refactoring. Improving the Design of Existing Code, Addison-Wesley Longman, Boston
• Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995): Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, Boston
• Hunt, Andrew; Thomas, David (1999): The Pragmatic Programmer, Addison-Wesley, Boston
• Kerievsky, Joshua (2005): Refactoring to Patterns, Addison-Wesley, Boston
• Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey
• Martin, Robert C. (2008): Clean Code. A Handbook of Agile Software Craftmanship, Prentice Hall, Upper Saddle River, New Jersey
• McConnell, Steve (2004): Code Complete. A practical handbook of software construction, Microsoft Press, Redmond, Washington
• Passig, Kathrin; Jander, Johannes (2013): Weniger schlecht programmieren, O'Reilly, Heidelberg