Codequalität in Alt- und Wartungsprojekten

Codequalität in Alt- und Wartungsprojekten

Daniel Winter


Sobald alle Stories abgeschlossen, Features programmiert, Testfälle bestanden sind und die Software erfolgreich beim Kunden ihren Dienst verrichtet, beginnt die längste und wohl zäheste Phase im Softwareleben: die Wartung. Diese ist meist durch das Beheben von Fehlern gekennzeichnet (Abb. 1). Dabei kann zu Beginn noch auf das umfassende Fachwissen der ursprünglichen Entwickler zurückgegriffen werden, die nicht nur bestimmte Architekturentscheidungen getroffen haben, sondern auch die fachliche Qualifikation besitzen, auftretende Fehler schnell zu identifizieren und zu beheben. Mit der Zeit jedoch geht dieses Wissen verloren, sei es durch die Bearbeitung von zahlreichen neuen Projekten oder durch die Fluktuation bei den Mitarbeitern selbst. Neue, motivierte Entwickler kommen mit der nun schon in die Jahre gekommenen Software in Kontakt und müssen die aktuellen Fehler bearbeiten oder sogar neue Erweiterungen implementieren und testen.

ArtikelserieTeil 1: Erste Lösungsansätze mit Checkstyle, PMD und einem Code FormatterTeil 2: Höhere Testabdeckung mit Mockito

Abb. 1: Lebenszyklus der Software, unterteilt in Entwicklung und Wartung

Never change a running system

Am einfachsten und für die neuen Mitarbeiter wahrscheinlich auch am reizvollsten wäre eine komplette Neuimplementierung der Anwendung. Nicht nur könnte man so alle alten Fehler korrigieren; es bestünde auch noch die Möglichkeit, moderne Technologien einzusetzen, neue Frameworks zu evaluieren und aktuelle Entwurfsmuster (Design-Patterns) in die Architektur mit einfließen zu lassen. Insgesamt, so die Intention, würde die Anwendung schneller reagieren, besser aussehen, Erweiterungen wären einfacher zu realisieren und das verloren gegangene Fachwissen im Unternehmen wäre wiederhergestellt.

Die Realität sieht jedoch anders aus. Anwendungen, die bereits seit Jahren erfolgreich und ohne größere Probleme in Unternehmen eingesetzt werden, werden nicht einfach ausgetauscht. Dabei spielen nicht nur die auftretenden Kosten einer kompletten Neuentwicklung eine Rolle. Hinzu kommt, dass der Kunde schlicht keinen Sinn darin sieht, ein Produkt ein zweites Mal entwickeln zu lassen, das bereits existiert, tief in die eigene Systemlandschaft integriert ist und mit dem die Mitarbeiter nach langer Einarbeitungszeit vertraut sind. Getreu dem Motto „Never change a running system“.

Mit Ausdauer zur Codequalität

Die Hauptaufgabe der neuen Entwickler ist es deshalb, das alte System am Leben zu erhalten. Um Fehler zu beheben, muss man ...

Codequalität in Alt- und Wartungsprojekten

Codequalität in Alt- und Wartungsprojekten

Daniel Winter


Sobald alle Stories abgeschlossen, Features programmiert, Testfälle bestanden sind und die Software erfolgreich beim Kunden ihren Dienst verrichtet, beginnt die längste und wohl zäheste Phase im Softwareleben: die Wartung. Diese ist meist durch das Beheben von Fehlern gekennzeichnet (Abb. 1). Dabei kann zu Beginn noch auf das umfassende Fachwissen der ursprünglichen Entwickler zurückgegriffen werden, die nicht nur bestimmte Architekturentscheidungen getroffen haben, sondern auch die fachliche Qualifikation besitzen, auftretende Fehler schnell zu identifizieren und zu beheben. Mit der Zeit jedoch geht dieses Wissen verloren, sei es durch die Bearbeitung von zahlreichen neuen Projekten oder durch die Fluktuation bei den Mitarbeitern selbst. Neue, motivierte Entwickler kommen mit der nun schon in die Jahre gekommenen Software in Kontakt und müssen die aktuellen Fehler bearbeiten oder sogar neue Erweiterungen implementieren und testen.

ArtikelserieTeil 1: Erste Lösungsansätze mit Checkstyle, PMD und einem Code FormatterTeil 2: Höhere Testabdeckung mit Mockito

Abb. 1: Lebenszyklus der Software, unterteilt in Entwicklung und Wartung

Never change a running system

Am einfachsten und für die neuen Mitarbeiter wahrscheinlich auch am reizvollsten wäre eine komplette Neuimplementierung der Anwendung. Nicht nur könnte man so alle alten Fehler korrigieren; es bestünde auch noch die Möglichkeit, moderne Technologien einzusetzen, neue Frameworks zu evaluieren und aktuelle Entwurfsmuster (Design-Patterns) in die Architektur mit einfließen zu lassen. Insgesamt, so die Intention, würde die Anwendung schneller reagieren, besser aussehen, Erweiterungen wären einfacher zu realisieren und das verloren gegangene Fachwissen im Unternehmen wäre wiederhergestellt.

Die Realität sieht jedoch anders aus. Anwendungen, die bereits seit Jahren erfolgreich und ohne größere Probleme in Unternehmen eingesetzt werden, werden nicht einfach ausgetauscht. Dabei spielen nicht nur die auftretenden Kosten einer kompletten Neuentwicklung eine Rolle. Hinzu kommt, dass der Kunde schlicht keinen Sinn darin sieht, ein Produkt ein zweites Mal entwickeln zu lassen, das bereits existiert, tief in die eigene Systemlandschaft integriert ist und mit dem die Mitarbeiter nach langer Einarbeitungszeit vertraut sind. Getreu dem Motto „Never change a running system“.

Mit Ausdauer zur Codequalität

Die Hauptaufgabe der neuen Entwickler ist es deshalb, das alte System am Leben zu erhalten. Um Fehler zu beheben, muss man ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang