Refactoring ist nicht weniger als ein Eingriff in die Codebasis von Systemen, der Stabilität schaffen oder neue Risiken erzeugen kann. Entscheidend ist daher das richtige Vorgehen. Der IT-Dienstleister Avision fasst die wichtigsten Schritte für eine erfolgreiche OP am lebenden Code zusammen.

In der Praxis zeigt sich, dass Refactoring weit mehr ist als eine rein technische Maßnahme. Damit Verbesserungen an der Codebasis langfristig wirken, braucht es ein klares Verständnis für Ziele, Grenzen und Abläufe. Auf welche Prinzipien es dabei ankommt und wie sich Refactoring strukturiert in den Entwicklungsalltag integrieren lässt, hat Avision auf Basis langjähriger Projekterfahrung zusammengefasst:

1. Klare Grenzen setzen und schrittweise vorgehen

Refactoring sollte bewusst begrenzt und kontrolliert erfolgen. Statt großflächiger Umbauten sind klar definierte, kleinere Änderungen entscheidend, die sich überprüfen lassen. In der Praxis hat sich daher ein schrittweises Vorgehen mit kleinen Commits bewährt, mit dem Anpassungen direkt getestet und nachvollzogen werden können. Ebenso wichtig ist eine klare Abgrenzung des Scope: Welche Bereiche sollen optimiert werden und welche nicht? Ohne diese Grenzen besteht die Gefahr, dass das Refactoring-Projekt ausufert. Das führt nicht nur zu steigender Komplexität, sondern gefährdet auch Zeitpläne und die Akzeptanz im Team.

2. Umfassendes Testkonzept einführen

Tests sind kein Nice-to-have, sondern die zentrale Voraussetzung dafür, dass ein Refactoring überhaupt verantwortbar ist. In der Praxis hat sich gezeigt, dass Unternehmen davon profitieren, Tests bereits vor dem eigentlichen Refactoring zu erstellen, um das bestehende Verhalten der Software abzusichern. Erst diese Basis macht sichtbar, ob sich durch Änderungen ungewollt Funktionalität verändert. Je nach Kritikalität des Code-Bereichs kommen unterschiedliche Testarten in Frage, vor allem Unit-Tests, Integrations- und End-to-End-Tests sind dabei entscheidend.

3. Refactoring als Prozess verstehen

Refactoring entfaltet seine größte Wirkung, wenn es nicht als einmaliges Großprojekt verstanden wird, sondern als fester Bestandteil der kontinuierlichen Softwareentwicklung. So lässt sich vermeiden, dass technische Schulden über Jahre anwachsen und irgendwann nur noch mit hohem Aufwand abgebaut werden können. Ein bewährter Ansatz ist dabei, den Code bei jeder Änderung ein Stück besser zu hinterlassen, als man ihn vorgefunden hat. Wurde das Refactoring über längere Zeit vernachlässigt, reicht ein rein inkrementeller Ansatz allerdings oft nicht aus. In solchen Fällen ist es sinnvoll, gezielt zusätzliche Phasen einzuplanen, etwa technische Sprints oder dedizierte Projekte zur Reduktion technischer Schulden.

4. KI nur gezielt einsetzen

Künstliche Intelligenz kann Refactoring wirkungsvoll unterstützen, wenn sie bewusst eingesetzt wird. Besonders hilfreich ist KI dort, wo sie Entwickler bei klar definierten Aufgaben entlastet, etwa beim Erstellen von Unit-Tests, beim Umstrukturieren von Methoden oder bei der Reduzierung von Code-Duplizierungen. Weniger zielführend ist der Versuch, große Codebereiche oder ganze Anwendungen vollständig von einer KI mit einem Refactory-Ansatz optimieren zu lassen. Gerade bei gewachsenen Legacy-Systemen bleibt fachliche Bewertung durch die Fachseite und Entwickler unverzichtbar. Effektiv wird KI deshalb nicht als Autopilot, sondern als unterstützendes Werkzeug. Der Mensch bleibt weiter in der Verantwortung für Architektur, Logik und Qualität.

„Refactoring ist eine notwendige Investition in die Zukunftsfähigkeit von Software“, sagt Nadine Riederer, Geschäftsführerin bei Avision. „Es geht darum, den eigenen Code systematisch aufzuräumen und sinnvoll zu modernisieren, bevor echte Probleme entstehen. Sicherlich, das Refactoring ist mit Zeitaufwand verbunden und liefert meistens keine spannenden neuen Features. Aber es schafft die Grundlage, Software stabil weiterzuentwickeln, technische Schulden zu vermeiden und neue Anforderungen verlässlich umzusetzen.“

