Rezension: Software-Fehler erkennen und vermeiden, 2. Auflage Aus Fehlern Software-Entwicklung lernen

Anbieter zum Thema

MicroConsult Academy GmbH

Parasoft® Deutschland GmbH

Der vernünftige Umgang mit Fehlern gehört zu den oft unterschätzten Anforderungen, die ein guter Entwickler mitbringen sollte. Im Studium wird dieser Aspekt oft vernachlässigt. Diesen Umstand adressiert Dieter Duschls Buch „Software-Fehler erkennen und vermeiden“, der mit praxisbezogenen Beispielen und Erfahrungen gerade für Einsteiger in die Programmierung mit C/C++ wertvolle Erkenntnisse in Sachen Fehlerkultur und Awareness bietet.

Software durchdringt längst nahezu alle technischen Produkte und betrieblichen Abläufe. Angehende Entwickler lernen in Studium und Ausbildung in der Regel vordergründig, wie sich Programme entwerfen und zum Laufen bringen lassen. Was allerdings oft nicht vermittelt wird, ist, weshalb sie unter realen Bedingungen scheitern, wie seltene Fehler systematisch untersucht werden, oder welche organisatorischen Folgen mangelhafte Softwarequalität haben kann. Angehende Programmierer müssen sich daher oft mit eigenen Experimenten und Scheitern den vernünftigen Umgang mit Fehlschlägen und falschen Entscheidungen in der Entwicklung selbst aneignen.

Gerade beim Übergang in die industrielle Praxis entsteht deshalb Bedarf an Praxisberichten oder Erfahrungen, die nicht nur korrekte Lösungen aufzeigen, sondern auch bereits im Grundsatz Fehlentwicklungen, Diagnosewege und die daraus gewonnenen Erfahrungen sichtbar machen. An dieser Stelle setzt Dieter Duschls Studienbuch „Software-Fehler erkennen und vermeiden“ an, das mittlerweile in der zweiten Auflage erschienen ist. Es richtet sich primär an Studierende, Berufseinsteiger und Projektverantwortliche und zeigt mit historischen Werkzeugen, bekannten katastrophal verlaufenen Software-Projekten sowie praktischen Industrieerfahrungen, wie Softwarefehler entstehen, und warum Technik allein sie selten verhindert.

Zwischen Lehrbuch, Fallstudie und Erfahrungsberich

Für ein Lehrbuch wirkt der Aufbau von „Software-Fehler erkennen und vermeiden“ auf den ersten Blick etwas ungewöhnlich. tatt mit Testtheorie oder einer systematischen Fehlerklassifikation zu beginnen, stellt Duschl zunächst Turbo Assembler und Turbo Debugger, Visual Studio, Modula 2 sowie LabWindows CVI vor, bevor er „Hallo Welt“ in mehreren Varianten bespricht. Hier macht sich die anvisierte Zielgruppe von studierenden oder Einsteigern in die Programmierung mit C und C++ am Stärksten bemerkbar. Im Anschluss folgen bevor bekannte Softwarekatastrophen, industrielle Praxisfälle, Testverfahren und Debugging in weiteren Kapiteln. Auch auf Managementprozesse, Best Practices und das Trendthema künstliche Intelligenz wird eingegangen. In diesen Kapiteln stehen Historische Werkzeuge, Grundlagen, persönliche Projekterfahrungen und allgemeine Software-Engineering-Prinzipien teilweise unvermittelt nebeneinander.

Das Buch entwirft allerdings abstraktes Lehrgebäude, wie es bei Kursen zur Programmierung oder in Studienlehrplänen oft der Fall ist. Stattdessen sondern führt es durch Situationen, in denen Entwickler Fehler tatsächlich erleben: beim Übersetzen, Linken und Debuggen, bei Speicherzugriffen, im Austausch mit Testern oder erst beim Kunden. Praxisorientierung steht dabei klar im Vordergrund: Kleine Programme, Konsolenausgaben und Debugger-Bilder sollen Fehler reproduzierbar und die Wirkung einzelner Befehle sichtbar machen.

Fehler bleiben keine abstrakten Kategorien, sondern werden als beobachtbare Zustandsänderungen verständlich. Der große Anteil an DOS-, Assembler- und Modula-2-Werkzeugen mag, die hierbei Erwähnung finden, mag insbesondere aus einer IT-Perspektive etwas aus der Zeit gefallen wirken. Für hardwarenahe Entwicklung, wie sie besonders bei Embedded-Systemen notwendig ist, bietet auch dies allerdings mitunter wertvolle Erkenntnisse. Denn der Umgang mit Registern, Speicheradressen oder Stack Overflows tritt hierdurch mehr in den Vordergrund.

Praxisfälle als größte Stärke

Am stärksten ist das Buch dort, wo es technische und organisatorische Ursachen verbindet. Die Fälle des London Ambulance Service, des Mars Climate Orbiter, der Patriot-Abwehrrakete und des Therac-25 zeigen, dass folgenschwere Ausfälle selten auf eine einzelne falsche Codezeile zurückgehen: Falsche Einheiten, Rundungsfehler, Race Conditions, schwache Tests, fehlende Dokumentation und organisatorischer Druck greifen ineinander.

Noch anschaulicher sind die Industrieerlebnisse des Autors selbst. Besonders einprägsam ist die Beschreibung eines Vorfalls, bei der eine Maschine, die beim Hersteller zuverlässig läuft, beim Kunden aber Hitze, Erschütterungen, Dreischichtbetrieb und schließlich einem Festplattenschaden ausgesetzt ist. Die reale Betriebsumgebung ist Teil des Systems. Embedded-Software muss sich nicht nur korrekt verhalten, sondern Ausfälle überstehen und im Servicefall verwertbare Informationen liefern.

Ähnlich lehrreich ist die Post-Mortem-Diagnose. Absturzbild, Softwareversion, Absturzadresse und letzte Bedienereingaben werden gesichert, damit ein Fehler später rekonstruiert werden kann. Die Technik ist historisch, das Prinzip hochaktuell. Moderne Crash Dumps, Logging, Telemetrie und Tracing verfolgen denselben Zweck.

Für Einsteiger wertvoll ist außerdem die Betonung von Lesbarkeit, Initialisierung, klaren Schnittstellen und überprüfbaren Zuständen. Das Buch wendet sich gegen die automatische Gleichsetzung von kompaktem oder vermeintlich elegantem Code mit gutem Code. Wartbarkeit bedeutet hier, dass andere Teammitglieder das Ziel einer Funktion in vertretbarer Zeit verstehen können. Auch das Testkapitel bietet eine solide Grundlage: Unit-, Integrations-, System- und Abnahmetests werden ebenso erläutert wie Black-, White- und Gray-Box-Verfahren.

Damit greift Duschl eine Erfahrung auf, die Studierende während ihrer Ausbildung oder Programmierer, die sich den Umgang mit C und C++ selbst erarbeiten, oft nur eingeschränkt machen dürften. Kleine Übungsprogramme werden meist allein entwickelt, laufen in einer kontrollierten Umgebung und werden nach der Abgabe oder einmaligen Testausführung kaum weiter gepflegt. In industriellen Projekten muss Software dagegen über Jahre verständlich, erweiterbar und diagnostizierbar bleiben. Sie wird von wechselnden Teams bearbeitet, kommuniziert mit Hardware und muss auch dann noch funktionieren, wenn einzelne Komponenten ausfallen oder Anwender ganz anders mit dem System umgehen als ursprünglich angenommen.

Gerade für Embedded-Entwickler ist diese Perspektive wertvoll. Das Buch behandelt Software nicht als isoliertes Produkt, sondern als Bestandteil technischer Anlagen. Fehler entstehen deshalb nicht ausschließlich im Quellcode. Sie können aus ungeklärten Anforderungen, ungeeigneten Datentypen, Hardwareproblemen, fehlenden Backups, einer unrealistischen Testumgebung oder mangelnder Kommunikation zwischen Entwicklung, Service und Kunden hervorgehen.

Auffällige Neuerung: Umgang mit dem Collatz-Problem

Gegenüber der ersten Auflage vom September 2024 wurden nach Angaben des Autors Programme überarbeitet und über den Verlag bereitgestellt, Grafiken verbessert sowie kleinere Fehler beseitigt. Die auffälligste und möglicherweise ungewöhnlichste inhaltliche Ergänzung ist ein neuer Abschnitt zur Collatz-Vermutung.

Das Beispiel zeigt anschaulich die Grenzen erfolgreicher Testläufe. Für kleinere Startwerte funktioniert das Programm, bei einer Erweiterung des Zahlenbereichs tritt jedoch ein Integer-Overflow auf. „Läuft bei meinen Beispielen“ ist eben keine belastbare Qualitätsaussage. Programme müssen innerhalb definierter Wertebereiche arbeiten, Grenzüberschreitungen erkennen und angemessen behandeln. Gerade für Embedded-Entwickler mit festen Datentypen, begrenztem Speicher und langen Laufzeiten ist das durchaus relevant.

