Maschinelle Code-Inspektion und technische Erfahrung
Wenn Mensch und Maschine aufeinander treffen
Fortsetzung des Artikels von Teil 1
Undefined-Behaviour-Fehler
Trotz aller dieser Vorkehrungen benötigte das Werkzeug nur ein paar Sekunden, um 120 Probleme zu erkennen. Diese wurden als Anmerkungen im Quellcode ausgegeben. Aufbauend auf dieser Analyse würde eine normale formale Code-Analyse - insbesondere wegen der Art der gefundenen Probleme - schnell wertvolle technische Ressourcen beanspruchen. So erkannte das Werkzeug zum Beispiel drei Undefined-Behaviour-Fehler, die jeweils unterschiedliche Ursachen hatten, aber alle nach Angaben des Compilers akzeptabel waren. Zusätzlich wurden 18 Probleme in einer Dataflow-Analyse ermittelt, sowie sieben Verstöße gegen lokale Standards. Auch wenn alle diese Probleme potenziell schwerwiegend sind, kann man nur mit einem genaueren Verständnis des Kontexts und der Absichten des Entwicklers herausfinden, ob irgendeines von ihnen weniger kritisch als ursprünglich angenommen ist. Daneben ermittelte das Werkzeug weitere 89 kleinere Probleme, von denen viele Verstöße gegen »lokale« Kodierungsstandards waren. Angesichts der Tatsache, dass der gewählte Kodierungsstandard für eine Organisation stehen sollte, die Wert auf hochqualitativen Code legt, ist es klar, dass auch diese Verletzungen behandelt werden müssen. Denn ihr Schweregrad ist bis zur Ausführung weiterer Untersuchungen unbekannt.
Auch wenn viele der Probleme sorgfältig von Hand angelegt wurden, fanden nur die besten Analytiker auch solche Fehler, die entweder durch den Menschen oder eine Maschine falsch interpretiert hätten werden können. Dies zeigt nicht nur den Wert einer gründlichen Inspektion, sondern auch die Notwendigkeit technischen Hintergrundwissens. Die wirklichen Vorteile aus diesem Vorgehen ergeben sich aber womöglich bereits aus der Tatsache, dass ein Ingenieur für die Erkennung der meisten Fehler schon viele teure Mannstunden hätte investieren müssen, bevor die »eigentliche« Code-Analyse überhaupt erst begonnen hätte.
Wenn man sich nun wieder den Ergebnissen der automatischen Analyse zuwendet und dabei die »weniger bedeutenden« Probleme weglässt, so bleiben immer noch 44 potenziell schwerwiegende Probleme übrig. Dies ist mehr als die besten Wettbewerbsteilnehmer gefunden haben, und immer noch zu viel, um eine langwierige und kostspielige manuelle Code-Analyse in Betracht zu ziehen. Eine genauere Untersuchung der aufgetretenen Probleme kann auf Code hinweisen, der aus gutem Grund gegen die implementierten Kodierungsstandards verstößt. Ist dies der Fall, dann kann man die entsprechenden Meldungen unterdrücken, das heißt, dass diese nicht mehr in der »aktiven« Meldungsliste erscheinen, aber nach wie vor umfassend nachverfolgbar und mit dem ursprünglichen Problem verknüpft sind. Bei diesem Vorgehen verringert sich die Anzahl der erkannten Probleme auf vier, von denen aber zwei unterdrückt werden. Die zwei verbleibenden »aktiven« Meldungen beziehen sich auf zwei spezifische Regelverletzungen - die Anzahl der statischen Pfade und die zyklomatischen Komplexität. Beide Meldungen beziehen sich auf kontextabhängige, architektonische Probleme, die nur von erfahrenen Entwicklern behandelt werden können. QA-C konnte erfolgreich einen problembehafteten Code für eine formale Code-Analyse vorbereiten durch eine Kombination aus automatisierter Code-Inspektion mit Verständnis für die technischen Absichten und die Nutzung der Erfahrungen des Entwicklers.
Das primäre Ziel des Entwicklerwettbewerbs war es nicht, Ingenieure lächerlich zu machen. Vielmehr wollte man die Effizienz der automatisierten Code-Inspektion vorführen, besonders in Bezug auf die Fähigkeit des Compilers, eine Aufgabe zu erledigen, für die dieser nie ausgelegt worden war. Obwohl die meisten Entwickler nicht besonders viel Wert darauf legen, dass ein Compiler keine Warnmeldungen liefert, kann dies fälschlichen Trost liefern. Andererseits kann man sich bei einer automatisierten Code-Inspektion darauf verlassen, dass sie eine objektive Interpretation der Code-Qualität liefert und - wie hier gezeigt - die Produktivität von Entwicklern aller Qualifikationsstufen verbessern kann.
Seit der industriellen Revolution traf die Aussicht auf Automatisierung auf eine Kombination aus Interesse und Angst. Dies ist zwar verständlich für Organisationen, die entweder zu viel oder zu wenig in Prozesse investierten, die sonst von einem menschlichen Mitarbeiter ausgeführt würden - schließlich ist dies nicht nur mit positiven, sondern auch mit negativen Begleiterscheinungen verbunden. Der hier gezeigte Einsatz einer automatisierten Codeinspektion als Teil eines formalen Code-Analyseprozesses kann die Ergebnisse erheblich verbessern und die Kostenbelastung in der Softwareentwicklung verringern. Diese Einschätzung ist nicht nur eine Reflektion der ursprünglichen Industriellen Revolution, sondern auch die Konsequenz aller einzelnen Entwicklungsschritte, die seitdem in den industrialisierten Ländern erfolgt sind.
Jobangebote+ passend zum Thema
- Wenn Mensch und Maschine aufeinander treffen
- Undefined-Behaviour-Fehler