Diese Presseinformation kann auch unter www.pr-com.de/de/avision abgerufen werden.

Zudem ist sie bei EAS-MAG.digital zu lesen.

Pressekontakt

Avision GmbH
Christina Karl
Marketing
Bajuwarenring 14
D-82041 Oberhaching
Tel. +49-89-623037-967
christina.karl@avision-it.de 

www.avision-it.de     

PR-COM GmbH
Melissa Gemmrich
Sendlinger-Tor-Platz 6
D-80336 München
Tel. +49-89-59997-759
melissa.gemmrich@pr-com.de

www.pr-com.de

Alternde IT-Systeme brauchen Hilfe. Weil eine Modernisierung aber zunächst Zeit, Energie und Geld kostet, sehen viele Entscheidungsträger zwar die Notwendigkeit zu handeln, sind aber erstaunlich kreativ beim Schönreden der vorliegenden Fakten. Der IT-Dienstleister Avision zeigt, hinter welchen Beschönigungen in Wahrheit eine unterlassene digitale Hilfeleistung steckt.

Den meisten Unternehmen ist längst bewusst, dass ihre Legacy-Software den Anforderungen der nächsten Jahre nicht gerecht werden wird. Technisch ist das selten ein Geheimnis, organisatorisch meist auch nicht. Und trotzdem passiert oft erstaunlich wenig. Anstatt klare Entscheidungen zu treffen, werden Erfahrungswerte aus der Vergangenheit herangezogen und die Hoffnung verbreitet, dass sich das Problem irgendwie von selbst erledigt. Das ist auch gefährlich, weil Legacy-Systeme selten über Nacht spektakulär explodieren, sondern langsam aber stetig teurer, schwerfälliger und riskanter werden. Avision hat die fünf häufigsten Scheinargumente aus der Praxis gesammelt, die aktive Gegenmaßnahmen ausbremsen.

„Das tut’s doch noch.“

Ja, im Moment schon. Ein System, das läuft, wirkt auf den ersten Blick oft noch stabil. Doch das bloße Funktionieren hat nichts mit Skalierung, Sicherheit und Zukunftsfähigkeit zu tun. Wenn mehr Nutzer auf dem System sind, als es verkraftet, Backups seit Jahren nicht getestet wurden und neue rechtliche Anforderungen nur mit viel Glück oder gar nicht mehr umsetzbar sind, dann läuft das System nicht mehr wirklich – es hält sich irgendwie über Wasser. Spätestens wenn ein Audit nur deshalb bestanden wird, weil niemand genau hingeschaut hat, muss gehandelt werden. Das geht aber nur, wenn das System überhaupt noch am Leben ist.

„Es gibt keinen Business Case.“

Modernisierung fühlt sich oft wie reines Geldausgeben ohne sichtbaren Mehrwert an, schließlich verkaufen Unternehmen danach nichts Neues. Übersehen wird dabei allerdings gerne, dass Legacy-Systeme auch die kleinste Veränderung maximal komplex machen, Infrastrukturen unnötig verteuern und Sicherheitsrisiken mit sich bringen, die im Ernstfall ein Vielfaches der Modernisierungskosten verursachen. Der Business Case liegt selten in der Modernisierung selbst, sondern in den Kosten, die ohne sie stillschweigend weiterlaufen.

„Das ist so alt, das hackt keiner mehr.“

Alte Systeme sind unscheinbar und werden als Konsequenz gerne als uninteressant für Angreifer abgestempelt. Dazu kommen Argumente wie Firewall, internes Netzwerk oder fehlende Attraktivität für Angreifer. Das ist fatal, denn die Realität sieht anders aus: Veraltete Software bedeutet oft ungepatchte Schwachstellen, fehlende Updates und Abhängigkeiten, die niemand mehr überblickt. Jeder Faktor für sich ist ein potenzielles Einfallstor für Cyberkriminelle. Sicherheit entsteht durch Wartbarkeit und Transparenz – und genau die fehlen vernachlässigten Legacy-Systemen.

„Das kann keiner machen.“

Wenn entscheidendes Know-how auf ein oder zwei Personen konzentriert ist, wird jede Veränderung zum Risiko. Schon der Ausfall einer einzigen Person kann reichen, um Systeme, Prozesse oder Projekte zum Stillstand zu bringen. Oft wird dieses Problem „gelöst“, indem alles beim Alten belassen wird. Ist ja noch immer gut gegangen. Das Problem: Je länger nichts passiert, desto schwieriger wird es, Wissen aufzubauen oder extern einzukaufen. Irgendwann zwingt eine gesetzliche Änderung oder ein Ausfall zum Handeln – dann aber unter maximalem Druck und Stress für alle Beteiligten.

„Never change a running system.“

Dieser Satz klingt nach Erfahrung und Abgeklärtheit, ist aber meist Ausdruck der Angst vor Kosten, Komplexität und dem großen Berg Arbeit. Während langjährige Mitarbeitende gelernt haben, mit den Eigenheiten des Systems zu leben, scheitern neue Kolleginnen und Kollegen daran oder wechseln schnell wieder. Gleichzeitig zieht der Wettbewerb vorbei. Ein System mag heute noch laufen – ohne Innovation läuft es morgen nur noch hinterher.

„Wenn es um die Wartung und Modernisierung geht, unterscheidet sich Software nicht viel von Bereichen wie dem Straßenbau oder Immobilien“, erklärt Nadine Riederer, Geschäftsführerin von Avision. „Werden dringende Maßnahmen immer nur auf die lange Bank geschoben und Investitionen gescheut, geht irgendwann gar nichts mehr – und dann wird es erst richtig teuer. Ausreden gibt es viele, aber sie kosten viel Zeit und letztendlich auch Geld.“

Diese Presseinformation kann auch unter www.pr-com.de/de/avision abgerufen werden.

Pressekontakt

Avision GmbH
Christina Karl
Marketing
Bajuwarenring 14
D-82041 Oberhaching
Tel. +49-89-623037-967
christina.karl@avision-it.de 

www.avision-it.de     

PR-COM GmbH
Melissa Gemmrich
Sendlinger-Tor-Platz 6
D-80336 München
Tel. +49-89-59997-759
melissa.gemmrich@pr-com.de

www.pr-com.de

Viele IT-Projekte scheitern nicht an der Technologie oder dem Budget, sondern an Führungsschwäche. Zwischen Moderationswahn, Mikromanagement und verpassten Entscheidungen versanden dabei nicht selten Deadlines und Motivation. Wer Verantwortung trägt, aber sie nicht übernimmt, sorgt für Stillstand. Der IT-Dienstleister Avision stellt fünf Projektleiter-Typen vor, die jeder aus der Praxis kennt.

Moderne IT-Projekte sind abhängig von guter Führung, Entscheidungsfreudigkeit, Empathie und Weitsicht – alles Attribute, die sich in der Projektleitung vereinen sollten. Soweit die Theorie. Zurück in der Praxis finden die oftmals wenig beneidenswerten IT-Teams aber ganz andere „Stärken“ bei der Projektleitung vor. Entscheidungen werden immer und immer wieder vertagt, Verantwortung großzügig weitergereicht und Meetings inflationär angesetzt.

Neben den vielen leistungsfähigen und kompetenten Projektleiterinnen und -leitern dieser Welt hat Avision fünf ganz spezielle Typen identifiziert, mit denen auch das vielversprechendste IT-Projekt zielsicher gegen die nächste Wand kracht.

Der Moderator – stets bemüht

Er führt kein Meeting allein und trifft keine Entscheidung, ohne mindestens drei Kolleginnen und Kollegen zu befragen. Alle dürfen zu Wort kommen, das auch gern mehrfach. Und lange. Seine eigenen Einwürfe bringen auch den kleinsten Fortschritt auf den Anfang zurück und den meisten Mitarbeitenden graut es schon vor dem nächsten „kurzen“ Team-Update. Nach zwei Stunden ist zwar alles besprochen, aber nichts entschieden. Der Moderator verwechselt dabei sehr gerne Führung mit physischer Anwesenheit und Gesprächsdauer mit echtem Fortschritt. Seine Stärke liegt in der Organisation von Meetings, nicht in ihrer Wirksamkeit. Projekte mit ihm enden selten mit einem Durchbruch, wenn sie überhaupt enden. Perfekt für alle, die nicht scheitern wollen – weil sie nie fertig werden. Und noch ein kleiner Haken dabei: Projekte werden immer teurer und der Zeitplan ist eher ein Art gut gemeinte Richtungsvorgabe.

Der Redner – ein Freund seiner Worte

