14.7.22
Development
Clean Code

Software­qualität: Kriterien „guter“ Software­produkte und die Rolle von Clean Code

Softwarequalität - fragt man den Otto­normal­verbraucher, was man darunter versteht, sind die häufigsten Antworten wohl: „Die Software tut, was sie tun soll.“, „Man findet sich gut zurecht.“ oder „Die Oberflächen sehen schick aus.“ Zurecht. Schließlich sind es am Ende die Anwender:innen, die die Software­lösung nutzen. Jedoch ist das nur eine Seite der Medaille. Auf welche Software­qualitäts­merkmale und -kriterien es aus technischer und wirtschaftlicher Sicht ankommt und wie Clean Code Development dabei helfen kann, die Software­qualität zu maximieren, ist Gegen­stand dieses Artikels.


  1. Was bedeutet gute Softwarequalität eigentlich?
    1.1 Äußere Softwarequalität
    1.2 Innere Softwarequalität
  2. Warum Software­qualität so wichtig für die Wirtschaftlich­keit ist
  3. Merkmale guter (innerer) Software­qualität
    3.1 Lesbarkeit
    3.2 Nachvollziehbarkeit
    3.3 Testbarkeit
    3.4 Wiederverwendbarkeit
    3.5 Evolvierbarkeit
  4. Wie Clean Code Development die innere Software­qualität optimieren kann

1. Was bedeutet gute Software­qualität eigentlich? 

Was gute Software­qualität auszeichnet, hängt am Ende damit zusammen, wen man fragt. So beurteilen die Anwender:innen die Funktionalität und Benutzer­freundlichkeit, Solution Architects den Aufbau der Entitäten, die Software­entwickler:innen die Güte des Quellcodes, Admins die Support­fähigkeit, Produkt­manager den Funktions­umfang usw. Für eine bessere Einordnung lohnt es sich daher den Begriff Software­qualität aufzuteilen: in die äußere und die innere Softwarequalität.

1.1 Äußere Software­qualität

Die äußere Software­qualität beschreibt die Perspektive von außen auf die Software. Wie stabil und zuverlässig läuft die Anwendung? Wie schnell reagiert die Software? Wie intuitiv und benutzer­freundlich sind die Ober­flächen gestaltet? Welche Funktionalitäten sind abgedeckt? Wie sicher ist das System vor Angriffen? Die wichtigsten Merkmale sind demnach: Funktionalität, Benutzbarkeit, Zuverlässigkeit, Robustheit, Performance und Sicherheit.

Übrigens: Auch eher qualitative Qualitätsmerkmale wie Benutzerfreundlichkeit sind validierbar. Wie UX Design objektiv getestet werden kann, erläutert unser Head of UX Design Uwe Betzin hier: (UX) Design muss funktionieren

Laptop mit einem Dashboard und Ausigelungen: Zuverlässigkeit, Sicherheit, Benutzbarkeit, Skalierbarkeit, Funktionalität, Effizienz
Äußere Softwarequalität: die Perspektive der User

1.2 Innere Software­qualität

Die innere Software­qualität beschreibt die Perspektive nach innen – also auf Architektur, Design und Güte des Quell­codes. Wie einfach lässt sich der Code lesen und verstehen? Wie gut lässt sich der Code umschreiben, modifizieren und erweitern? Welche Abhängig­keiten gibt es? Wie hoch ist die Test­abdeckung? Die wichtigsten Merkmale sind: Lesbarkeit, Nachvollzieh­barkeit, Test­barkeit, Wieder­verwend­barkeit und Evolvier­barkeit.

Laptop mit Quellcode und Ausigelungen: Lesbarkeit, Nachvollziehbarkeit, Testbarkeit, Evolvierbarkeit
Innere Softwarequalität: die Perspektive der Softwareentwickler:innen

2. Warum Software­qualität so wichtig für die Wirtschaftlich­keit ist

Selbstredend sind äußere Qualitäts­merkmale, wie ein korrekter Funktions­umfang, Zuverlässigkeit oder Benutzer­freundlichkeit wichtige Kriterien, wenn es um die Wirtschaftlich­keit einer Lösung geht. Schließlich muss der Output des Software­produkts, bspw. Effizienz­steigerungen, nach einer gewissen Zeit die entstandenen Entwicklungs­aufwand übersteigen, um einen positiven ROI zu gewährleisten. Jedoch darf bei dieser Rechnung die Product Lifetime und damit der Blick in die Zukunft nicht außer Acht gelassen werden. Denn so schnell wie sich heut­zutage Prozesse, Technologien und sogar ganze Business­modelle ändern, so rasant ändern sich auch die Anforderungen an die Software. Das bedeutet im Umkehr­schluss: die Lösung muss sich auch wirtschaftlich weiter­entwickeln, anpassen oder verändern lassen. Und genau hier kommt es auf die inneren Qualitätsmerkmale an.

