Schlagwort-Archiv: Qualität

Veröffentlicht am von

Merkmale für Code-Qualität

Nachdem wir die zu erfüllenden Anforderungen kennen, müssen wir nun Merkmale finden in denen sich die Anforderungen widerspiegeln. Merkmale, die es erlauben den Grad zu messen in dem die Anforderungen erfüllt sind. Es giebt eine unglaubliche Menge von Vorschlägen für Eigenschaften, Merkmalen oder Qualitäten die Code haben sollte oder nicht haben dürfen soll um als „guter Code“ zu gelten. Man kann diese Merkmale auch — zumindest teilweise — den genannten Anforderungen zuordnen.

Und an dieser Stelle fangen die Probleme an. Die Menge der Regeln ist riesig und die der diskutierten Auslegungen unüberschaubar. Tatsächlich ist die Vorstellung von Code-Qualität nicht absolut. Sie ist abhängig von Zeit, Kultur, verwendeter Technologie, Fachlichkeit und vielen anderen Faktoren. Die wenigen allgemeingültigen Regeln sind dermaßen abstrakt formuliert, daß sie kaum unmittelbar anwendbar sind. Und sobald man versucht ihre Anwendung zu konkretisieren, starten die Diskussionen.

Jedes Team und jede Organisation, die versucht die Code-Qualität zu verbessern muß damit beginnen ein gemeinsames Verständnis für die Qualität zu entwickeln. Ohne ein solches Verständnis findet man keine Einigung und Regeln werden entweder gar nicht erfüllt oder sie werden nur um der Erfüllung willen erfüllt. Gesetzte Regeln müssen verstanden und immer wieder auf ihre Sinnhaftigkeit hinterfragt werden. Das ist aufwändig und erfordert Engagement — wer ist bereit dafür Energei aufzubringen?

In den alten Tagen war es üblich, Code-Qualität am Verhältnis von Kommentar- zu Code-Zeilen zu messen. Je größer das Verhältnis desto besser. In der Folge sind viele Entwickler dazu übergegangen, den Code mit leeren Kommentar-Zeilen aufzufüllen. Die Metrik wird erfüllt, aber was hat das mit Qualität zu tun?

Metriken führen nicht zu Code von besserer Qualität,
sondern zu Code der die Metriken erfüllt.

Moderne Metriken scheinen besser geeignet zu sein. Man zählt die Methoden der Klasse, die Zeilen von Methoden und Funktionen, man mißt die Abdeckung des Codes mit Unit-Tests und die Kohärenz in Modulen. Aber was ändert das an der Einstellung des Entwicklers? Wer schnell viel Code generieren will (oder muß), der findet Wege die Metriken zu erfüllen ohne dabei die Code-Qualität ändern zu müssen.

Qualität ist die Einstellung des Entwicklers,
die vom Code reflektiert wird.

Macht das Regeln — und die Metriken die sie messen — überflüssig oder unsinnig? Nein. Der qualitätsorientierte Entwickler sollte alle Mittel nutzen — und zumindest ernsthaft erproben — um die Qualität zu verbessern. Die vielleicht beste Formulierung diese Gedankens stammt von Michael Feathers:

Clean Code always looks
like it was written by someone who cares.

Michael Feathers

Die Kommentar-Metrik zeigt aber noch ein anderes Problem. Keine Metrik kann messen wie hoch der Bezug ist den der Code zu seiner Semantik hat. Man könnte diese Eigenschaft als „Angemessenheit“ bezeichnen. Betrachten wir diese Zeile:

int x = a + b;

Sie ist zu umfangarm um irgendeine Aussage über ihre Qualität zu machen. Sobald wir aber die Variablen umbenennen und schreiben:

int differenz = soll + ist;

macht die Zeile überhaupt keinen Sinn mehr. Sie widerspricht sich plötzlich selbst. Die zusätzliche semantische Information die durch die Bezeichner transportiert wird ist für den Compiler schlichtweg unsichtbar. Ebenso wie die Information die gar nicht im Code enthalten ist, weil sie nur im Fachkonzept existiert.

Was können wir also über die meßbaren Merkmale von Code-Qualität sagen? Sobald wir festgelegt haben, welchen Regeln wir folgen möchten, können wir dazu Merkmale festlegen an denen wir die Code-Qualität messen können. Sobald sich unser Verständnis der Qualität ändert müssen wir die Merkmale anpassen. Ausreichend sind solche Merkmale aber nicht, die Übereinstimmung des Codes mit seiner Bedeutung können sie nicht erfassen.

Veröffentlicht am von

Code-Qualität, Vorbemerkung

Bevor man über einen Begriff diskutiert, muß man festlegen, was man damit eigentlich meint. Wir können erstmal beim landläufigen Verständnis dafür bleiben, was „Code“ ist, aber was ist eigentlich „Qualität“?

Der Bedeutung des Wortes nach bezeichent „Qualität“ zunächst „die Beschaffenkeit von irgendwas“. Meint also irgendeine Eigenart des betrachteten Objekts, wie die Farbe oder die Größe. Dem Wesen nach bedeutet (eine) Qualität also (eine) Eigenart die irgendwie ausgeprägt sein kann. Eine allgemeine oder absolute Bedeutung hat der Begriff zunächst nicht — es macht also keinen Sinn von der Qualität einer Sache zu sprechen. Auch ist noch keine Aussage darüber gemacht in welcher Weise oder Menge das Objekt die Eigenschaft erfüllt. Und auch nicht, ob dieser Zustandgut ist oder schlecht. Oder so gefragt: Hat das Objekt mehr oder weniger? Ist mehr besser oder schlechter?

