Suchen

Softwarequalität

Legacy-Code ist eine tickende Zeitbombe

Seite: 5/5

Firmen zum Thema

Metriken für Code-Qualität

Verstehen die Unternehmen denn, dass bei ihnen im Keller eine Zeitbombe tickt?

Immer mehr verstehen es. Eine Reihe von Interessenten oder gar Bestandskunden sagen zu uns: „Wir wissen, dass wir ein großes Problem mit unserem bestehenden Code haben.“ Das heißt, dass sie wissen, dass sie ein Qualitätsdefizit haben.

Jeder, der Code produziert, weiß, wo die Probleme liegen. Deshalb arbeiten wir zur Zeit einem webbasierten Qualitätsmonitor für VectorCast Analytics. Er erlaubt Ihnen auf sehr einfache Weise Qualitätsmerkmale zu prüfen, etwa die Komplexität, die Größe oder die Kommentardichte. Das erlaubt Ihnen zu sehen, wo Sie stehen und worauf Sie sich konzentrieren sollten.

Denn bei dem Bestandscode-Problem stellt sich jeder die Frage, wo man anfangen soll. Selbst mit Werkzeugen zur statischen Analyse bekommt man ja Millionen von Bugs angezeigt. Man kann sie aber nicht alle auf einmal fixen. Die Zeit reicht einfach nicht. Aber wir können unsere begrenzten Ressourcen intelligent an der Stelle einsetzen, wo es am meisten nützt.

Die Analyse zeigt zum Beispiel anhand von Farben die Codeabdeckung an. Jetzt habe ich etwa ein richtig komplexes Symbol, das komplett rot eingefärbt ist. Das zeigt Ihnen, dass es sehr komplex ist und dass die Komponente kaum getestet wurde. Wenn Sie ganz kleine Symbole haben, die alle grün sind, dann haben Sie die einfachen Sachen getestet. Sie sollten sich also auf die schwierigen Dinge konzentrieren.

Eine andere Analyse, die Sie vornehmen können: Welcher Code ändert sich am häufigsten? Wenn sich Module jeden Tag verändern, dann sind das mit einiger Wahrscheinlichkeit Ihre Sorgenkinder. Denn wenn sich diese Module jeden Tag ändern, dann fügen Sie entweder jeden Tag neue Funktionen hinzu oder Sie reparieren eine ganze Menge Fehler.

Eine andere interessante Sache ist: Wieviel Zeit verwenden die Entwickler darauf, Bugs zu fixen? Wir wollen ja, dass unsere Entwickler neue Software erstellen, neue Funktionen, die die Kunden zufriedenstellen. Aber wenn wir an den Punkt kommen, an dem die Entwickler zu 90 oder zu hundert Prozent Fehler beheben, dann sind wir gefesselt, nicht wahr? Wenn Sie ein Bauunternehmen wären und Ihre Mitarbeiter würden zu 90 Prozent löchrige Dächer stopfen oder Rohre reparieren, die nicht richtig installiert wurden, dann wären Sie schnell pleite.

Denn bei der Software wird so gearbeitet, als würden wir beim Hausbau nicht auf Qualität achten und dann die Wände einreißen und die löchrigen Röhren reparieren. Sie würden ja auch kein Set von acht Gläsern herstellen, die alle unterschiedlich hoch sind. Ich bin mir sehr sicher, dass die Glasfabrik nicht zuerst die Gläser herstellt und dann alle wegwirft, die nicht die richtige Höhe haben.

Aber im Softwarebereich machen wir das! Wir finden hinterher die Fehler und dann patchen wir sie! Und ziemlich oft ruinieren wir damit das ursprüngliche Design! Ich habe gestern in meinem Vortrag einen Witz gemacht: Wenn man einen Entwickler fragt, wie er mit dem neuen Feature vorankommt, dann sagt er: „Gut, wir sind zu 90 Prozent fertig. Wir müssen nur noch testen." Realistisch betrachtet ist er zu 30 Prozent fertig.

Bieten Sie diesen Service vor allem Herstellern von Embedded-Software an oder gehen Sie auch auf traditionelle IT-Firmen zu?

Wir sprechen die [traditionellen IT-Firmen] nicht an, denn unsere Domänen-Expertise liegt ganz klar im Embedded-Segment.

Ein Bekannter von mir schreibt Code für ein Maschinenbauunternehmen. Er ist aber nie zu einem Seminar für Embedded-Softwarearchitektur geschickt worden, weil er und seine Kollegen den Code quasi ad hoc entwickeln müssen. Der Code wächst quasi organisch.

Ja. Ohne jede Richtung, ohne Maß und Ziel. Das ist doch verrückt. Weiß Ihr Bekannter auch, dass das verrückt ist?

Ja. Er weiß, dass er und seine Kollegen eigentlich einen viel systematischeren Ansatz bräuchten. Aber dafür fehlt die Zeit. Und das Team kann kein Mitglied entbehren, um ihn oder sie auf einen Kurs oder ein Seminar zu schicken.

Oder wenigstens einen Schritt zurückzutreten und zu überdenken, was man gerade tut. Vielleicht wäre es hilfreich, die Deming-Philosophie zu verwenden, bei der es um schrittweise Verbesserung geht. Deming war ein Management-Theoretiker, der Japan in den 1950-er Jahren beigebracht hat, Produkte effizient zu fertigen.

Nach dem Zweiten Weltkrieg lag die japanische Wirtschaft ja in Trümmern. Als sie mit dem Wiederaufbazu begannen, sagten sie sich: Es muss einen besseren Weg als den herkömmlichen geben. Zuvor hatten sie folgendermaßen gearbeitet: „OK, jetzt haben wir all diese Füllfederhalter produziert, jetzt schauen wir, welche in Ordnung sind und werfen wir die weg, die fehlerhaft sind.“

(ID:44562071)