For many people, refactoring is a simple code transformation they click on in a context menu or via a keyboard shortcut. The widespread availability of automated refactoring should have made oversized classes and long-winded functions a thing of the past. But it hasn't.

Having a tool is only part of the solution: knowing what to do with it and how to use it well matters. In this talk, we'll revisit what refactoring is (and isn't) and emphasise the idea that refactoring should be considered a design process and not just a clean-up click.

Target Audience: Developers, Architects, Tech Leads
Prerequisites: Programming experience
Level: Advanced

Extended Abstract:
For many people, refactoring is a simple code transformation they click on in a context menu or via a keyboard shortcut. They can extract, inline, replace, move, rename, etc. at will. The widespread availability of automated refactoring should have made oversized classes and long-winded functions a thing of the past. But it hasn't.

Having a tool is only part of the solution: knowing what to do with it and how to use it well is what makes the bigger difference. Refactoring is often mentioned in the context of agile development, test-driven development and legacy code, but beyond saying that it should happen, there is often not much focus on how and why.

In this talk, we'll revisit what refactoring is (and isn't), examine what practical and social obstacles refactoring faces, explore the idea that refactoring should be considered a design process and not just a clean-up click, and that most interesting refactorings are not necessarily automated.

Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal

In den letzten 30 Jahren habe ich viel Software selbst oder mit Teams entwickelt und viele Softwaresysteme analysiert, um die darin angesammelten technischen Schulden zu analysieren und Lösungen zu erarbeiten. Dabei bin ich immer wieder ähnlichen Missverständnissen rund um das Thema Software-Architektur begegnet. In diesem Vortrag werde ich erklären, welche Missverständnisse das sind und warum sie anders gedacht werden müssen, damit wir mit unseren Software-Architekturen kleine und große Probleme lösen können.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider:innen, alle!
Voraussetzungen: Erfahrung aus Software-Entwicklungsprojekten
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In Beratungs- und Schulungssituationen habe ich immer wieder mit Kunden zu tun, die irgendein Architekturkonzept gelernt oder gelesen und vielleicht sogar selbst in ihre Software eingebaut haben, es aber aus meiner Sicht falsch verwenden/verstehen. Diese Erkenntnis taucht meist erst nach einer eingehenden Diskussion auf. Zuerst denken alle, wir meinen das Gleiche.

Meine aktuellen Highlights sind:

• Microservice-Architekturen sind dasselbe wie Service-orientierte Architekturen (SOA)
• Wenn man Events einsetzt, dann hat man eine lose gekoppelte Architektur
• Wiederverwendung steht über allen anderen Konzepten
• Zyklen sollte man durch den Einsatz von Interfaces auflösen
• Neubau ist besser als Refactoring
• Jedes Team sollte seine eigene Technologie frei wählen
• Sourcecode reicht als Dokumentation aus

Es kommen immer wieder neue Missverständnisse hinzu – so dass zum Zeitpunkt der Konferenz durchaus einige Missverständnisse erneuert sind.

Je nach Länge variiere ich die vorgestellten Missverständnisse.

Copy & Paste ist seit Jahrzehnten als Code-Smell verschrien. Trotzdem kommen in allen größeren Systemen viele Klone vor. Das schafft Probleme.

Clone Detection – die automatisierte Erkennung solcher Duplikate – ist inzwischen in vielen IDEs enthalten. Allerdings nützt es wenig, eine Liste mit 100k Klonen zu erzeugen. Die Herausforderung ist der sinnvolle Umgang mit bestehenden Klonen. Im Vortrag stelle ich Clone Detection und Management-Techniken vor. Außerdem zeige ich, wie man als Architekt eine Bestandsaufnahme im eigenen System machen kann.

Zielpublikum: Architekt:innen und Entwickler:innen
Voraussetzungen: Grundlegende Programmiererfahrung.
Schwierigkeitsgrad: Anfänger 

Extended Abstract:
Copy & Paste-Programmierung ist seit Jahrzehnten als Code-Smell verschrien. Das hat nicht verhindert, dass quasi in allen größeren Systemen viele durch Copy & Paste entstandene Klone vorkommen. In einigen Systemen kommt mehr als die Hälfte aller Zeilen in Kopie an anderen Stellen auch vor. Das schafft in der Weiterentwicklung viele Probleme, da Änderungen an mehreren Stellen durchgeführt werden müssen, Code-Reviews aufwändiger werden, Fehler oft bei Fixes in Kopien übersehen werden etc.

Clone Detection, also statische Code-Analyse, die solche Duplikate automatisiert erkennen kann, ist inzwischen in einigen IDEs enthalten. Allerdings zeigt die Erfahrung, dass es wenig nützt, eine Liste mit 100.000 Klonen zu erzeugen.

Die Herausforderung ist nicht das Finden, sondern Clone-Management: der sinnvolle Umgang mit existierenden Klonen.

Welcher Umgang mit Klonen der richtige ist, hängt vom eigenen Kontext ab: Wie viel Copy & Paste-Programmierung kommt im eigenen System vor, und wie wirkt sich das auf die Kosten aus? Welche Fehler wurden nicht in allen Kopien behoben? Gibt es "Copy & Paste im Großen" zwischen verschiedenen Anwendungen in der Unternehmensarchitektur? Welche Klone sollten wir in wiederverwendbare Module/Bibliotheken herausziehen, bei welchen lohnt es nicht? In welchen Bereichen wollen wir Duplikation eventuell bewusst, um z. B. Microservices unabhängig voneinander weiterentwickeln zu können? Und wie stellen wir dabei sicher, dass wir Fehler in Kopien trotzdem konsistent beheben?

Im Vortrag stelle ich Clone Detection und Management-Techniken vor. Ich zeige Kostenmodelle, um die Kosten von Klonen zu quantifizieren, und gehe auf Erfahrungen ein, die wir mit Clone-Management in den letzten 10 Jahren bei verschiedenen Kunden gesammelt haben. Außerdem zeige ich, wie man eine Bestandsaufnahme im eigenen System machen kann, um diese Fragen als Architekt für das eigene System oder die eigene Anwendungslandschaft zu beantworten.

Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/wolfgang.rohde

Die DB AG beschäftigt sich seit 2019 mit Quantentechnologien zur Optimierung ihrer Assets (Schiene, Zug, Personal, Energie) und den Auswirkungen auf die Security. In Konsortien mit Forschungseinrichtungen erfolgt ein Realitätscheck, in dem Implementierungen auf Digital Annealern durchgeführt werden. Der praktische Umgang mit der Technologie steht im Vordergrund. Es werden aktuelle Use Cases ebenso vorgestellt wie auch Herausforderungen, die sich durch die Technologie ergeben. Eine Übersicht des Quantencomputing-Ökosystems rundet das Bild ab.

Zielpublikum: Architekt:innen, Projektleiter:innen, Manager, Entscheider:innen
Voraussetzungen: Keine speziellen IT-Kenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der kommerzielle Einsatz von Quantencomputern wird von den Software- und Hardwareherstellern seit kurzem angeboten. Die Technologie verspricht einen großen Nutzen bspw. in der Materialforschung und in der Optimierung. Auf der anderen Seite birgt die Technologie Risiken für die IT und OT, da Verschlüsselungsmechanismen bei ausreichender Größe und Stabilität der Quantensystem gebrochene werden können. Für die Unternehmen ist die Annäherung an das Thema eine Herausforderung, da (noch) wenige Experten die Anwendungsmöglichkeiten, die Risiken und die Anbieterlandschaft erfassen. In dem Vortrag werden den Zuhörern Mittel an die Hand zu geben, sich mit der Technologie frühzeitig auseinanderzusetzen, in den Unternehmen zum Einsatz zu bringen und sich auch abzusichern. So ist in Europa ein Ökosystem aus mehr als 160 Unternehmen vom Startup bis hin zu Konzernen entstanden, das sich in Allianzen und Kooperationen weltweit austauscht.

Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/thomas.ronzon

Überall werden Architekturprinzipien publiziert, die diesen oder jenen Vorteil haben.

Immer wieder gibt es Success-Storys, wie gut z. B. ein System skalierbar ist.

Aber mal ehrlich, jeder kennt auch negative Beispiele.

Genau darüber soll in diesem Talk gesprochen werden – mit Euch!

• Welche Beispiele von Fallstricken kennt ihr?
• Wie wird man sie wieder los?
• Hätte man vorher die Probleme erkennen können?

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten 

Extended Abstract:
Während die Literatur über Software-Engineering geradezu von Positivbeispielen erfolgreicher Software-Architekturen strotzt, kennen Software-Architekturen auch einige Probleme oder sogar Fehlschläge. Nicht immer wählen Architekten die richtigen Entscheidungen, nicht immer existiert ein idealer Projektkontext. Wir leben und agieren in einer nicht perfekten Welt. Bei einer Retrospektive erkennen Architekten oft, was sie hätten anders machen sollen. Jeder kann ein Liedchen davon singen. In einem Fish-Bowl-Setting erhalten Teilnehmer die Gelegenheit, aus dem Nähkästchen zu plaudern. Welche Fehler kennen sie und was hätte anders laufen sollen. Stichwort: Aus Fehlern lernen. Dadurch sollte es zu einigen Déjà-vus kommen. Ziele sind ein geschärfter Blick der Teilnehmer und ein Lernen von anderen.

Elasticsearch ist eine weit verbreitete Suchmaschine und ein Datenspeicher. Neben diesem Erfolg gibt es aber beinahe wöchentlich negative Schlagzeilen, weil falsch konfigurierte Cluster sensible Daten preisgeben oder Ziel von Erpressern werden.

Dieser Vortrag gibt einen Überblick, wie es aus dem Spannungsfeld von Einfachheit gegenüber Sicherheit dazu kam, was genau die Probleme sind und wie man sie auflösen kann. Dabei geht es auch darum, dass richtige Entscheidungen der Vergangenheit heute andere Lösungen erfordern und wie man mit seinem Erfolg wächst.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider:innen
Voraussetzungen: Keine strikten Voraussetzungen
Schwierigkeitsgrad: Fortgeschritten

