- Profit ist wichtig und für das Weiterbestehen einer Firma notwendig. Wer jedoch die Qualität eines Produkts ausschließlich über Kosten definiert, um damit den Profit zu maximieren, hat den Job nicht verstanden.
- -- Daniel Goeudevert
Qualitätskontrolle für Ubuntu ist auf Golem zu lesen. Qualitätskontrolle ist eine gute Idee, grundsätzlich zumindest. Es ist halt nur die Frage, wie man sie aufzieht. Eine Qualitätskontrolle, in der man einen Benutzer an die Software (ich beschränke mich jetzt mal auf diesen Fall) ransetzt ist einer der wichtigsten und effektivsten Weg, mit denen man die Produktion von Software verbessern kann. So gibt es zum Beispiel die Legende, das die C/C++-Entwicklungsumgebung, die dann später Visual C++ wurde, am Anfang mächtig gewaltig abgestunken haben soll. Dies hat sich der Legende nach erst dann verbessert, als die Entwickler per Dienstanweisung dazu gezwungen wurden, ihren eigenen Kram auch selbst einzusetzen um die Weiterentwicklung voran zu treiben. So wurde die Entwickler gleich zu ihren eigenen Testern. Mir geht es bei der Software, die ich für mich schreibe genauso. Da hat die Erfahrung gezeigt, dass nur Software, die ich auch selbst verwende, wirklich benutzbar wird.
Ein anderer Weg die Qualität von Software zu verbessern ist die sogenannte statische Codeanalyse. Das bedeutet, dass Software, ähnlich einem Compiler den Quelltext analysiert, aber nicht um ausführbaren Code daraus zu machen, sondern um
mögliche Fehler wie die Verwendung von nicht initialisierten Variablen oder Speicherlöchern aufzudecken, wie zum Beispiel
lint. Klingt toll, muss es aber nicht unbedingt sein. Erstmal sind diese Tools bei weitem nicht so clever, dass sie wirklich erkennen können, ob es sich um ein Problem handelt oder nicht, sondern halt nur den Hinweis geben können: es
kann sein, dass hier etwas nicht stimmt. Wenn der Code wirklich so in Ordnung ist, dann muss über einen Kommentar gesagt werden, dass dies wirklich so gemeint ist, und der Hinweis nicht mehr angezeigt werden soll. Dieses Tool ist wertvoll, wenn es darum geht, Programmierer "zu erziehen", also ihnen mögliche Probleme, mit dem was sie da gerade verbrochen haben, im Vorfeld aufzuzeigen.
Leider werden diese Tools aber auch gerne anders eingesetzt. Zum Beispiel vom Management. Da kommen dann Vorgaben wie: "in nächsten drei Monaten soll die Anzahl der lint-Meldungen um 50%25 sinken." Also verwenden die Programmierer jetzt einen nicht unerheblicher Teil ihrer Arbeitskraft um mit oberflächlichem rumgehacke und Tricks diese Quoten zu drücken, statt wirklich den Code zu verbessern. Ich habe es schon erlebt, dass die Behebung eines Fehlers nicht ins Depot eingecheckt werden durfte, weil sich dadurch die Anzahl der lint-Warnungen erhöht. Die Entscheidung kam von einem Manager, der seinem Tool hörig war. Ist aber nur meine persönliche Meinung...
Ähnlich schlimm ist es aber auch, jemand mit solchen Werkzeugen versucht, den Code anderer Leute damit zu verbessern. Auch dafür gibt es ein sehr schönes Beispiel: ein Entwickler verwaltet Code, den er nicht selbst geschrieben hat, für eine Linux-Distribution. Er führt eine solche Analyse über den von ihm betreuten Code aus, und bekommt eine Warnung, dass an einer Stelle eine nicht, beziehungsweise nur teilweise, initialisierte Datenstruktur an eine Unterroutine übergeben wird. Der Grund für die Warnung ist: wenn diese Unterroutine nun auf den "Datenmüll" im nicht initialisierten Bereich zugreift, muss das ja zwangsläufig zu Fehlern führen. Daraufhin hat er diesen Aufruf nach kurzer Rückfrage mit dem Entwicklerteam der Software entfernt. Im Prinzip richtig, nur hat die Unterroutine genau das Gegenteil gemacht: sie hat dort nicht Daten gelesen, sondern die Struktur "richtig" initialisiert. Und dass diese "richtige" Initialisierung nicht stattgefunden hat, hat nun dafür gesorgt, dass die Software mit erheblichen Mängeln weiter lief. Leider passierte dies an einer Stelle, die richtig weh tat: der
Erzeugung von Kryptografie-Schlüsseln, von denen nun viele alles andere als sicher sind und ersetzt werden müssen.
Deshalb mal hier der Hinweis: auch eine Qualitätskontrolle muss nicht zwangsläufig die Qualität verbessern, und trotzdem würde wohl niemand auf die Idee kommen auf mal die Qualitätskontrolle einer solchen zu unterziehen, glauben aber alles blind, was von dort kommt.
Trotz allem rumgemaule hier möchte ich mich hier nochmal bei allen Qualitätskontrolleuren bedanken, die Fehler gefunden haben, die ich gemacht habe...
Aber um nochmal zum Anfang meines Artikels zurückzukommen. Liebes Ubuntu-Qualitätssicherungsteam, bitte
hier anfangen, oder mir wenigstens sagen, wem ich per eMail die Ohren langziehen kann. Das wäre dann mein persönlicher Betrag zur Qualitätssicherung. Aber ich gehe mittlerweile davon aus, dass der Bug erst dann gefixt wird, wenn Ubuntu 8.10 rauskommt, und dann auch eher zufällig, weil sie dann einen Kernel einsetzen, wo der Bugfix von jemanden kommt, der über mehr Kompetenz verfügt.
Kommentare