Qualität

Wie so vieles im Leben ist Qualität nicht etwas Absolutes. Qualität ist nicht mit Kategorien wie Richtig und Falsch, An und Aus, Ja und Nein zu fassen. Das klingt banal, aber trotzdem scheint es, als würde allzu oft aus dieser Banalität nicht der naheliegende Schluss gezogen.

Wenn Qualität kein Absolutum ist, dann benötigen wir einen Maßstab, um sie einschätzen, um sie bewerten und vergleichen zu können. Wie sieht es damit in den Web-Firmen aus? Vor allem, wenn wir jetzt mal die gängigen Allgemeinplätze beiseiteschieben.

Machen wir es konkret und betrachten einfach einmal Lint (oder den Linter), ein wunderbares Tool zur automatischen Analyse von Code, beispielsweise – und sehr gängig – von JavaScript-Code. Lint tut das, indem es den Code auf die Einhaltung bestimmter Regeln hin untersucht und auf Fehler oder Bad Practice hinweist. Sprich: indem es einen Maßstab mitbringt, an dem es den Code misst, beispielsweise diesen für ES6: eslint.org/docs/rules/.

Der Regelfall, den ich in den verschiedensten Umgebungen erlebe, ist, dass Lint dabei stets mit der vollen Palette an Vorgaben eingesetzt wird, auch solchen, die nicht unbedingt sinnvoll sind oder über die man zumindest diskutieren könnte.

Wir können beispielsweise grundsätzlich die Verwendung einfacher Vergleichsoperatoren (==, != etc.) verbieten, etwa um insbesondere wenig erfahrene Entwickler nicht in die Falle unbeabsichtigter impliziter Typkonvertierung laufen zu lassen. Oder um uns einfach zu ersparen, genau daran jedes Mal denken zu müssen. Wir können aber auch entscheiden, dass wir beispielsweise im Zusammenhang mit dem Operator typeof einfache Vergleiche zulassen, weil er immer Strings liefert (→ https://eslint.org/docs/rules/eqeqeq  – auf Option smart achten).

Wir können verkürzte bedingte Ausdrücke zwecks besserer Lesbarkeit des Codes verbieten. Wir können so etwas wie foo.isNew && feed.addItem(foo) aber auch zulassen, weil’s bei kompakten Ausdrücken und vernünftig benannten Variablen und Funktionen einfach eine angenehme Abkürzung ist (→ eslint.org/docs/rules/no-unused-expressions – auf Option allowshortcircuit achten).

Wir können auch das nach wie vor absolut gültige und keineswegs veraltete oder unsaubere var für Variablendeklarationen verbieten. Ja, wir können sogar die Verwendung von const erzwingen, wenn sich der Wert einer Variablen im Geltungsbereich nicht ändert. Wir können allerdings auch zu dem Schluss kommen, dass zumindest letzteres ein wenig sinnvoller Formalismus ist und dass wir const ganz bewusst ausschließlich für Variablen verwenden, die von ihrem Sinn und ihrer Bedeutung her (also konzeptionell, nicht programmlogisch) unveränderlich sein sollen. Dass wir const also nicht missbrauchen, um anzuzeigen: »Du, guck mal, diese Variable ändert sich zufälligerweise gar nicht.« (→ eslint.org/docs/rules/prefer-const) – Ein JS-Entwickler sollte einfach wissen, wie var, let und const funktionieren und was sie bedeuten!

Mir geht es hier gar nicht darum, eine ermüdende und vollkommen überflüssige Debatte darum aufzumachen, was die einzig wahre Lint-Konfiguration ist oder was der einzig zulässige Code-Stil.

Nein, ich möchte vielmehr dazu anregen, dass wir uns die Zeit nehmen, uns über das klarzuwerden, was der Begriff Qualität für uns bedeutet. Die Zeit, genau den Maßstab für uns zu finden, von dem ich eingangs sprach und der eben nicht für alle und in allen Fällen identisch ist.

Ich möchte dazu anregen, Entscheidungen bewusst zu fällen und nicht in den Irrtum zu verfallen, dass aus möglichst vielen und möglichst spezifischen und strengen Regeln automatisch ein umso besseres Produkt entspringt. (Besser in Bezug auf was?) Oder dass Entwickler, die nach einem anderen Maßstab arbeiten, automatisch schlechte Entwickler sind oder fehlerhaften Code schreiben.

Es ist beispielsweise sinnvoll, einfach einmal in die lobens- und dankenswert ausführlichen Beschreibungen der Lint-Optionen zu schauen und sich immer wieder klarzumachen, dass es in den meisten Fällen nicht um Richtig und Falsch geht. Sondern dass man ausgehend von der Beschreibung der Option frei entscheiden kann, ob sie für die aktuellen Rahmenbedingungen eine Rolle spielt oder nicht.

Reiner Formalismus ist in der Qualitätssicherung ebenso trügerisch wie sonst überall auch.