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.

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 :-)

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?

Vortragssprache: Deutsch
Level: Fortgeschrittene
Zielgruppe: Architekten, Entwickler, Product Owner, Quality Assurance, Projektleiter, Abteilungsleiter

Unternehmen:
Cape of Good Code GmbH

Egon Wuchner