Refactoring – Unabhängig von Microservices

Wie geht man praktisch vor, um Code nachträglich entlang von Fachlichkeiten zu refactoren?

Das eigene Software-System in Microservices transformieren? Unabhängig davon, wir Softwerker sollten auch bestehenden Code entlang von Fachlichkeiten besser trennen. Wie gehen wir vor? Strangler-Pattern? Ist keine praktische Anleitung. Den Code in Geschäftsdomänen konzeptionell aufteilen und dann refactoren? Klingt nach Big-upfront-Design.

Im Vortrag zeigen wir, wie man die bestehende Datenbasis nutzen kann. Wie man von Features (im Issue-Tracker) ausgeht, diese probeweise Domänen zuweist und deren Kopplungen (Überlappungen, Aufruf-Abhängigkeiten) im Code evaluiert. Damit dann den Refactoring-Bedarf lokalisieren und den Aufwand bewerten. Und wie automatisierte Refactoring-Vorschläge dabei eine Rolle spielen. Die Herausforderungen sind die gleichen, wir müssen sie nur anders angehen.

Behandelte Problemstellungen

• Wie trennt man bestehenden Code nach fachlichen Verantwortlichkeiten?
• Wie führt man das ganze probeweise durch vor dem Refactoring/Coding?
• Wie nutzt man die Features des Issue-Trackers dafür?
• Wie nutzt man das Code-Repository dafür?
• Wie wird der Refactoring-Bedarf lokalisiert?
• Wie bewertet man den Aufwand dafür?

Nutzen für den Teilnehmer

• Teilnehmer lernen ein praktisches Vorgehen zur Trennung des Codes entlang fachlicher Verantwortlichkeiten
• Teilnehmer lernen mehr über architekturelle technische Schulden
• Teilnehmer wohnen einem unterhaltsamen Vortrag bei :-)