Das Thema digitale Inklusion spielt in der IT-Welt noch immer eine untergeordnete Rolle. Dabei sind bereits die Vorgaben und Gesetze für die IT gemacht. IT-Lösungen von Unternehmen müssen ab 2025 barrierefrei sein.

• Was muss moderne Software-Architektur dafür beachten?
• Wie erhalte ich weiterhin Zugang zu öffentlichen Ausschreibungen?
• Wie erfülle ich die Mindestanforderungen, auch im privaten Sektor?

Die Expertin für Barrierefreiheit, Peggy Reuter-Heinrich, bietet einen auch für Techis hilfreichen Einstieg in das Thema.

Zielpublikum: IT-Schaffenden Projektmanager:innen, Entwickler:innen, UX-Designer:innen, Entscheider:innen
Voraussetzungen: Kenntnisse in UX-UI-Design, Development
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Das Thema digitale Inklusion spielt in der IT-Welt leider noch immer eine untergeordnete Rolle. Dabei sind bereits mit der Barrierefreien-Informationstechnik-Verordnung („BITV) sowie den Web Content Accessibility Guidelines (WACG) die Vorgaben für die IT gemacht. Das mündet in das Europäische Teilhabe-Gesetz (EAA) und das Barrierefreiheitsstärkungsgesetz (BFStG). Beides gibt für Unternehmen vor, dass auch deren IT-Lösungen ab 2025 barrierefrei sein müssen.

In dem Vortrag werden die Vorgaben und Bedingungen aufgezeigt und erläutert, die moderne Software-Architektur heutzutage mit einbeziehen muss, um weiterhin Zugang zu öffentlichen Ausschreibungen zu erhalten und die Mindestanforderungen künftig auch im privaten Sektor zu erfüllen.

Die 98 Regeln der BITV bilden hierfür die Grundlage, wozu die Sprecherin einen auch für Techis nachvollziehbarer Einstieg bietet.

Der technischen Programmierung kommt dabei eine Schlüsselrolle zu, da sie die Basis für alle digitalen barrierefreien Lösungen ist. Das gilt für mobile Apps, Webseiten und Software. Hierfür sind sämtliche Hauptakteure aus der IT gefragt, um Brücken für eine menschenfreundliche digitale Welt zu bauen.

Insbesondere Software-, Web- und App-Entwickler:innen, Software-Architekt:innen, technische Berater:innen, IT-Abteilungsteiler:innen und IT-Projektleiter:innen wird die Expertin für Barrierefreiheit, Peggy Reuter-Heinrich, pragmatisch weiterhelfen.

Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/thomas.much

Wenn Code und Architektur einer Anwendung nicht mit Testbarkeit im Hinterkopf entwickelt wurden, ist es oft schwierig, diese Anwendungen in eine agilere Software-Entwicklung mit kontinuierlicher Auslieferung zu überführen. Die dafür nötigen automatisierten, schnellen Tests können oft nicht oder nur mit sehr hohem Aufwand geschrieben werden. In dieser Session zeige ich ein paar grundlegende Muster und Ideen, mit denen vorhandener Legacy-Code für bessere Testbarkeit umgebaut werden kann. Und dieses Wissen hilft natürlich auch bei Neuentwicklungen.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Hilfreich ist, wenn man schon mal versucht hat, (Unit-)Tests für alten Code zu schreiben
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wer schon einmal Änderungen in einer großen, alten Anwendung einbauen musste, die "historisch bedingt" nicht durch ausreichende Testautomatisierung abgesichert ist, weiß vielleicht, wie schwer es sein kann, nachträglich (Unit-)Tests für solche Altanwendungen zu schreiben. Zumal es ohne eine solche Absicherung durch schnelle Tests kaum möglich ist, solche Anwendungen für beispielsweise Continuous Delivery fit zu machen – was bei vielen Unternehmen im Rahmen von DevOps-Initiativen o. ä. relevant ist bzw. wird.

Wie schafft man es aber, vorhandenen Code besser testbar zu machen? Oder neuen Code gleich gut testbar zu entwickeln? Oft denkt man dann sofort an Programmierpraktiken wie Test-Driven Development (TDD), durch die ein besseres – besser testbares! – Code-Design entsteht. Aber es gibt auch einige Architekturstile bzw. -muster, die ein einfacheres Testen mit schnelleren Feedback-Schleifen ermöglichen.

Wir schauen uns in dieser Session an, was es bedeutet, Geschäftslogik von Integrationscode zu trennen, welche unterschiedlichen Code-Designs und Architekturmuster es gibt, um dieses Ziel zu erreichen – und warum damit kleinere und schnellere automatisierte Tests möglich sind.

Es geht dabei um die absoluten Grundlagen von testbarem Code und testbarer Architektur. Wer sich nicht sowieso schon täglich mit diesen Themen beschäftigt, wird Anregungen und Tipps bekommen, wie man sofort morgen im eigenen Projekt die ersten Verbesserungen vornehmen kann.