Clean Code für Dummies
Clean Code für Dummies
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
© 2020 WILEY-VCH Verlag GmbH & Co. KGaA, Weinheim
Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries. Used by permission.
Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc., USA, Deutschland und in anderen Ländern.
Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler keine Haftung.
Print ISBN: 978-3-527-71634-0
ePub ISBN: 978-3-527-82392-5
Coverfoto: © georgejmclittle – stock.adobe.com
Korrektur: Claudia Lötschert, Neuss
Jürgen Lampe ist promovierter Mathematiker. Nach dem Studium arbeitete er mehrere Jahre als Entwickler für Prozessrechner. Die dabei zwingende Notwendigkeit, mit sehr begrenzten technischen Mitteln für den Kunden einen messbaren ökonomischen Nutzen zu erreichen, hat ihn dauerhaft geprägt. Natürlich blieb ihm auch das zeitraubende und mühselige Suchen und Beheben von Programmierfehlern nicht erspart, sodass nahezu zwangsläufig der Wunsch reifte, Exaktheit und Effektivität der mathematischen Verfahren auf die Softwareentwicklung zu übertragen. Insbesondere die teilweise bereits formalisierten Fachsprachen schienen dafür ein guter Ausgangspunkt zu sein. Über Jahre beschäftigte er sich dann mit der Definition von Fachprogrammiersprachen und deren Implementierung. Diese Forschungen zeigten ihm unter anderem die Wichtigkeit der Anwendungsmodellierung für eine saubere Softwareentwicklung.
Mit diesen Voraussetzungen war der Weg zu Clean Code einfach eine gern genommene logische Fortsetzung. Sie bestärkte ihn auch in der Ansicht, dass große und komplexe Systeme nicht aus dem Stand, sondern nur in einer evolutionären Folge von kleinen Veränderungen – Irrtümer eingeschlossen – gebaut und lebensfähig erhalten werden können.
Software ist wichtig und wird immer wichtiger. Vielleicht haben Sie angesichts dieser Tatsache auch, so wie ich, das flaue Gefühl, dass die Qualität der Programme und die Kosten ihrer Entwicklung viel zu oft nicht den Erfordernissen entsprechen.
Es ist offensichtlich, dass die Erstellung von Software in vielerlei Richtungen entscheidend verbessert werden muss. Wenn das nicht gelingt, drohen Ausfälle mit gewaltigem Schadenspotenzial.
Berichte über – oft nach einem Update – nicht oder nur noch eingeschränkt funktionierende Bank- oder Buchungssysteme vermitteln einen kleinen Vorgeschmack darauf, was in Zukunft möglicherweise alles passieren kann.
Je mehr Software im Einsatz ist, desto bedeutender wird deren konsequente Verbesserung und Weiterentwicklung. Bereits heute entsteht ein großer Teil der Kosten nicht durch Neuentwicklungen, sondern durch die notwendigen Anpassungen.
Clean Code ist ein wichtiges Konzept, um Programme so zu schreiben, dass sie möglichst wenig Fehler enthalten und über lange Zeit stabil weiterentwickelt werden können. Jeder engagierte Entwickler sollte deshalb zumindest die wichtigsten Grundsätze kennen.
Dieses Buch soll Ihnen die Gedankenwelt des Clean-Code-Konzepts nahebringen.
Das ist nicht mit der Darstellung einer Reihe von Regeln getan. Infolgedessen kann ich Ihnen auch nicht versprechen, dass Sie nach dem Studium dieses Buchs ein perfekter oder auch nur guter Clean-Code-Programmierer seien werden.
Ich kann Ihnen jedoch versprechen, dass Sie nach dem Lesen eine andere Sicht auf die Softwareentwicklung haben werden. Sie werden zumindest einiges besser verstehen und verständlicheren Code schreiben können. Und das ganz unabhängig davon, ob Sie das komplette Buch intensiv studiert oder nur Teile davon überflogen haben.
Softwareentwicklung kann gut mit der Expedition zu einem Ziel in schlecht erschlossenem Gelände verglichen werden. Je nachdem wie gut die Gegebenheiten bereits bekannt sind, lässt sich der erforderliche Aufwand mehr oder weniger genau vorhersagen. Je weniger Sie wissen, desto sorgfältiger muss die Unternehmung vorbereitet werden.
Mit diesem Buch will ich Ihnen helfen, sich zielstrebig auf Softwareprojekte einzustellen. Deshalb diskutiere ich nützliche handwerkliche Fertigkeiten und Verfahren ausführlich.
Daneben geht es mir aber auch um die mentale Vorbereitung. Anforderungen können sich stark unterscheiden und Schwierigkeiten beispielsweise durch den Umfang an Funktionen, Leistungsanforderungen oder ein unzureichendes Verständnis der Anwendungsdomäne verursacht werden.
Jeder dieser Punkte erfordert ein anderes Herangehen. Diese Differenzierung wird viel zu häufig unterlassen.
Schließlich noch ein dritter Punkt: Sie lernen (hoffentlich) jeden Tag etwas dazu. Ich zeige Ihnen Wege, wie Sie das Gelernte nutzen können, um darauf aufbauend jeden Tag besser für Ihr Projekt zu arbeiten.
Mit dieser umfassenden Sicht hoffe ich, Ihnen auch dann zu helfen, wenn Sie die vorgestellten Techniken nicht oder nur stark eingeschränkt einsetzen können.
Und nicht zuletzt wünsche ich mir, dass dieses Buch auch dem einen oder anderen, der nicht selbst Code schreibt, aber eng mit IT-Entwicklungen verbunden ist, hilft, Softwareentwickler besser zu verstehen und ihnen den Freiraum zu gewähren, den sie für gute Ergebnisse brauchen.
Wenn es konkret wird, verwende ich Java. Diese Programmiersprache ist sehr vielen Entwicklern zumindest bekannt und wird seit Jahren in zahlreichen Projekten eingesetzt. Allein aufgrund des vorhandenen Codebestands wird Java noch lange wichtig sein.
Allerdings ist Clean Code nicht an eine bestimmte Sprache gebunden. Fast alle Beispiele lassen sich ohne großen Aufwand in andere Sprachen übertragen. Und wahrscheinlich lernen Sie bei Ihren entsprechenden Versuchen sogar mehr, als wenn ich dieses Buch durch die Wiederholung von Beispielen in verschiedenen Programmiersprachen aufgebläht hätte.
Damit Sie sich gut zurechtfinden, erkläre ich Ihnen kurz die verwendeten Schriftarten und Hervorhebungen.
public class DasIstEinBeispiel extends Nothing {}
java.lang.Object geht.Neue Begriffe werden in der Regel kursiv gesetzt.
Manchmal wird die Kursivschreibung auch zur Hervorhebung benutzt.
Selbstverständlich bin ich der Meinung, dass es sich lohnt, das gesamte Buch zu lesen. Aber natürlich müssen Sie das nicht.
Die Texte in Kästen sind Hintergrundinformationen, die Sie überspringen können.
Was für Sie wichtig ist und was nicht, hängt stark davon, warum Sie sich für dieses Thema interessieren und was Sie dazu bereits wissen.
Wenn Ihnen das Thema Clean Code noch relativ neu ist und Sie überhaupt erst einmal verstehen wollen, worum es dabei geht, sollten Sie mit den Kapiteln 1, 2 und 4 starten und dann mit einem Ihnen interessant erscheinenden Thema aus Teil III fortfahren.
Wenn Sie Clean Code bereits kennen, können Sie eigentlich sofort mit Teil III beginnen. Trotzdem empfehle ich Ihnen, unabhängig davon auch die Kapitel 6 und 7 zu lesen.
Für alle, die keine oder wenig Programmiererfahrung haben, sind die Kapitel 1, 2, 6, 7 und 21 geeignet, um das Verständnis für den Softwareentwicklungsprozess zu erhöhen.
Der Aufbau des Buchs ist so gewählt, dass es von Anfang bis Ende einer Linie folgt. Trotzdem ist es so geschrieben, dass Sie grundsätzlich jedes Kapitel für sich allein lesen können.
Wenn einzelne Gesichtspunkte in einem anderen Kapitel detailliert behandelt werden, finden Sie entsprechende Verweise – denen Sie folgen können oder nicht.
Wenn Sie etwas schon wissen oder es Ihnen unwichtig erscheint, überspringen Sie es – oder lesen Sie es später. Wie ich Ihnen überhaupt empfehlen möchte, es nicht beim einmaligen Durchlesen zu lassen. Ich bin ziemlich sicher, dass Sie im Lichte Ihrer gewonnenen Erfahrungen bei jedem erneuten Lesen einige Dinge besser oder erst richtig verstehen werden, die Ihnen zuvor entgangen sind.
In diesem Buch dreht sich alles um Softwareentwicklung und Code. Daher sollte mindestens einer der folgenden Punkte auf Sie zutreffen.
Sie können programmieren.
Für das vollständige Verständnis ist eine gewisse Vertrautheit mit einer im Idealfall objektorientierten Programmiersprache nötig.
Sie wirken an IT-Projekten als Entwickler mit.
Praktisch erleben können Sie den Nutzen von Clean Code vor allem bei größeren und länger laufenden Softwareprojekten.
Sie wollen besseren Code produzieren.
Diese Motivation wird Ihnen ganz bestimmt helfen, schneller und gründlicher zu lernen.
Sie verfügen über Ausdauer und Stehvermögen.
Um sauberen Code zu schreiben, werden Sie möglicherweise lieb gewonnene Wege verlassen müssen. Eine solche Umstellung Ihrer Arbeitsweise ist nicht von heute auf morgen bewerkstelligt, sondern braucht Zeit und Training.
Sie sind eng mit der Entwicklung von Software verbunden.
Wenn Sie als Projektleiter, Product Owner oder in einer ähnlichen Rolle eng mit Entwicklern zusammenarbeiten, gehören Sie nicht unmittelbar zur angepeilten Zielgruppe. Sie können jedoch viel über deren Methoden und Probleme lernen und dadurch das gegenseitige Verständnis erheblich fördern. Abschnitte, die sich unmittelbar auf den Code beziehen, können Sie natürlich überspringen.
Sie sind bereits ein perfekter Clean-Coder.
Dann brauchen Sie dieses Buch eigentlich nicht. Lesen Sie es bitte trotzdem kritisch und machen Sie mich auf Fehler und Vergessenes aufmerksam. Oder – noch besser – verfassen Sie gleich »Cleaner Clean Code für Dummies«.
Dieses Buch besteht aus fünf Teilen.
In diesem Teil erfahren Sie die Grundgedanken des Clean-Code-Prinzips. Warum ist Code als solcher so wichtig? Was ist überhaupt guter und sauberer Code? Daneben geht es um Fragen des Abwägens zwischen konkurrierenden Zielstellungen.
In Teil II lernen Sie wesentliche Herausforderungen kennen, die Sie als Softwareentwickler bewältigen müssen. Der Schwerpunkt liegt dabei auf jenen Problemen, die vor dem Beginn des Codeschreibens gelöst sein sollten.
Diese Differenzierung der Problembereiche hilft Ihnen, keine unrealistischen Erwartungen bezüglich des Effekts von sauberer Programmierung zu hegen.
Teil III zeigt Ihnen die wichtigsten Regeln zum Schreiben von sauberem Code. Dabei erfahren Sie jeweils auch, unter welchen Bedingungen eine Regel verwendet werden sollte und wann es besser ist, sie nicht anzuwenden.
Sie lernen zudem, wie Sie mögliche Fehler klassifizieren und dementsprechend sauber behandeln können.
Schließlich geht es auch noch um neuere Sprachbestandteile, und Sie sehen, wie diese ohne Beeinträchtigung der Codequalität sinnvoll eingegliedert werden können.
In Teil IV steht die praktische Umsetzung des Clean-Code-Konzepts im Mittelpunkt. Sie erhalten Tipps, wie es Ihnen gelingen kann, das Schreiben von sauberem Code in den Softwareentwicklungsprozess zu integrieren.
Im letzten Teil des Buchs habe ich noch ein paar nützliche Hinweise für Sie versammelt:
Die Glühbirne markiert einen Tipp. Falls Sie nur Wissen erwerben wollen, können Sie solche Hinweise überspringen. Wenn es Ihnen aber auch um die praktische Umsetzung geht, sollten Sie diese Tipps nicht nur einmal sorgfältig lesen.
An dieser Stelle finden Sie Hinweise, die Ihnen helfen sollen, bei der praktischen Anwendung des Dargestellten Fehler zu vermeiden.
Daher können Sie diese Texte überspringen, wenn Sie nur das Thema verstehen wollen.
Hier schränke ich die Bedeutung einzelner Wörter durch eine genauere Abgrenzung ein, um im folgenden Text Missverständnisse zu vermeiden. Solche Definitionen sollten Sie besser nicht ignorieren.
Mit dem Wegweiser kennzeichne ich zusätzliche Erläuterungen beispielweise durch Analogien aus anderen Bereichen oder kurze Beispiele. Für das Verständnis sind diese Ausführungen zwar nicht zwingend erforderlich, aber hoffentlich hilfreich.
Wenn Sie wenig Zeit haben oder das Kapitel bereits zum zweiten Mal lesen, können Sie diese Texte überspringen.
Umfangreichere Beispiele, die unabhängig vom umgebenden Text verständlich sind, werden auf diese Weise gekennzeichnet.
Sie können diese Teile beim ersten Lesen gern überspringen und eventuell später genauer studieren.
Ganz gleich, aus welchen Gründen Sie sich für Clean Code interessieren. Fangen Sie an zu lesen – das muss nicht auf Seite 1 sein – und versuchen Sie Ihre Erkenntnisse sinnvoll anzuwenden.
Bevor Sie nun loslegen, möchte Ihnen aber noch einen Rat geben. Den können Sie jetzt gern überspringen, aber lesen Sie ihn bitte auf jeden Fall noch, bevor Sie eventuell aufgeben:
Es gibt keinen Express auf dem Weg zum guten Clean-Code-Entwickler. Viel eher ist ein Fußmarsch vonnöten. Wie lang und wie beschwerlich dieser Marsch ist, hängt vom Ausgangspunkt und den spezifischen Schwierigkeiten ab, die Sie überwinden müssen.
Und sollte Ihnen unterwegs einmal alles zu lange dauern und der Mut sinken, dann kann Ihnen diese jüdische Weisheit vielleicht neue Energie und Zuversicht geben: »Wer langsam und besonnen geht, doch oft zuerst am Ziele steht.«
In diesem Sinne – auf denn!
Teil I
Kapitel 1
IN DIESEM KAPITEL
In diesem Kapitel werden, ausgehend von der Bedeutung, die Software im Alltag spielt, Probleme erläutert, die bei der Softwareentwicklung immer wieder auftreten. Danach wird die zentrale Stellung des Programmcodes im Entwicklungsprozess begründet.
Software ist aus dem täglichen Leben nicht mehr wegzudenken. Sie findet sich nicht nur in Computern und Smartphones, sondern ersetzt zunehmend sogar einen Teil der mechanischen Bauteile, beispielsweise in Türschlössern und Nähmaschinen. Vor allem die aufwendig herzustellenden Steuerungskonstruktionen weichen elektronisch angesteuerten einfachen Schaltelementen.
Den meisten Benutzern ist es dabei völlig gleichgültig, was Software ist. Sie erwarten, dass das Gerät oder das Programm funktioniert.
Allerdings ist niemand total überrascht, wenn das einmal nicht der Fall ist. Überlegen Sie kurz, wie oft Sie selbst schon schulterzuckend einen Softwarefehler hinnehmen mussten. Meist ist das zum Glück nur ärgerlich.
Es scheint unmöglich zu sein, weitgehend fehlerfreie Software zu produzieren.
Der Vergleich mit anderen komplexen technischen Apparaten wirft allerdings die Frage auf, wieso es bisher nicht gelungen ist, Verbesserungen in vergleichbarem Maße zu erreichen wie etwa bei der Sicherheit von Flugzeugen. Darauf gibt es keine einfache Antwort.
Die beschriebene Problematik ist fast so alt wie der Computer. Bereits 1972 erwuchs aus der unbefriedigenden Situation der Begriff Softwarekrise, und 1993 wurde auf einer Tagung gefragt: »Kann eine Krise 20 Jahre dauern?«
Trotz unleugbarer Fortschritte muss man eingestehen, dass die Krisensymptome heute noch genauso sichtbar sind wie damals. Geändert hat sich die Wahrnehmung. Das, was zunächst als Krise erschien, wird mittlerweile als Dauerzustand hingenommen.
Das heißt allerdings nicht, dass Sie als Entwickler diesen Zustand akzeptieren müssen. Ich hoffe, Sie lesen dieses Buch gerade deshalb, um daran etwas zu ändern. Denn Veränderung tut not, und zwar immer dringender. Je mehr Software in unser Leben eingreift, desto schwerwiegender werden ganz zwangsläufig die Auswirkungen von Fehlern sein.
Wenn man auf Probleme stößt, ist es erfahrungsgemäß nützlich, deren Ursachen aufzuklären. In den meisten Fällen gibt es dafür nicht nur einen Grund. Für die Softwarekrise lassen sich zwei wichtige Ursachengruppen finden.
Für die oft mangelhafte Qualität von Software gibt es ebenso wie für das ganze oder teilweise Scheitern von Entwicklungsprojekten verschiedene Gründe, unter anderem:
Diese Liste ist bei Weitem nicht vollständig. Sie soll Ihnen nur zeigen, dass es zwar viele aus Sicht der Entwicklung externe Ursachen gibt, aber zumindest die letzten beiden Punkte fallen in die Verantwortung der Entwickler.
Tests sind unverzichtbarer Teil jeder professionellen Softwareentwicklung. Sie können damit zwar nicht die vollständige Korrektheit Ihres Programms beweisen – ein Test ist immer nur eine Stichprobe –, aber Sie dokumentieren, was nachweisbar funktioniert, und verringern die Wahrscheinlichkeit, dass Fehler übersehen werden.
Dieser Hinweis steht seiner Wichtigkeit wegen bereits hier und damit ganz am Anfang. Nehmen Sie ihn bitte ernst und vergessen Sie nicht: Auch Tests sind Code, und für diesen Testcode sind die gleichen Qualitätsanforderungen zu erfüllen wie für den zu testenden Code.
Einen sehr großen Einfluss auf die Softwarekrise hat die Entwicklung der Hardware ausgeübt. Durch die rapide Leistungssteigerung der Prozessoren und die parallel dazu gewachsenen verfügbaren Speichervolumina entstand ein stetiger Druck, noch größere Aufgaben in Angriff zu nehmen.
Die Softwarehersteller hatten nie Zeit, um in Ruhe Luft zu holen und ihre Produkte zu konsolidieren. Stets stand schon eine neue, noch leistungsfähigere Hardwaregeneration vor der Tür, die Anpassungen und Weiterentwicklungen verlangte. Die Programme wurden immer umfangreicher und komplexer, ohne dass mehr Zeit für die Entwicklung verfügbar war.
Alle im Entwicklungsprozess erreichten Verbesserungen wurden sofort dafür eingesetzt, in diesem Rennen Schritt zu halten. Die Softwarequalität geriet dabei oft ins Hintertreffen. Schon in den 1980er-Jahren entstand dazu das wahlweise Niklaus Wirth oder Martin Reiser zugeschriebene Bonmot: Software wird schneller langsamer, als die Hardware schneller wird.
Mittlerweile steigt die reine Prozessorgeschwindigkeit kaum noch, dafür werden die Strukturen mit Mehrkern- und Multiprozessoren komplizierter. Diese neuen Möglichkeiten können nur durch nebenläufige Programme voll ausgenutzt werden, was die Software noch einmal um Größenordnungen komplexer macht. Die Lage hat sich also kaum verändert.
Bisher habe ich ständig von Software gesprochen, ohne diesen Begriff genauer zu erläutern. Das hat seinen Grund. Es ist schwer, eine Definition zu finden, die sowohl ausreichend konkret als auch umfassend genug ist. Hier werde ich mich deshalb auf einen wesentlichen Aspekt beschränken.
Software ist in gewisser Weise ein indirektes Produkt. Sie entsteht aus formalen Beschreibungen, die im Allgemeinen Programmcode oder kurz Code genannt werden. Ihre Wirksamkeit oder Nutzbarkeit ist an bestimmte technische Geräte – die Hardware – und weitere Software wie Betriebssysteme und Compiler gebunden.
Wenn Sie von dieser Umgebung, die gemeinhin vorgegeben ist, absehen, lassen sich alle wichtigen Eigenschaften einer Software auf ihren Code zurückführen. Um eine Software zu schreiben oder zu erweitern, müssen Sie Code schreiben. Das Gleiche gilt, wenn Sie einen Fehler beheben wollen.
Das Produkt jedes Softwareentwicklungsprozesses ist Code. Es gibt gemeinhin keine genauere Beschreibung dessen, was eine Software leistet, als den Programmcode.
Die Schlussfolgerung lautet daher: Software besteht im Wesentlichen aus Code. Und daraus folgt unmittelbar: Code ist wichtig. Bessere Software lässt sich nur durch besseren Code produzieren.
Es wird Sie daher nicht überraschen, dass in vielen Unternehmen schon heute ein erheblicher Teil der Vermögenswerte aus Code besteht. Dessen wirtschaftliche Bedeutung zeigt sich nicht zuletzt in den mit viel Einsatz geführten Auseinandersetzungen um Rechtsverstöße und Lizenzbedingungen.
Da immer mehr Funktionen durch Software realisiert werden, ist absehbar, dass die Wichtigkeit von Code für unser Leben weiter zunehmen wird.
Code existiert oft wesentlich länger als die Hardware, für die er ursprünglich entwickelt wurde. Beispielsweise verwenden manche Forschungseinrichtungen noch heute mathematische Fortran-Bibliotheken, die bereits mehrere Jahrzehnte alt sind. In vielen großen Programmsystemen finden sich Codeteile, die aus weit zurückliegenden Versionen überlebt haben.
Voraussetzung eines solch langen Lebens ist lediglich, dass neuere Versionen der Compiler abwärtskompatibel sind, das heißt, dass sie den alten Quelltext weiterhin akzeptieren und fehlerfrei verarbeiten können. Wenn ein genügend großer Codebestand vorhanden ist, wird das von den Compilerproduzenten gewöhnlich gewährleistet, um die Kunden schneller auf neue Versionen locken zu können.
Ganz nebenbei: Die Angst, dass die für eine solche langfristige Sicherung der Codebasis notwenige kritische Masse an Programmcode nicht zustande kommt, ist eines der größten Hindernisse bei der Verbreitung neuer Programmiersprachen.
Kapitel 2
IN DIESEM KAPITEL
In diesem Kapitel werden die grundlegenden Eigenschaften des Qualitätsbegriffs dargestellt. Sie lernen einige der möglichen Ausprägungen von Qualitätserwartungen an Code kennen und erfahren, dass jedes Projekt sein individuell angepasstes Codequalitätsziel braucht.
Bevor ich genauer auf die Codequalität eingehe, erscheint es mir angebracht, den Qualitätsbegriff, den ich in diesem Buch verwende, klarzustellen. Das Schlüsselwort Qualität wird immer öfter unzulässig weit interpretiert. Das führt dazu, dass seine Bedeutung verschwimmt und in die Beliebigkeit abzurutschen droht.
Klare Gedanken erfordern eine klare Sprache. Um der Gefahr von Missverständnissen vorzubeugen, beginne ich mit folgender Definition:
Qualität ist zunächst lediglich die Summe aller Eigenschaften und Merkmale eines Objekts – ohne jede Bewertung. Dem allgemeinen Sprachgebrauch folgend wird hier vorrangig die Güte der Eigenschaften und Merkmale als Qualität bezeichnet.
Wenn man den auf die Güte bezogenen Qualitätsbegriff betrachtet, ergeben sich die beiden nachfolgenden wichtigen Eigenschaften:
Qualität ist prinzipiell nicht absolut messbar.
Gemeint ist damit, Qualität lässt sich nicht als Zahlenwert ausdrücken, sonst wäre sie Quantität. Trotzdem gibt es Qualitätsindikatoren, die messbar sind.
Die Bewertung von Qualität ist immer auf eine Erwartung bezogen.
Ob etwas hohe Qualität hat, hängt vom Betrachter ab. Sie können beispielsweise ein Stück Code positiv bewerten, weil es hervorragend zu lesen ist, während jemand anderes es negativ einschätzt, weil es die erwartete Funktion nicht erfüllt.
Sie können sich die genannten prinzipiellen Eigenschaften gut vergegenwärtigen, wenn Sie das Wort »Qualität« durch »Schönheit« ersetzen. Letztere ist ebenfalls eine (spezielle) Qualität im Sinne der obigen Definition.
Es ist klar, dass man Schönheit nicht absolut messen kann, und der Volksmund sagt nicht zu Unrecht mit Bezug auf die Bewertung: Die Schönheit liegt im Auge des Betrachters.
Obwohl Qualität nicht messbar ist, lassen sich Objekte hinsichtlich ihrer Qualitätsbewertung vergleichen. Sie dürfen dabei nur nicht vergessen, dass dieser Vergleich stets auf eine bestimmte Erwartung bezogen ist.
Daneben müssen die verglichenen Objekte hinsichtlich der Erwartung ausreichend ähnlich sein, wenn Sie zu sinnvollen Ergebnissen kommen wollen. Äpfel mag man mit Birnen vergleichen, wenn es um den Geschmack oder andere Qualitäten geht, die sich auf das Objekt »Frucht« beziehen – ansonsten besser nicht.
Getreu dem Motto »Was man nicht messen kann, gibt es nicht« wird immer wieder versucht, Qualität zu messen. Leider scheinen viele Manager dann auch zu glauben, dass ihnen das wirklich gelingt – eine riskante Selbsttäuschung.
Alle sogenannten Qualitätsmaße sind bestenfalls Qualitätsindikatoren. Es wird versucht, messbare Eigenschaften zu finden, die in hohem Maße mit den jeweiligen Qualitätserwartungen korreliert sind.
Das Problem mit diesen Korrelationen besteht aber darin, dass sie keinem zwingenden Zusammenhang entspringen. Es ist stets möglich, den Indikator zu manipulieren, ohne dass sich an der betrachteten Qualität etwas ändert.
Betrachten Sie Qualitätsindikatoren mit Vorsicht. Zurückhaltend angewandt, können Sie Ihnen wichtige Erkenntnisse liefern.
Vermeiden Sie jedoch unbedingt eine Verabsolutierung. Wenn Sie einen Indikator zum Maßstab erklären, wird er über kurz oder lang wertlos, und Sie berauben sich dadurch einer nützlichen Informationsquelle.
Was ich hier Dimensionen von Codequalität nenne, sind die Erwartungen der Qualitätsbewertung aus dem vorangegangenen Abschnitt. Der Ausdruck erscheint mir deshalb angebracht, weil es sich um ganz unterschiedliche Erwartungen handelt, die im konkreten Fall auch unterschiedlich ausgeprägt sein können, sodass die konkrete Qualitätserwartung einem Punkt im mehrdimensionalen Raum entspricht.
Die Unabhängigkeit der Erwartungen voneinander bedeutet nicht, dass die Realisierungen ebenfalls unabhängig sind – ganz im Gegenteil. Kollisionen zwischen stark ausgeprägten Erwartungen sind eher unvermeidlich.
Das heißt letztlich, nicht alles, was Sie gern gleichzeitig hätten, ist auch möglich. Oder abstrakter gesagt: Nicht jeder Punkt im Qualitätsraum ist realisierbar.
Auf diese Dimension wird kein sinnvoller Code verzichten. Trotzdem können die Erwartungen recht unterschiedlich sein, wie ich Ihnen an ein paar Beispielen zeigen werde:
Prototyp oder Demonstrationsprogramm
In der Regel steht die schnelle und kostengünstige Herstellung im Fokus. Abstriche an der Funktion und einzelne Fehler werden toleriert.
Programm für beschränkten Einsatz
Das sind oft Programme für Datenmigration oder zeitlich beschränkte Funktionalitäten. Es ist manchmal kostengünstiger, die Folgen von einzelnen Fehlern nachträglich von Hand zu beseitigen, als ein Programm zu korrigieren.
Programm für langfristigen Einsatz
Da die Anwendungsfälle begrenzt und bekannt sind, können Fehler bei nicht oder nur selten genutzten Funktionen akzeptabel sein.
Softwareprodukt
Es wird ein weitgehend fehlerfreies Verhalten über alle Anwendungsfunktionen erwartet.
Sicherheitsrelevantes Programm
Sehr hohe Anforderungen an die Korrektheit werden mit großem Aufwand realisiert.
Diese beiden Dimensionen sind nicht identisch, aber stark miteinander verknüpft. Auch wenn Sie das auf den ersten Blick vermuten könnten, gute Wartbarkeit setzt eine gute Lesbarkeit des Codes nicht zwingend voraus. Gute Wartbarkeit kann durch aktuelle und umfassende Dokumentation ebenso erreicht werden.
Für Assemblercode lässt sie sich beispielsweise anders praktisch gar nicht erreichen. Bei höheren Programmiersprachen ist allerdings der Zwang, die Dokumentation auf dem aktuellen Stand zu halten, nicht ganz so stark. Deshalb spielt die Lesbarkeit eine wichtigere Rolle.
Da sich das Verhältnis von Lesbarkeit zu Wartbarkeit wie ein roter Faden durch dieses Buch zieht, werde ich es hier nicht weiter ausführen. In den folgenden Kapiteln werden Sie ausführliche Erläuterungen finden.
Damit ist in erster Linie die Laufzeiteffizienz des Codes gemeint. In vielen Anwendungsbereichen ist es inzwischen zwar kostengünstiger, mehr oder schnellere Hardware bereitzustellen, als den Code zu optimieren, aber es gibt auch einen großen Sektor, in dem Antwortzeiten und damit die Verarbeitungsgeschwindigkeit eine Rolle spielen. In dem Ausmaß, in dem computergesteuerte Geräte den Alltag durchdringen, wird der Bedarf an solcher echtzeitfähigen Software zunehmen.
Leistung ist eine Dimension, die bei der Umsetzung häufig in Konkurrenz zu anderen Erwartungen wie Lesbarkeit oder Modularisierung tritt.
Je nach Projektziel gibt es zusätzliche Dimensionen. Als Anregung möchte ich Ihnen kurz noch einige weitere präsentieren:
Speicherbedarf
Das kann sich sowohl auf den Umfang des Codes als auch auf den während der Laufzeit für die Daten erforderlichen Platz beziehen. Da Speicher nicht teuer ist, wird dieses Kriterium vor allem dann wichtig, wenn die Software in vielen Tausenden (echten oder virtuellen) Instanzen läuft. Dazu gehören ebenfalls die vielen »smarten« Geräte, die meist nur über eine beschränkte Ausstattung verfügen.
Stromverbrauch
Diese Dimension weist Beziehungen zur Leistung auf, ist aber ähnlich wie der Speicherbedarf vor allem bei einer großen Anzahl von Instanzen und langen Laufzeiten wichtig.
Außerdem ist niedriger Stromverbrauch bei mobilen Geräten von entscheidender Bedeutung, weil dadurch die Laufzeit, die ohne Nachladen möglich ist, verlängert werden kann.
Komplexität des Codes
Bei dieser Dimension wird zur Abwechslung eine möglichst niedrige Ausprägung angestrebt.
Modularität
Auch diese Dimension hat Beziehungen zu anderen Dimensionen. Da Modularität kein Allheilmittel ist und möglicherweise andere Qualitäten negativ beeinflussen kann, sollten Sie sie aber als eigene Dimension betrachten.
Angesichts der vielen Sichtweisen auf den Begriff der Qualität rate ich Ihnen, sich zu Beginn eines Entwicklungsprojekts rechtzeitig Gedanken über Ihr spezifisches Qualitätsziel zu machen. Wenn Sie das unterlassen, besteht die Gefahr, dass Sie im Laufe der Entwicklung die für Ihr Projekt relevanten Ziele aus den Augen verlieren oder gar auf abweichende, das heißt weniger wichtige Zielstellungen, hinarbeiten.
Bei der Definition müssen Sie als Erstes die lang- und kurzfristigen Interessen des Auftraggebers erkunden. Zusammen mit der Analyse der Aufgabenstellung erhalten Sie eine Basis, auf der Sie die zu erfüllenden Erwartungen, deren Ausprägungsgrad und die Wichtigkeit für den Projekterfolg ermitteln können.
Da in diesen Prozess viele subjektive Einschätzungen einfließen, ist es wichtig, dass sich alle Teammitglieder daran beteiligen. Am Ende muss das Qualitätsziel von allen akzeptiert und mitgetragen werden.
Nehmen Sie die gemeinsame Bestimmung eines Qualitätsziels ernst und planen Sie genügend Zeit für die notwendigen Diskussionen ein. Nur ein von allen und von Anfang an akzeptiertes Ziel kann gemeinsam erreicht werden.
Sorgen Sie dafür, dass das vorab definiert Qualitätsziel im Laufe des Projekts nicht dem Vergessen anheimfällt. Andererseits dürfen Sie es natürlich nicht als Dogma sehen. Ebenso wie alle anderen Entwicklungsentscheidungen muss das Ziel von Zeit zu Zeit und den gewonnenen Erfahrungen entsprechend angepasst werden.
Abschließend werde ich Ihnen die wichtigsten Überlegungen an einem (sehr) kleinen Beispiel illustrieren. Es handelt sich um Euklids Algorithmus zur Berechnung des größten gemeinsamen Teilers (ggT) zweier Zahlen. Listing 2.1 zeigt zwei mögliche Implementierungen.
public static int ggT01(int m, int n) {
int r;
while (n != 0) {
r= m % n;
m= n;
n= r;
}
return m;
}
//------------------------------------
public static int ggT02(int m, int n) {
if (n == 0) {
return m;
} else {
return ggT02(n, m % n);
}
}
Listing 2.1: Zwei Implementierungen des euklidischen Algorithmus
Im Unterschied zu fast allen anderen Beispielen in diesem Buch sehen Sie hier Abkürzungen und Namen, die nur aus einem Buchstaben bestehen. Bei der Implementierung von allbekannten mathematischen Formeln halte ich das für vertretbar, weil es der Praxis im Anwendungsgebiet, also der Mathematik, entspricht.
Überlegen Sie selbst, ob der Code verständlicher wird, wenn Sie m, n und r durch zahl1, zahl2 und rest ersetzen sowie den Methodennamen ausschreiben. Wahrscheinlich wird Ihre Entscheidung davon abhängen, wie vertraut Ihnen der mathematische Formalismus ist. Insofern zeigt Ihnen dieses Beispiel, gewissermaßen nebenbei, auch noch die Relativität von Qualitätserwartungen.
Nun werden die beiden Methoden ggT01 und ggT02 in Bezug auf einige der vorgestellten Qualitätsdimensionen verglichen. Da es hier nur um die prinzipielle Darstellung geht, berücksichtige ich nicht, dass es in der Realität möglicherweise noch Optimierungen durch den Compiler oder das Laufzeitsystem geben könnte.
ggT02 leicht im Vorteil, weil sie kürzer ist und sich stärker an der in der Mathematik üblichen rekursiven Beschreibung orientiert.ggT01 für die Berechnung nur drei lokale Variablen und keine zusätzlichen Methodenaufrufe benötigt, ist von ihr die bessere Leistung zu erwarten.ggT01 Vorteile, weil ggT02 bei jedem erneuten Aufruf zusätzlichen Speicherplatz im Stack belegt.