Um mit dem Begriff „Qualität“ etwas sinnvolles bezeichnen zu könnne, definiert ihn die ISO so:

Grad, in dem ein Satz inhärenter Merkmale eines Objekts Anforderungen erfüllt.

Es geht darum, daß das Objekt Anforderungen erfüllen muß; gemessen an einer definierten Menge von Eigenschaften die dem Objekt zu eigen sind (also nicht zugesprochen werden). Anhand der Merkmale soll bestimmt werden, inwieweit die Anforderungen erfüllt sind; die Merkmale müssen also meßbar sein, einen Bezug zu den Anforderungen haben und Aufschluß darüber geben, ob die Anforderungen erfüllt sind.

Zu abstrakt? Ein Computer-Programm wird nicht verwendet, wenn die Berechnung zu lange dauert. Man verlangt also als Anforderung: 5 ms nach Eingabe muß das Ergebnis am Bildschirm erscheinen. Das Merkmal ist die Verarbeitungsgeschwindigkeit (daß diese vom verwendeten Computer abhängt übersehen wir hier mal). Der Grad der Erfüllung ist die Differenz zwischen den 5 ms und der tatsächlichen Ausführungszeit.

Um die Qualität bestimmen zu können benötigen wir also:

  • Anforderungen
  • Merkmale die die Erfüllung dieser Anforderungen widerspiegeln
  • Einen Weg diese Merkmale am Objekt zu messen
  • Schwellwerte, die die Erfüllung der Anforderung signalisieren

Um von der Qualität eines Objekts sprechen zu können, benötigen wir also immer einen Kontext. Es muß klar sein, welche Anforderungen vom Objekt erfüllt werden sollen. Die Anforderungen und die Mekmale, die als Indikator für deren Erfüllung dienen, müssen feststehen; dann können wir darauf verzichten sie jedesmal aufzuzählen und sprechen von der Qualität des Objekts.

Veröffentlicht am von

Warum Code-Qualität wichtig ist

An jedem Software-Projekt ist eine Unmenge von Leuten beteiligt die die unterschiedlichsten Rollen wahrnehmen. Da gibt es Projektleiter, Fachspezialisten, Tester, Architekten, Designer und was sonst noch alles. Je größer das Projekt, desto größer die Zahl der Beteiligten. Und wenn die Software in den Betrieb geht kommen noch mehr Leute und noch mehr Rollen hinzu. Software ist — heute mehr denn je — ein Team-Produkt.

Wer in obiger Aufzählung nicht erwähnt wurde, das sind die Coder, die Programmierer oder Software-Ingenieure. Diejenigen, die — in der Sprache der Machine — das formulieren, was die Maschine später zu tun hat. Ihnen kommt eine einzigartige Bedeutung zu. Denn nüchtern betrachtet ist ihre Arbeit das einzige, was am Ende übrig bleibt und tatsächlich „etwas tut“ wenn die Software live geht.

Das bedeutet nicht, daß der Rest des Teams überflüssig wäre — ganz im Gegenteil. Erst die gemeinsame Anstrengung macht den Erfolg des Projektes überhaupt erst möglich. Der Projekt-Plan ist wichtig um das Projekt durchzuführen, verschwindet aber wenn das Projekt abgeschlossen ist. Die Arbeit der Tester ist ein wichtiger Bestandteil des Entwicklungsprozesses, aber am Ende läuft nur noch der Code; von den Testläufen ist am Ende nur noch das Ergebnis übrig.

Es ist so ähnlich wie bei einer militärischen Operation. Von vier eingesetzten Soldaten werden drei für Transport, Versorgung und Unterstützung der Truppen — von der Verpflegung bis zur Flugabwehr — benötigt. Der eigentlichen Kampf — Mann gegen Mann — wird in der ganzen Kette von einer erstaunlich kleinen Gruppe geführt. Alle Beteiligten sind wichtig, alle Beteiligten setzen sich sich Lebensgefahr aus, aber die Schlacht wird letztenendes von den Kampftruppen entschieden.

Wenn dann die Anwendung im Betrieb ist, das Team sich anderen Projekten widmet und in der Software ein Problem auftritt, dann zeigt sich wie gut der Coder tatsächlich gearbeitet hat. Denn oft genug sind diejenigen die die Anwendunng betreuen nicht die gleichen wie die die sie gebaut haben. Dann zeigt sich, ob der Code sauber entwickelt oder einfach nur heruntergerotzt wurde.

Jeder im Projekt muß solide Arbeit leisten wenn das Endprodukt erfolgreich sein soll. Aber wenn das was der Coder baut nur gerade eben das tut was die Anforderungen verlangen, schläft in der Anwendung eine Bombe die mit Sicherheit dann hochgeht, wenn man es am wenigsten gebrauchen kann. Wenn dann Fragen auftauchen wie „Was macht eigentlich diese Funktion?“ oder „Was geschieht, wenn man diesen Wert ändert?“, dann zahlt man doppelt und dreifach was man im Projekt an der Entwicklung gespart hat.