Florian Klein vom VDMA Landesverband Baden-Württemberg und Jakob Albert vom VDMA Fachverband Software und Digitalisierung haben mit Sebastian Betzin von generic.de und mit Wolfram Schäfer von iT Engineering Software Innovations über das Thema Softwarequalität und Clean Code gesprochen.
Je komplexer und langfristiger Softwareprojekte angelegt werden, desto wichtiger ist die Sicherstellung einer hohen Softwarequalität. Niedrige Softwarequalität rächt sich mit der Zeit. So können neue Features zu Beginn noch relativ einfach implementiert werden, aber mit jeder Veränderung am Quellcode steigt auch der Entwicklungsaufwand für die nächste Änderung. Und wenn nicht sorgfältig gearbeitet wird, wachsen Entwicklungszeit und -kosten mit jedem neuen Feature im schlimmsten Fall exponentiell an. Im Fokus steht vor allem die Nachhaltigkeit. Softwarelösungen müssen heutzutage flexibel auf Veränderungen reagieren können – und das ohne Unmengen an Kosten für Code-Anpassungen zu verschlingen. Wir haben darüber mit Sebastian Betzin und Wolfram Schäfer gesprochen.
VDMA: Wodurch definiert sich Softwarequalität bzw. was ist Clean Code? Und worin unterscheiden sich innere und äußere Softwarequalität?
Sebastian Betzin: Softwarequalität an sich definiert sich erst einmal durch zwei Qualitätsmerkmale: durch innere und äußere Qualität. Äußere Qualität ist im Grunde all das, was man von außen wahrnehmen kann, vom User her. Sprich: Skalierbarkeit, Funktionalität und im Grunde alles, was ich als Anwender mit Sicht von außen als Software wahrnehme. Und das Zweite, was eben vom Entwickler generiert und wahrgenommen wird, ist innere Softwarequalität. Dann gibt es ganz viele andere Merkmale. So rein formal: Das, was von außen wahrgenommen wird, ist das, was wir in der Softwarequalitätsabteilung testen. Innere Qualität ist sozusagen das Fundament der Software.
Wolfram Schäfer: An der Stelle ist zu erwähnen, dass eigentlich die wahren Qualitätsmerkmale eher die inneren Qualitätswerte sind und aus unserer Sicht sind es hauptsächlich Wartbarkeit und Erweiterbarkeit, wie wir in den letzten 20 Jahren immer wieder gelernt haben. Jeder kennt dieses Eisbergmodell: Das was oberhalb der Wasserlinie ist, ist vielleicht die äußere Qualität von Wahrnehmung und Aufwand. Und der Berg darunter, das ist die innere Qualität.
VDMA: Was sind Ihrer Meinung nach die drei wichtigsten Kriterien für Softwarequalität? Wie wird Softwarequalität messbar?
Sebastian Betzin: Nachvollziehbarkeit, Evolvierbarkeit und eigentlich auch Testbarkeit. Also Testbarkeit in Form von automatisierten Softwaretests. Keine Oberflächentests oder manuelle Tests. Das sind für mich die absoluten Gewinner. Nachvollziehbarkeit deswegen, weil wir uns als Software-Entwickler immer damit beschäftigen, Software, also Quellcode, zu lesen. Egal ob ich eine Neuentwicklung mache oder an etwas Bestehendem weiterentwickle. Das heißt: Nachvollziehbarkeit von Quellcodes ist das Wichtigste überhaupt.
Wolfram Schäfer: Lesbarkeit, Nachvollziehbarkeit, genau das grenzt wieder ab zum Thema Dokumentation. Früher hat man dicke Bücher gelesen: “Wie muss ich Softwarequellcode dokumentieren?” Aus meiner Sicht ist das heute überholt. Der Quellcode muss für jeden am Projekt Beteiligten lesbar und verständlich nachvollziehbar sein. Darauf kommt es im Wesentlichen wirklich an: Evolvierbarkeit, Erweiterbarkeit. Ich glaube gerade im Maschinenbau ist das wichtig, weil wir dort doch sehr lange Produktlebenszyklen haben und wir häufig die Aufgabe haben tatsächlich auch in älteren Softwareständen nochmal etwas weiterzuentwickeln. Wie wird Softwarequalität also messbar? Rein Testen macht Softwarequalität nicht messbar. Deshalb sind Metriken für Softwarequalitätsmaßstäbe schwierig.
Sebastian Betzin: Also ich würde da ergänzen: Es gibt zwei Betrachtungsweisen: Man kann einerseits natürlich statische Codeanalysen fahren mit Hilfe von Tools. Das hilft auf jeden Fall, um Code-Smells und die typischen Fehler in den Griff zu kriegen. Das deckt aber nur einen Teil der Wahrheit ab. Es bezieht sich sozusagen sehr auf den syntaktischen Baum des Quellcodes. Was nicht oder noch nicht messbar ist, ist die semantische Codequalität. Also alles was Lesbarkeit und Nachvollziehbarkeit betrifft, ist dort nicht abgedeckt: Sind die Methoden gut benannt? Sind die Klassen gut benannt? Spiegeln sie die Domänensprache wider? Ist es in sich schlüssig? Das ist noch nicht messbar. Das geht nur über manuelle Code-Reviews. Zusammenfassend ist deswegen Softwarequalität lediglich teilweise messbar. Im Übrigen: Softwarequalität kann auch auf Low Code-Anwendungen übertragen werden. Teilweise sind die Themen Nachvollziehbarkeit und Lesbarkeit auch absolut als Qualitätsmerkmal gegeben. Ich kann auch in Low Code Anwendungen ziemlichen semantischen Schrott programmieren, den nachher niemand mehr versteht.
Sebastian Betzin (Quelle: generic.de software technologies AG)
Sebastian Betzin ist Vorstand und CTO der generic.de software technologies AG. Als studierter Wirtschaftsinformatiker ist er nach wie vor begeisterter Softwareentwickler aus Leidenschaft. Er ist stellvertretender Vorstandsvorsitzende des Fachverbandes „Software und Digitalisierung” des VDMA und engagiert sich in der Initiative Clean Code Development (CCD). Das Thema Softwarequalität bzw. Clean Code liegt ihm besonders am Herzen.
Wolfram Schäfer (Quelle: iT Engineering Software Innovations GmbH)
Wolfram Schäfer ist Gründer und geschäftsführender Gesellschafter bei iT Engineering Software Innovations GmbH. Als Maschinenbauingenieur und studierter Informatiker ist er seit über 25 Jahren an der Schnittstelle zwischen Maschinenbau und IT tätig. Er ist Teil des Vorstands im Fachverband „Software und Digitalisierung“ des VDMA sowie Industrie 4.0-Scout der Allianz Industrie 4.0 Baden-Württemberg. Mit Herzblut engagiert er sich besonders für die Themen Softwareengineering, Softwarequalitätssicherung und agile Softwareentwicklung.
VDMA: Wodurch entsteht „technische Schuld“, wie kann diese verhindert und wieder abgebaut werden?
Wolfram Schäfer: Technische Schuld baut sich dadurch auf, dass Anforderungen teilweise nicht wirklich gut spezifiziert werden. Oftmals fehlt die Bereitschaft, am Anfang Aufwand in Qualität zu investieren. Wir haben es schon oft erlebt, dass der Kunde gar nicht bereit ist, für das Thema innere Qualität auch Geld auszugeben. Damit wird eigentlich erst diese technische Schuld aufgebaut, vergleichbar mit finanziellen Schulden, Zinsen und Zinseszinseffekt. Wenn man genau diese längere Lebensdauer von Software hat, dann kann das echt zu einer Zinsfalle werden, dass man am Ende nur noch seine Schulden tilgt oder für seine Zinsen arbeitet und damit die Entwicklungsgeschwindigkeit in den Keller geht.
Sebastian Betzin: Technische Schuld entsteht dann, wenn kein Fokus auf innerer Qualität vorhanden ist. Und dies entsteht dann, wenn das Projekt es nicht zulässt. Das heißt, wenn im Projekt die anderen Rahmenbedingungen wie Umfang und Zeit von außen vorgegeben sind. Durch den dadurch entstehenden Druck wird die innere Qualität vernachlässigt. Technische Schuld ist somit eine aufgeschobene Investition in innere Qualität. Das geht eine ganze Weile gut, solange bis die technische Schuld so hoch ist, dass es Auswirkungen auf das Projekt hat. Warum? Weil ich als Entwickler in einen Bestandscode rein gehe und einen nicht optimalen Quellcode vorfinde, der nicht ganz lesbar, nicht ganz nachvollziehbar und nicht ganz testabgedeckt ist. In diesem Code Änderungen vorzunehmen, dauert einfach länger als in einem guten Code. Und dann kommen solche Effekte zum Tragen: Dann mache ich Sachen nicht mehr sauber, sondern programmiere ein wenig drumherum, bekomme es doch zum Laufen und somit potenzieren sich die Mängel in der Software.
Wolfram Schäfer: Und das ist im Grunde in der Entwicklungsgeschwindigkeit nachher wieder schwer messbar, aber spürbar. Ich würde sagen, jeder Entwickler weiß, wenn er technische Schulden aufbaut. Da hat er ein schlechtes Gefühl und kann es dann auch nicht kompensieren. Dadurch sinkt am Ende die Entwicklungsgeschwindigkeit. Irgendwann bin ich dann nur noch damit beschäftigt, meine Schulden zu tilgen und komme gar nicht mehr in der Evolvierbarkeit oder Erweiterbarkeit von meiner Software voran. Das heißt, ich verwende ein viel zu hohes Budget oder viel zu viele Entwickler darauf, die Software mehr oder weniger am Laufen zu halten. Damit wiederum schließt sich der Kreis zu den Kosten, weil man am Anfang nicht bereit ist, den Aufwand schlussendlich auch einzugehen. Wenn ich anfangs in eine saubere Architektur, ein sauberes Konzept sowie einen sauberen und agilen Prozess investiere, habe ich zunächst vielleicht eine langsamere Entwicklungsgeschwindigkeit, aber am Ende eine sehr viel höhere Qualität. Da hat sich in den letzten Jahren auch viel verändert. Es gibt dort heute ein anderes Bewusstsein. Viele haben auch eine andere Wertschätzung gegenüber Software, gerade im Maschinenbau. Insofern sind wir auf einem guten Weg.
VDMA: Was sind aus Ihrer Sicht die wichtigsten Verfahren, um eine hohe Qualität Ihrer Software zu gewährleisten?
Sebastian Betzin: Hierbei muss man zwei Ebenen betrachten: Zum einen muss das Entwicklungsteam verstehen, was Qualitätsfaktoren sind und wie man diese erreicht. Innere Qualität also. Außerdem müssen die Rahmenbedingungen so gestaltet sein, dass das Team dies auch umsetzen kann. Das muss sowohl vom Produktmanagement, vom Teamsetup und von der Entscheidungsebene unterstützt werden. Es muss auch Wert auf Qualität gelegt werden. Der äußere Projektdruck entsteht nicht durch das Entwicklerteam, sondern von außen. Beide Sachen müssen zutreffen, damit ich gute Qualität umsetzen kann.
Wolfram Schäfer: Um eine hohe Qualität zu gewährleisten, sind agile Vorgehensmodelle wie beispielsweise Scrum wichtig. Unsere Erfahrung zeigt, dass toolgestützte Code-Reviews vermutlich der beste Ansatz und der früheste Ansatz sind, wirklich auf Qualität zu achten, gefolgt von automatisierten Tests und automatischen Deployment. Man muss da am Ball bleiben. Kontinuierliches Refactoring, kontinuierliche Restrukturierung meiner Software ist ein Must-have. Man vergleicht oft Software mit Architektur: eine Instandhaltung meiner Wohnung oder meines Hauses in Form von Renovierungsarbeiten beispielsweise betreibe ich auch kontinuierlich. Das kann man auf die Software übertragen, nur noch viel intensiver, weil es dort um einiges komplexer ist.
VDMA: Nach welchen Methoden entwickeln Sie? Wie kann die Wahl der richtigen Entwicklungsmethode die Softwarequalität beeinflussen?
Wolfram Schäfer: Bleibt noch was anderes übrig als agil?
Sebastian Betzin: Na ja, ich kann auch im Wasserfall Softwarequalität verankern. Das geht auch. Wobei es da tatsächlich schwieriger ist. Ich kann aber auch schlechten Code mit agilen Methoden produzieren.
Wolfram Schäfer: Das stimmt natürlich.
Sebastian Betzin: Es geht beides. Agil, würde ich sagen, kann die Entwicklung von gutem Code fördern. Allerdings nur, wenn das Bewusstsein im Team vorhanden und fest verankert ist.
Wolfram Schäfer: Ich denke, dass agile Methoden die Möglichkeiten bieten, es zu verankern. Wenn ich alles unter einem anderen Label mache, dann komme ich auch wieder bei einem ähnlichen Prozess raus. Ich brauche klar definierte Strukturen und Prozesse, wie man sie auch vom agilen Arbeiten kennt. Mit all den Schwierigkeiten, die es dann natürlich auch gibt. Es wird dann nicht plötzlich alles gut.
Sebastian Betzin: Also nur weil ich etwas agil mache, habe ich nicht automatisch gute Softwarequalität. Der Eindruck darf nicht entstehen.
VDMA: Vielen Dank an Sie beide für das Interview.
Dieses Interview wurde von dem VDMA Fachverband Software und Digitalisierung, dem VDMA Landesverband Baden-Württemberg und dem Mittelstand 4.0-Kompetenzzentrum Stuttgart durchgeführt.
Kontakt:
Florian Klein
VDMA Landesverband Baden-Württemberg
florian.klein@vdma.org
(+49 711) 2 28 01-18