Er verwechselt Kommunikation mit Dauerbeschallung. Jedes Meeting beginnt mit einem Monolog und endet mit einer Wiederholung desselben. Wer versucht, etwas beizutragen, löst einen einstündigen Exkurs aus. Der Redner liebt seine eigene Stimme so sehr, dass er sie ungern unterbricht – weder für Argumente noch für Ergebnisse. Irgendwann spricht im Team niemand mehr über Probleme, weil man fürchtet, eine neue Vorlesung zu provozieren. So wird jedes Thema gründlich zerredet, jedes Projekt zu Tode moderiert – und jede Stunde zu einer, die man nie zurückbekommt. Frei nach dem Motto „This meeting could have been an E-Mail“ blickt das Team dabei schon mit Unbehagen auf den nächsten Termin im Kalender.

Der Unsichtbare – Tarnmodus an

Er ist formal Projektleiter, praktisch aber Mythos. Im Meeting fehlt er, im Chat ist er offline, im Projektplan nur als Name präsent. Während das Team sich so gut es eben geht selbst organisiert, wundert der Kunde sich über die doch beachtlich lange Funkstille. Im besten Falle taucht der Unsichtbare kurz vor dem Go-live wieder auf, meist zum Gratulieren und um die Arbeit des Teams als gemeinsamen Erfolg zu verkaufen. Führung ist für ihn ein Konzept, das auch ohne ihn funktionieren sollte. Und manchmal funktioniert das sogar, bis jemand merkt, dass niemand mehr mit dem Kunden spricht. Der Unsichtbare sorgt zuverlässig für Eskalationen – und das intern wie extern.

Der Ahnungslose – viel heiße Luft

Inhalte? Braucht kein Mensch! Statt Probleme anzugehen und Teams mit seiner Erfahrung zu führen, zählt er Tickets, prüft komplizierte Tabellen und ist die meiste Zeit sowieso in mysteriösen Meetings gebunden. Fachliche Fragen nimmt er „mit“ (wohin auch immer) – und bringt sie nie wieder zurück (warum auch immer). Der Projektstatus ist für ihn eine Zahl, kein Zustand. Sein Verständnis von Leitung baut darauf auf, dass sich alle zu jederzeit gegenseitig updaten müssen – morgens sogar im Stehen. So bleibt er stets oberflächlich informiert und kann den Projektplan aktualisieren. Risiken erkennt er mit großer Verlässlichkeit immer erst dann, wenn das Worst-Case-Szenario eingetroffen ist und Erfolge, wenn jemand anderes sie ihm erklärt. Für Probleme im Team hat er genau null offene Ohren und auch kein Interesse für was auch immer seine Kolleginnen und Kollegen da eigentlich im Detail arbeiten.

Der Diktator – alles hört auf sein Kommando

Er weiß alles (besser), vor allem wann etwas „fertig“ ist. Kritik gilt als Illoyalität, Widerspruch als Schwäche. Unter seiner Regie werden Aufgaben eher abgeschlossen als erledigt. Druck ist sein bevorzugtes Führungsinstrument, und Drohungen sind Teil seiner Meetingkultur. „Da sehe ich ja, wie du priorisierst“, ist einer seiner Lieblingssätze – halb Zynismus, halb Warnung. Teams unter seiner Leitung funktionieren nur so lange, bis die Ersten gehen. Was merkwürdigerweise sehr oft passiert. Danach sorgt er für „frischen Wind“, weil ständig jemand Neues dazukommt. Er verwechselt Disziplin mit Angst und merkt nicht, dass unter seinem Kommando nicht nur Projekte fehlschlagen, sondern auch Menschen die Motivation verlieren.

„Am Ende sind es nicht nur neue Methoden oder leistungsstarke Tools, die über den Erfolg oder Misserfolg von IT-Projekten entscheiden, sondern Menschen“, sagt Nadine Riederer, Geschäftsführerin von Avision mit einem Augenzwinkern. „Eine gute Projektleitung hält das Team zusammen, schafft Orientierung und trifft Entscheidungen, wenn andere zögern.“

Diese Presseinformation kann auch unter www.pr-com.de/de/avision abgerufen werden.

Pressekontakt

Avision GmbH
Christina Karl
Marketing
Bajuwarenring 14
D-82041 Oberhaching
Tel. +49-89-623037-967
christina.karl@avision-it.de 

www.avision-it.de     

PR-COM GmbH
Melissa Gemmrich
Sendlinger-Tor-Platz 6
D-80336 München
Tel. +49-89-59997-759
melissa.gemmrich@pr-com.de

www.pr-com.de