Wird die innere Software­qualität vernachlässigt, kommt es im Laufe der Entwicklung zu technischer Schuld. Und diese Schuld wächst mit jeder Änderung an. Mit ihr wächst auch der Arbeits­aufwand für Änderungen am Quell­code – und zwar nicht linear, sondern exponentiell. Das unvermeidbare Ende in vielen Fällen: Die Software­lösung kann gar nicht mehr weiter­entwickelt werden und muss von Grund auf neu geschrieben werden. Um dies zu verhindern und um Software­lösungen zu entwickeln, die über einen längeren Zeit­raum im Betrieb sein sollen, muss auch die innere Software­qualität auf einem hohen Niveau sein. Und das von Beginn an.

Diagramm: Entwicklungskosten für jedes neue Feature. Bei schlechter innerer Qualität nehmen die Kosten exponentiell zu
Je komplexer und langlebiger eine Anwendung ist, desto eher lohnt es sich in innere Softwarequalität zu investieren

3. Merkmale guter (innerer) Softwarequalität

3.1 Lesbarkeit

Quellcode wird deutlich öfter gelesen als geschrieben. Hierbei haben sich syntaktische Normen und Konventionen etabliert, an die es sich zu halten gilt. Man könnte es vergleichen mit einer hoch­deutschen Schreib­weise nach Duden. Diese sind wir gewohnt zu lesen und können Sie daher schnell erfassen. Laut­schrift dagegen vermittelt zwar die gleiche Bedeutung, da wir es aber nicht gewohnt sind sie zu lesen, dauert es erheblich länger sie zu entziffern. Das gleiche gilt für Quell­code: Schreiben alle in der gleichen Form und Syntax, findet man sich deutlich schneller zurecht.

3.2 Nachvollziehbarkeit

Fast noch wichtiger als die Syntax ist jedoch die Semantik. Software­entwickler:innen verbringt 70 bis 90% ihrer Arbeitszeit damit, Quell­code zu lesen und zu verstehen. Wirklich produktiv genutzt werden also lediglich 10 bis 30% der Zeit. Um dieses Verhältnis zu optimieren, ist es unerlässlich, dass der Code semantisch nachvoll­ziehbar ist. Das bedeutet, dass man dem Code ansehen können muss, was er tut und wieso er es tut – was auch eine Verknüpfung der Kunden­anforderungen mit dem Code impliziert.  

Syntaktische Lesbarkeit und semantische Nachvollziehbarkeit sind elementare Merkmale innerer Softwarequalität

3.3 Testbarkeit

Genauso wichtig, wie die Lesbarkeit und Nachvoll­ziehbarkeit, ist es aber auch, dass der Code funktional korrekt arbeitet. Um dies nicht nur gewährleisten, sondern auch garantieren und nachweisen zu können, ist eine hohe Test­abdeckung elementar. Über automatisierte Tests muss der Quellcode in seinen kleinsten Teilen, bspw. über Unit-Test, wie auch in seiner Gesamtheit, bspw. über Integrations-Tests, jederzeit über­prüfbar sein. Nur so kann sicher­gestellt werden, dass Änderungen nicht zu Regression führen.

3.4 Wiederverwendbarkeit

Softwarekomponenten sollten so implementiert werden, dass sie wieder­verwendet werden können. Das hat gleich mehrere Vorteile: Zum einen wird dadurch Code-Duplizierung reduziert, was den Quell­code schlanker und effizienter macht. Zum anderen werden durch Wieder­verwendung gleicher Code­bestandteile mögliche Fehler­quellen reduziert, wodurch der Wartungs­aufwand deutlich verringert werden kann.

3.5 Evolvierbarkeit

Der Begriff evolvieren leitet sich vom Wort Evolution ab und beschreibt die Fähigkeit eines Lebe­wesens, sich durch Gen­veränderungen an neue Umwelt­faktoren anzupassen. Bezogen auf Software bedeutet Evolvierbarkeit, dass Quellcode so designt wird, dass er jederzeit flexibel modifiziert werden kann. So kann bspw. ein neues Feature zu einem späteren Zeit­punkt im Entwicklungs­projekt mit geringerem Aufwand umgesetzt werden, als wenn es von Anfang an gefordert gewesen wäre.

