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.

Value for the audience:
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 :-)

Problems addressed:
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?

Talk language: German
Level: Advanced
Target group: Architekten, Entwickler, Product Owner, Quality Assurance, Projektleiter, Abteilungsleiter

Company:
Cape of Good Code GmbH

Egon Wuchner