Die Collatz-Passage ist deshalb mehr als ein mathematischer Exkurs. Sie führt vor, wie leicht Entwickler von erfolgreichen Tests auf eine allgemeine Korrektheit schließen können. Ein Programm kann für Hunderte oder Tausende Eingabewerte zuverlässig erscheinen und dennoch an einer später erreichten Grenze scheitern. Die Lektion lässt sich direkt auf Zähler, Zeitwerte, Sensorbereiche, Speicheradressen oder lange Betriebszeiten eingebetteter Systeme übertragen.

Allerdings weist dieser Abschnitt mehr auf die grundsätzliche Existenz dieses Problems in bestimmten Fällen hin; also Musterlösung sollte man sie nicht verstehen. so ist es etwa strittig, ob die im Buch angesprochenen Gleitkommatypen das Problem wirklich beheben oder möglicherweise nur verschieben, und ob nicht etwa andere Lösungen robuster wären. Ihren wichtigsten didaktischen Zweck erfüllt die Ergänzung dennoch: Sie zeigt, wie ein scheinbar korrektes Programm erst unter erweiterten Randbedingungen scheitert.

Innovate Your Software – for a Smarter Future

Deutschlands Leitkongress der Embedded-Softwarebranche

Das Programm des ESE Kongress umfasst 96 Vorträge, 21 Seminare und 3 Keynotes. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der vier Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI, Safety und Security bis hin zu Management und Innovation.

Jetzt mehr erfahren und anmelden!

Fokussierung auf ältere C- und C++-Standards

Wenngleich bei den Fallbeispielen und praktischen Erfahrungen der historische Bezug sehr wertvoll für das gesetzte Ziel der Wissensvermittlung ist, offenbart sich in diesem Zusammenhang auch etwas, dass manche modernen Entwickler als Schwäche auffassen dürften: Das Buch greift primär ältere C- und C++-Paradigmen auf und arbeitet mit Visual Studio 2022. Neuere Standards und Änderungen nach C++17 bis C++23 kommen kaum vor. Auch andere in der modernen Software-Entwicklung eingesetzten Tools und Methodiken, wie beispielsweise Sanitizer, moderne statische Analyse, automatisierte Build-Pipelines oder Fuzzing, werden nur wenig oder stellenweise gar nicht behandelt. Als ergänzendes Studien- und Praxisbuch ist das vertretbar. Als eine alleinige Einführung in die moderne Software-Qualität sollte es aber nicht verstanden werden.

Das macht sich esonders an den verwendeten Operator-Beispielen bemerkbar. Ausdrücke wie „iTest += ++iTest“ oder „iTest += iTest++“ werden im Buch mit konkreten Resultaten erläutert. Die daraus folgende Bewertung ist jedoch schwer von der Sprache und der gültigen Standardversion abhängig; dies weird im Buch leider nicht ausdrücklich erwähnt. Modernes C++ legt bestimmte Auswertungsreihenfolgen klarer fest als ältere Standards oder C. Für Einsteiger wäre deshalb die wichtigste Lehre aus diesen Beispielen nicht das Ausrechnen solcher Konstrukte, sondern deren Vermeidung durch verständliche Einzelschritte.

Aber hierdurch macht sich auch die grundsätzliche Ausrichtung des Buches am Stärksten bemerkbar: Der Autor möchte Entwickler dafür sensibilisieren, dass sprachlich erlaubte Konstruktionen nicht automatisch wartbar oder empfehlenswert sind. Diese Botschaft ist richtig. Die konkrete Erklärung müsste jedoch deutlicher zwischen C, älteren C++-Versionen und aktuellen Standards unterscheiden. Gerade Anfänger dürften hier eine klare Einordnung benöitigen, weil ihnen noch die Erfahrung fehlt, allgemeine Regeln von historisch oder compilerabhängigem Verhalten zu trennen.

Auch weitere Aussagen benötigen Einordnung. Automatische lokale Variablen sind in C und C++ ohne Initialisierung nicht gewöhnlich mit null vorbelegt, sondern besitzen einen unbestimmten Wert. Die Empfehlung, Variablen sofort zu initialisieren, bleibt richtig; ihre Begründung ist missverständlich. Beim Refactoring wirkt der Autor stellenweise zu defensiv, da moderne Entwicklung eher auf kleine, durch Tests abgesicherte Änderungen setzt.

Bei einem Studienbuch wäre es wünschenswerter, wenn besser auf solche potentiellen Stolperstellen eingegangen würde. Wer den Band im Selbststudium verwendet, sollte ihn deshalb mit aktueller Literatur zur jeweils eingesetzten Sprache verbinden. Am besten eignet sich das Werk daher wahrscheinlich als Ergänzung zum Studium: So könnten in einer Lehrveranstaltung oder in Kursen zur C- und C++-Programmierung die entsprechenden Stellen etwa als Ausgangspunkt dienen, um Veränderungen der Standards, Compilerverhalten und moderne Entwicklungspraktiken zu diskutieren.