Evolvierbarkeit: Die Fähigkeit sich durch Modifizierung (der DNA / des Quellcodes) Veränderungen anzupassen

4. Wie Clean Code Development die innere Software­qualität optimieren kann

Clean Code Development ist ein norm­gebendes Werte­system für Software­entwickler:innen. Über Werte und Tugenden vermittelt Clean Code Development eine perfekt auf die Software­entwicklung zugeschnittene Arbeits­philosophie, die von Agilität, konsequentem inter­disziplinären Austausch, einem hohen Qualitäts­bewusstsein sowie dem Drang nach ständiger Optimierung lebt. Daneben sind es ganz praktische Handlungs­empfehlungen für das eigentliche Coding. In fünf Grade unterteilte Praktiken und Prinzipien, die, wenn sie von Anfang an beherzt werden, nicht nur zu hoher innerer Software­qualität führen, sondern diese auch mess- und prüfbar machen.

Folgende Tabelle zeigt welche Prinzipien und Praktiken auf die wichtigsten inneren Software­qualitäts­merkmale einzahlen und was sie bedeuten:


Qualitätsmerkmal CCD Prinzipien CCD Praktiken
Lesbarkeit Source Code Convention: Nutzen von syntaktischen Konventionen, die ein schnelles Lesen und Erfassen des Codes unterstützen Statical Code Analysis: Automatisierte Tests, die den Quellcode auf formale Fehler überprüfen

Code Reviews: Quellcode sollte immer von einer zweiten Softwareentwickler:in begutachtet werden
Nachvollziehbarkeit Single Level of Abstraction: In einer Methode sollte nur ein Abstraktionsniveau verwendet werden

Principle of Least Astonishment: Softwarekomponenten sollten immer genau so implementiert sein, wie man es von ihnen erwarten würde

Keep It Simple Stupid: Wenn (auch) eine einfache Lösung funktioniert, ist immer diese zu wählen
Version Control System: Ein Versionskontrollsystem ist einzusetzen

Issue Tracking: „Kundenanfragen“ müssen systematisch erfasst, priorisiert, abgearbeitet und nachverfolgt werden
Testbarkeit Integration Operation Separation Principle: Entweder eine Methode enthält nur Logik (Operation) oder keinerlei Logik und nur Aufrufe anderer Methoden (Integration) Test First: Zuerst werden Tests für eine bestimmte Schnittstelle geschrieben und erst danach wird diese implementiert

Test Automation: Egal ob Unit oder Integration Testing: Tests müssen automatisiert werden, um konsequent Mehrwert zu bieten
Wiederverwendbarkeit Don’t Repeat Yourself: Codebestandteile dürfen nicht dupliziert werden – Copy/Paste ist verboten

Single Responsible Principle: Eine Klasse sollte immer nur eine Aufgabe/Verantwortlichkeit haben
Component Orientation: Komponenten können unabhängig voneinander implementiert werden und erfüllen dabei einen gemeinsamen Kontrakt, sodass sie später beliebig integriert werden können
Evolvierbarkeit Open Closed Principle: Eine Klasse muss offen für Erweiterungen sein, jedoch geschlossen für Modifizierungen

Dependency Inversion Principle: Klassen dürfen nicht voneinander abhängig sein, sondern nur von Interfaces
Refactorings: Methoden, Muster und Tools, um Quellcode gemäß den CCD-Prinzipien zu bereinigen

Inversion of Control Container: Der Container löst die Abhängkeiten auf und hat die Kontrolle über den Lebenszyklus der Objekte

Autor
Dominik Schaufelberger
Softwareentwickler | Clean Code Ambassador
Autor
Florian Kinn
Softwareentwickler | Clean Code Ambassador
Wie können wir Sie beraten?
Telefon
Online Beratung
Kontaktanfrage
Telefon
Wir freuen uns auf Ihren Anfruf
+49 (0) 721-619096-0
+49 (0) 721-619096-19
Für Sie erreichbar von
Mo bis Fr 8-16 Uhr
Online Beratung
Buchen Sie online einen für Sie passenden Termin
Wir freuen uns auf Ihre Nachricht
Wenn Du wissen möchtest, welche Daten wir ver­ar­beiten und wie lange wir diese speichern, findest du weiter­führende Infor­mationen in unserer Daten­schutz­erklärung.
Vielen Dank! Ihre Kontaktanfrage wurde von uns empfangen!
Oh nein! Irgendwas ist schiefgelaufen. Probieren Sie es bitte noch einmal!
Kontakt