Refactoring kann je nach Perspektive unterschiedliche Prioritäten haben, sowohl in der Zielsetzung als auch in der Umsetzung. Die wichtigsten vier Ziele, die bei fast allen Softwaresystemen zutreffen sind hier aufgelistet.
1. Die Kosten des Betriebs (Wartung und Service) zu reduzieren
Durch Refactoring erreicht man die kontinuierliche Verbesserung des Softwaresystems und den regelmäßigen Umgang damit durch das Developer Team. Fehler können rascher Behoben werden und kleine Änderungen und Neuerungen werden leichter und vor allem schneller umsetzbar. Dies führt zu einer Senkung der Kosten im Betrieb mit der Software.
2. Die Wartbarkeit der Software erhöhen
Durch die regelmäßige Verbesserung und Überarbeitung des Source Codes, werden bei richtiger Durchführung, alle Code Teile stetig besser und die Architektur und Technologie am neuesten Stand gehalten. Dies führt zu erhöhter Wartbarkeit, weil die Code-Base an sich immer lesbarer und nachvollziehbarer wird. Außerdem sind die Developer gewohnt, regelmäßige Releases und Tests durchzuführen.
3. Die Software für Schnittstellen verfügbar und erweiterbar halten
Refactoring erneuert alte Konzepte und hält die Software auf dem Stand der Technik. Werden neue Schnittstellen benötigt, z.b. durch die Verschmelzung von Konzernteilen, oder der Zukauf von Firmen, oder eben die Integration neuer Systeme in die IT Landschaft, können rasch neue Schnittstellen aufgestellt oder vorgesehene genutzt werden.
4. Das System für zukünftige Entwicklungen rechtzeitig positionieren
Nachdem ein System für einen Business Case entwickelt wurde und auch diese immer wieder innoviert werden, kann es sein, dass die Software erweitert werden, oder eine neuartige Technologie beherrschen und einsetzen soll. Die Umstellung des Business sollte aber nicht an den Fähigkeiten der Software scheitern. Durch Refactoring wird ein Software System auf solche Fälle durch eine stets an die aktuellen Konzepte angepasste Software Architektur vorbereitet.
Fazit
Die wesentlichen Ziele des Refactoring finden sich in allen Organisationen gleichermaßen wieder. Je nach Geschäftsfall und Unternehmensumfeld können die vier genannten Ziele anders priorisiert sein.
In der Entscheidungsfindung ob eine Software erneuert oder überarbeitet werden soll, wird in vielen Organisationen der dritte Fall übersehen: Der Fall, dass sich gar nichts ändert.
Dieser Fall birgt aber besondere Gefahren in sich und das Verschleppen der Entscheidung macht, wie es bei IT Projekten bekannt ist, die Lage von Monat zu Monat noch schlechter.
Ernste Gefahr Nummer 1: Stillstand der Weiterentwicklung
Die Hauptgefahr von Legacy Systemen ist, dass das gesamte Developerteam damit beschäftigt ist das System irgendwie am Leben zu halten. Die gesamten Ressourcen gehen in Bugfixing, Support und s.g. Hacks: Lösungen die man schnell einbaut, die gewöhnlich unsauber und ungetestet sind und deren Auswirkungen auf das restliche Software unklar bleiben.
Wenn man dem Kunden keine Neuerungen und keine Innovationen bieten kann, fangen diese an sich in der Umgebung nach anderen Lösungen umzuschauen. Die Hürde eines Umstiegs wird schleichend geringer.
Ernste Gefahr Nummer 2: steigende Fehleranfälligkeit
Je schwerfälliger ein bestehendes System ist, desto mehr Fehler treten auf. Je mehr Fehler auftreten desto unzufriedener werden die Benutzer, welche die internen aber in vielen Fällen auch die externen Kunden sind.
Die Unzufriedenheit mit einer Software führen bei internen Kunden zu schlechterer Arbeitsmoral und bei externen Kunden zum Wechsel zur Konkurrenz.
Ernste Gefahr Nummer 3: verpassen des Technologiefortschritt
In der IT Geschichte hat sich eine immer wieder eine neue Technologie rascher durchgesetzt oder alte Systeme rascher abgelöst als man es gewöhnt ist. Wenn man das System nicht aktuell hält, wird der Umstieg schwieriger, weil die Lücke zwischen alter und neuer Technologie zu groß wird. Oft werden Technologie-Umstellungen rasch notwendig um am Markt zu performen.
Wer so eine Umstellung dann nicht schafft, läuft sogar Gefahr sein gesamtes Business zu verlieren. Es muss nicht immer so drastisch sein, doch auch wenn die Konkurrenz die Technologieentwicklung besser mit macht und dadurch z.b. besser für dritte Anwendungen anbindbar ist, wird das zu einem ernsten Faktor für Endkunden einen Umstieg zu erleichtern.
Fazit
Ein System ungewartet dahin dümpeln zu lassen ist auf jeden Fall eine schlechte Idee und kann leider sehr rasch zu ernsthaften Problemen für das bestehende Business werden. Die Kosten einer raschen „Rettung“ sind bekanntlich höher als der nachhaltige solide Weg und daher empfehlen wir ein System regelmäßig zu warten und weiter zu entwickeln.
Wichtig ist, dass man im Refactoring von Legacy Code eine klare Strategie verfolgt und systematisch dabei vorgeht. Ein weitere wesentliche Komponente ist, die Messbarmachung des Fortschritts vom IST zum SOLL.
Phase 1: Bewerten der Lage
In einer ersten Phase wird Bewertet ob und welche Systeme der bestehenden IT Landschaft erneuert, überarbeitet oder eingestellt werden sollen. Dabei ist es notwendig eine ganzheitliche Sicht auf die eingesetzten Applikationen zu erschaffen und dann jeweils methodisch festzustellen, welche Entscheidung getroffen werden muss. In den meisten Fällen spielen Zeit und Kosten die wesentlichen Rollen.
Phase 2: Analyse eines Systems das Refactored werden soll
Sobald ein System zum Refactoring ausgewählt wurde, gilt es eine Analyse durchzuführen, die den IST-Zustand der Software erfasst. Je nach Stand der bestehenden Dokumentation, sind Use Cases und ein Architekturmodell noch zu ergänzen. Zwei wesentliche weitere Analysen beziehen sich auf die Qualität des Source Codes und die Erfassung des vorhandenen KnowHow in der vorliegenden Organisation.
Phase 3: Das SOLL definieren
Je nach System Zustand und Anforderungen an die Überarbeitung der Software können unterschiedliche Ziele für das erwartete Ergebnis gefunden werden. So kann im einen Fall eine Verbesserung der Architektur im Fokus sein und in einem anderen der Umstieg auf eine höhere Version der eingesetzten Programmiersprache; in wieder anderen Fällen liegt die Wartbarkeit im Argen, weil die Source Code Qualität nicht ausreichend ist, sprich der Code nicht lesbar ist.
In dieser Phase werden also Ziele und damit auch die Messbarkeit des Fortschrittes definiert, die Roadmap für das Umsetzungsprojekt aufgeschrieben und insbesondere der Aufwand anhand dieser beiden Grundlagen mit dem Team gemeinsam systematisch abgeschätzt, damit eine Kostenkalkulation möglich wird.
Phase 4: Controlling und Durchführung
Sind alle Rahmenbedingungen für das Refactoring geschaffen, kümmern wir uns um das Controlling des Projektes, welches das Team selbst durchführt. Dabei werden Fortschritte gemessen, Standups moderiert, entstandene Probleme einer Lösung zugeführt und Reports erstellt
Fazit
Insgesamt ist wichtig, Refactoring strukturiert anzugehen und eine klare Vorstellung innerhalb des Teams zu erarbeiten, was der SOLL Zustand ist, und wie man Schrittweise vom IST dort hingelangt. Die vier Phasen sind nochmal aufgelistet:
5 falsche Einschätzung bzgl. Refactoring versus Renewal
Ist Refactoring vs. Renewal eine reine Kostenfrage…?
Irgendwann gelangt man an einen Punkt in einem alten Projekt das „gewachsen“ ist, an dem Fehler in großer Zahl nach Änderungen auftreten und vor allem Änderung maßgeblich aufwändig werden. Der Kunde (egal ob intern oder extern) hat kein Verständnis und das Developer Team gelangt immer mehr in Erklärungsnotstand, warum scheinbar kleine Ergänzungen Tage bis Wochen an Codebasteln und manuelles Testen in Anspruch nehmen.
Ein anderes Szenario ist folgendes. Die Firma die das bestehende System entwickelt hat fällt weg. Der Grund ist unwichtig, oft aber eine Unzufriedenheit wegen des fehlenden Zahlungswillen großer Summen bei kleinen Änderungen des Auftraggebers. Eine neue Firma wird gesucht und alle ausgesuchten Kandidaten kommen zum selben Ergebnis: Das Projekt muss ganz neu gemacht werden. Der Code sei unverständlich, veraltet und zu risikoreich für die Übernahme des Projektes.
Kurzum man steht früher oder später vor der vermeintlichen Entscheidung, ob man das System neu aufbauen muss oder das bestehende überarbeiten kann.
Hier sind die häufigsten Argumente die für das Neuerstellen dabei ins Felde geführt werden
Die nachfolgenden Argumente klingt grundsätzlich mal alle nachvollziehbar und hören sich vorteilhaft an. Die Wahrheit liegt, wie so oft, irgendwo dazwischen und die Konsequenzen der tatsächlichen Umsetzung werden gerne außer Acht gelassen. Ich möchte zu jedem Punkt die fehlerhafte Einschätzung aufzeigen.
1. Wir hätten die Chance das Projekt endlich auf solide Beine zu stelle
Meistens wird die Vorarbeit für dieses Argument übersehen. Dazu gehört das Erfassen der Funktionen, das aufschreiben einer Dokumentation, die Befragung der Benutzer usw.
Dazu kommt der Personalmangel, da das ganze Team die bestehenden Systeme betreut. Wer macht denn dann die neue Software? Im schlimmsten Fall entscheidet man sich für eine externe Firma, das dazu führt, dass am Ende der Neuentwicklung das Team ein System übergeben bekommt, dass sie nicht kennen und frustriert ist, weil die „schöne Arbeit“ des Entwickeln von der grünen Wiese weg jemand anderer machen durfte.
2. Unit Tests könnten endlich eingeführt werden
Aufgrund der fehlenden Ressourcen werden oft wieder keine Unittests eingeführt und die Dokumentation wird wieder weggelassen. Hier findet meistens keine Verbesserung statt.
3. Die Kosten sind geringer als weiterhin den schleppenden Betrieb zu bezahlen.
Sie müssen sich vorstellen, dass der aktuelle Betrieb schon teuer ist, d.h. die Ressourcen werden zu großen Teilen bereits verwendet und ohne weiteres Personal ist das Erneuern nicht rasch durchzuführen sondern dauert womöglich Jahre. Also unterm Strich sind die Kosten für die Erneuerung meistens höher, wenn man den Betrieb mit in die Kalkulation nimmt.
4. Man kann nach dem Neubau viel leichter Änderungen oder Neuerung einzubauen
Das ist auch ganz sicher der Fall, aber es führt dazu, dass neue Features im bestehenden Betrieb nicht implementiert werden, damit man keine Arbeit doppelt macht. Da die Erneuerung aber lange Zeit in Anspruch nimmt, werden alle Kunden auf später vertröstet und die Frustration mit dem Bestandsystem steigert sich weiter.
5. Man könnte beim Neubau gleich die Features aus der Pipeline/ dem Backlog mit einbauen (und alte Features weg lassen)
Auf Platz eins der Prioritätenliste des Neubaus steht, die Wiederherstellung der Funktionen des bestehenden Systems. Bevor das neue System nicht zumindest das gleiche kann wie das alte, werden keine weiteren Funktionen ergänzt. D.h. man wartet als Kunde, ähnlich wie bei Punkt 5, sehr lange auf neue Funktionen.
Zu diesen 5 Punkten kommt die Migration der Daten vom alten in ein neues System, die dann auch parallel gepflegt werden. Wenn ein vorgegebener Stichtag näher rückt, werden wieder Notlösungen im neuen System geschaffen, damit das System zum Tag X einsatzbereit ist. Die Spirale beginnt dann von Neuem.
Nach einiger Zeit wird es dann eine Neue Version geben, die aber weder erprobt noch vollständig sein wird. Meistens entscheidet man sich dann für einen Parallelbetrieb, der noch stärker in die Ressourcen eingreifen wird, als der bisherige Parallele Entwicklungsbetrieb.
Fazit
Auch wenn Renewal gut klingt, unterm Strich ist die Umsetzung teuer und die Machbarkeit ungewiss. Eine Schrittweise und kontrollierte Überarbeitung des bestehenden Codes ist daher meistens die bessere Entscheidung.
Wir helfen Ihnen gerne bei der Strategie und Planung um ihr Legacy System wieder zu dem Value Zugpferd zu machen, dass es am Anfang war mit der Möglichkeit es sauber weiter zu entwickeln.
Man hat nur Angst, wenn man mit sich selber nicht einig ist. (Hermann Hesse)
Meine persönliche Erfahrung ist, dass das Refactoring aus den folgenden gründen vermieden wird:
das Developer Team muss sich kritisch mit den eigenen Fehlern in der Vergangenheit befassen
es gibt keinen Plan, wie man im Refactoring vom IST zum SOLL Zustand gelangt
Es gibt keine Strategie, wie man Refactoring und Deployments gemeinsam betreibt
die Prioritäten, was man zuerst umbauen will sind unklar
die Angst, das Refactoring nicht zu Ende zu bringen verhindert das Beginnen
Unsere Mission ist, einem Unternehmen dies genannten Punkte durch methodisches Vorgehen und klare Planung und Abschätzung aus dieser Pattstellung heraus zu führen. Denn klar ist, dass die parallele oder ausgelagerte Erneuerung wesentlich teurer sein kann und auch hier ist der Ausgang nicht vorhersehbar.
Der große Vorteil vom Refactoring ist, dass es keinen System-Wechsel gibt, der unvorhersehbare Probleme mit sich bringen kann. Wichtig zu verstehen ist, der Prozess wird dennoch viel Zeit in Anspruch nehmen, birgt aber große Chancen für das Developer Team, was das Erlernen von Neuem betrifft, was wiederum zu Zufriedenheit führen wird.