Was positiv auffällt ist, dass das im Juli 2025 in der zweiten Auflage erschienene Bereich bereits auf den Einsatz von Künstlicher Intelligenz in der Softwareentwicklung eingeht. Der im Buch verwendete Ansatz ist lobenswert, weil er Coding-Assistenten nicht nur bewirbt, sondern ebenfalls praktisch erprobt und Erkenntnisse zieht. So werden hier TabNine, IntelliCode und ChatGPT werden zur Codevervollständigung und Erzeugung kleiner Programme eingesetzt. Sogar ein in der Erfahrung des Autors aufgetretener fehlerhafter Vorschlag ist näher dokumentiert wird. In einem gedruckten Buch sind solche auf aktuelle Trends eingehende Kapitel natürlich immer mit Vorsicht zu genießen: Gerade bei Coding-Agenten und Sprachmodellen schreitet die Entwicklung derart rapide voran, dass die zur Drucklegung des Buches gültigen Erkenntnisse zwangsweise bereits überaltert wirken.

Die grundsätzliche Schlussfolgerung bleibt allerdings richtig und dient als allgemeines Mantra: Entwickler dürfen sich nicht vollständig auf KI-Ausgaben verlassen. Gerade für Einsteiger ist diese Haltung hilfreicher als pauschale Euphorie oder Ablehnung: KI-Werkzeuge können Routinearbeit beschleunigen, Codegerüste erzeugen und beim Einstieg in unbekannte Funktionen helfen. KI-Vorschläge sind allerdings nur Ausgangspunkte, keine geprüften Lösungen. Coding Agents ersetzen weder das Verständnis des Programmierers zum erzeugten Codes noch Tests, Reviews und die Verantwortung des Entwicklers; und die Erkenntnis, frühe Fehlentwicklungen zu erkennen und zu korrigieren.

Ergänzendes Praxisbuch für den Berufseinstieg

Wohlgemerkt: „Software-Fehler erkennen und vermeiden“ ist kein vollständiges Lehrbuch über moderne Testautomatisierung, Secure Development oder aktuelle C++-Standards. Dafür ist seine Zusammenstellung zu eigenwillig und seine Perspektive stellenweise zu historisch. Als ergänzendes Praxisbuch besitzt es jedoch erheblichen Wert.

Besonders empfehlenswert sind die Kapitel zu bekannten Softwarekatastrophen, industriellen Fehlerfällen, Testen und Post-Mortem-Diagnose. Sie vermitteln, dass Softwarequalität nie durch eine einzelne Methode entsteht. Gute Werkzeuge helfen, doch ebenso wichtig sind klare Zuständigkeiten, reproduzierbare Zustände, verständlicher Code, realistische Tests und eine Kultur, die Probleme nicht versteckt.

Studierende und Berufseinsteiger erhalten damit etwas, das in vielen Lehrveranstaltungen zu kurz kommt: einen Eindruck davon, wie unübersichtlich reale Projekte werden und wie stark technische Entscheidungen mit Kosten, Lieferterminen, Serviceeinsätzen und Kundenvertrauen verbunden sind. Embedded-Entwickler werden viele Situationen wiedererkennen, in denen Hardware, Laufzeitumgebung und über Jahrzehnte gepflegte Softwarestände die reine Programmlogik überlagern.

Daraus erklärt sich denn auch der für einen Studierenden möglicherweise ungewohnt wirkende Aufbau des Buchs: Der Autor folgt weniger einem streng akademischen Lehrplan als dem Erfahrungsweg eines Praktikers. Dadurch wirkt das Werk zwar gelegentlich sprunghaft, erreicht aber eine Anschaulichkeit, die systematischere Lehrbücher nicht immer bieten. Leser begegnen Fehlern nicht nur als Definitionen, sondern als konkrete Ereignisse mit technischen, menschlichen und wirtschaftlichen Folgen.

Als Empfehlung gilt, das Buch zusammen mit aktuellen Quellen zu modernen C++-Standards, Continuous Integration, statischer Analyse, Security und KI-gestützter Entwicklung zu lesen. Dann kann seine persönliche und historische Perspektive ihre größte Wirkung entfalten. Sein dauerhaftester Wert liegt weniger in den konkreten Werkzeugen und Regeln als in der Erfahrung, dass Softwarefehler fast immer im Zusammenspiel von Code, Umgebung, Prozessen, Kommunikation und wirtschaftlichem Druck entstehen – eine Einsicht, die besonders für Entwickler, die gerade vom Software-Studium ins Berufsleben übertreten, unverzichtbar ist.

 (sg)

(ID:50918593)