Buch-Rezension zu "Debug It!"

"Debug It!" von Paul Butcher erschien 2009 bei The Pragmatic Programmers. Wie es der Titel ahnen lässt, geht es um das Debuggen von Programmen. Braucht es dazu ein ganzes Buch? Ja! Und es verwundert wieso dies nicht schon früher geschrieben wurde.

Unter debuggen verstehen viele Entwickler die Zeit, in der sie mit Hilfe eines Debuggers versuchen zu verstehen, was ihr Programm gerade falsch macht. Butcher beschränkt sich nicht auf diesen kleinen Teil sondern behandelt den ganzen Ablauf der Bugbeseitigung. Dies reicht vom 1. Aufblitzen des Fehlers über die Bugmeldung, der Beseitigung des Bugs bis hin zum Verbessern der Abläufe um solche Fehler nicht erneut zu machen.

Damit sollte klar sein wieso für diesen Teil der Software-Entwicklung ein eigenes Buch angebracht ist.

Reproduzierbarkeit ist die Grundlage

Viel zu oft vermutet man die Ursache eines Bugs an einer bestimmten Stelle. Da man ja weis was es ist, beginnt man gleich zu reparieren. Das Problem tritt danach nicht mehr auf, also muss es gelöst worden sein. Was aber, wenn man mit einem Datensatz testet, bei dem der Fehler gar nicht auftaucht? Dann ist die ganze Aussagekraft des Nachtests dahin.

Der Hinweis von Butcher ist da sehr simpel: Bevor man etwas macht, muss der Fehler reproduziert werden. Ist dies zu komplex oder zu aufwändig, muss man weiter suchen bis man eine einfache, reproduzierbare Möglichkeit gefunden hat, um den Bug ans Tageslicht zu befördern. Dabei genügt es nicht, dass der Bug ab und zu auftritt. Denn wer sagt einem später, dass man den Fehler wirklich behoben hat und nicht nur gerade den Fall erwischt, wo der Bug sich mal wieder nicht zeigt?

Auf den ersten Blick mag dies zu aufwendig erscheinen. Nur wie viel Zeit verliert man wenn man den gleichen Bug ein 2. Mal beheben muss? Oder was ist wenn der Bug erst wieder in der Produktion auftritt? Ist angesichts der möglichen Auswirkungen wirklich keine Zeit für eine genaue Problemanalyse?

Ursachen bekämpfen statt nur Symptome behandeln

Ein weiterer Punkt der viel zu wenig beachtet wird ist was den Bug eigentlich auslöst. Ist es wirklich nur ein Problem des Entwicklers der bei einer Methode mit mehreren Strings als Argumente 2 davon vertauscht? Oder sollte man die Methode nicht ebenfalls anschauen und die Strings reduzieren?

Im Gegensatz zur Reproduzierbarkeit ist die Ursachenbehebung schon deutlich komplexer. Sobald sich die Bugs bei der Methode häufen, kann eine tiefgreifende Anpassung aber wiederum deutlich günstiger sein.

Wann sollen Bugs gefixt werden?

Im Buch werden 2 gegensätzliche Verfahren beschrieben, wie in der Praxis Bugs gefixt werden. Die einen beheben die Bugs sobald sie entdeckt werden, die anderen gehen diese erst am Ende der Entwicklungsphase an. Butcher bevorzugt klar die Variante mit der sofortigen Behebung des Fehlers. Dies gibt einem Vertrauen in den Code, da man weiss wir haben keine Bugs und funktioniert etwas nicht muss es ein bisher noch nicht bekannter Bug sein. Sind die bekannten Bugs gefixt, wird in der regulären Weiterentwicklung festgestellt, dass der Bug behoben ist.

Beim anderen Ansatz vermutet man den Fehler in einem bekannten Bug und ignoriert dies fürs erste. Hat man am Ende der Entwicklungsphase endlich die bekannten Bugs behoben, muss man nachtesten. Dann stellt sich zu oft heraus, dass ein Teil der Probleme nicht durch die gesammelten Bugs verursacht wird, sondern durch neue. So wiederholt sich der Kreislauf mit den Bugfixes, Nachtests und dem finden weiterer Bugs. Nur ist dafür in den meisten Projekten keine Zeit geplant worden und so kommt es zu grossen Verzögerungen.

Ich bin hier ganz der Meinung von Butcher. Die Bugs müssen so oder so behoben werden und dann kann man dies auch gleich machen.

Die Ideale Umgebung fürs Debuggen

Ein ganzes Kapitel ist der Umgebung gewidmet. Dies ist eines der Kapitel, bei dem man nicht einfach als einzelner Entwickler etwas ändern kann. Als unverzichtbar für eine dauerhafte Qualitätssicherung führt Butcher auf:

• Ein Versionierungssystem für Quellcode
• Automatische Tests
• Test-Attrappen (Mocks, Stubs, Testdoubles)
• Automatische Builds
• Continous Integration
• Statische Codeanalyse

Je nach Programmiersprache variieren die dafür zu verwendenden Werkzeuge. Im Appendix gibt es eine Liste mit zahlreichen Tools für Java, C# und C++.

Fazit

Das Buch bündelt eine ganze Reihe von Best-Practices. Vieles hat man schon gehört und etliches kennt man eigentlich schon lange. Die Kombination zusammen mit guten Beispielen gibt einem aber einen Ruck es auch endlich umzusetzen. Zumal ein Grossteil der Tipps unabhängig von Team, Programmiersprache und Vorgehensmodell ist. Put it in Action!

Zum Buch

"Debug It!: Find, Repair, and Prevent Bugs in Your Code" von Paul Butcher, 2009 bei The Pragmatic Programmers, ISBN 978-1-9343-5628-9, 232 Seiten