Fehler beim Programmieren
Die folgende Liste geht hauptsächlich auf den Teil meiner Erfahrungen zurück, den ich Ad-Hoc-Programmierung nenne. Während bei „richtigen Projekten” in der Regel angemessene Methodik und definierte Prozesse zum Einsatz kommen, wird in beim Scripting auf Zuruf, bei kurzfristigen Projekten und bei Anwendungen für den IT-Hausgebrauch oft recht kopflos dahergehackt. Das soll aber nicht heißen, dass die folgenden Fehler nicht auch bei großen IT-Projekten bzw. deren Teilaufgaben gemacht werden.
Error 0x00: Frühstart
Es ist unfassbar, wie oft die erste Zeile Code entsteht, bevor die Aufgabe definiert und die Vorgehensweise festgelegt ist. Es heißt dann gerne, das sei „ja jetzt kein großartiges Projekt” oder „erstmal nur ein PoC”. So begründet bleibt dann jegliche Methodik außen vor.
Empfehlung an hartnäckige Ad-Hoc-Hacker:
Selbst wenn die gewählte Methodik Wörter wie rapid
oder agile im Namen hat, ist das Drauflos-Coden der Schritt
ins Verderben. Selbst wenn der erwartete Arbeitsaufwand gering scheint,
sollte es vor dem Entstehen der ersten Zeile Code immer wenigstens eine
Seite Text und eine Handskizze geben, in denen Anforderungen,
(angestrebte) Lösung, Design, Ressourcen und ein grober Zeitplan
definiert sind.
Error 0x01: „Selbsterklärender Code”
Die Idee, dass man dem Code ansieht, was er tut, ist bestenfalls eine Notlüge und schlimmstenfalls eine Philosophie des Grauens. Auch wenn es sich nur um ein kleines Skript handelt, sollten z.B. Administratoren gleich erkennen können, was es tut und welche anderen Skripte und Cronjobs hier mitspielen. Bei der Fehlersuche unter Zeitdruck macht Reverse-Engineering keinen Spaß und wenn man die Programmiersprache gar nicht kennt geht das gar nicht. Wer, jenseits von solchen Notfällen, z.B. eine Java-Anwendung erweitern soll, wird ohne vernünftige Dokumentation der verwendeten Klassen im Spaghetti enden - oft sogar dann noch, wenn er den bestehenden Code selber geschrieben hat.
Error 0x02: Zu spätes Dokumentieren
„Die Dokumentation machen wir, wenn alles funktioniert.”
Schon mal probiert, die Dokumentation jeder Klasse, Methode oder
sonstiger Code-Abschnitte schon
vor dem eigentlichen Code zu erstellen? So weiß man immer genau,
was man tun wollte. Irgendwie wirken Sachen
schon zu 40% erledigt, wenn sie mal aufgeschrieben sind.
Und beim Schreiben fallen einem auch schon mal Unzulänglichkeiten
oder Widersprüche im Ansatz auf. Wenn man dann noch
Werkzeuge wie Javadoc, RDoc u.s.w. bemüht, macht das
Wiederverwenden richtig Spaß.
Fazit: Man kann durchaus erst denken, dann beschreiben
und dann programmieren.
Error 0x03: Zu spätes Testen
Funktionen und Methoden testet man, wenn man sie schreibt.
Und wenn das Modul oder die Klasse fertig ist, darf auch diese
systematisch getestet werden. Unit-Testing ist eine gute
Sucht. Also ich kann von Ausgaben wie der folgenden
gar nicht genug kriegen:
0 failures, 0 errors, 0 skips
Error 0x04: Inkonsistenz aus Pragmatismus
Als Programmierer sollte man seinen Pragmatismus
nicht an der allgemeinen Definition, sondern eher an
Pragmatischen Programmierer wie Thomas & Hunt
ausrichten. Die
Broken‑Windows‑Theorie
gilt für Software:
Wird ein konsistentes Design an einer einzigen Stelle
durch eine Sonderlösung oder einen „Hack”
missachtet, dann verkommt die ganze Software auf Kurz oder Lang.
Was wie die „ergebnisorientierte Finisher-Lösung”
aussieht, ist oft der Anfang vom Ende einer wartbaren
Software.
Fazit: Immer sauber bleiben!
Error 0x05: Verschmähen von Pausen
Auch wenn es in der Begeisterung schwer fällt:
Pausen macht man am besten, bevor man müde ist. Wenn man dann
noch den Schreibtisch verlässt, machen die Pausen sich bezahlt.
Pausen bringen viele gute Ideen und manchmal sogar die Erkenntnis,
dass man auf dem falschen Weg ist.
Übrigens: Ein Blick aus dem Fenster gut für die Augen.
Error 0x06: Verzagt Problemlösungen suchen
Mehrfach bis nach Mitternacht im Büro gesessen, seit 13:00 nichts
mehr gegessen und kaum getrunken, ohne das vorliegende Problem
auch nur ein Stück weit zu lösen.
Die Lösung kam dann auf der Heimfahrt bei lauter Led-Zepelin-Musik und war am
nächsten Tag in fünf Minuten implementiert.
Fazit: Manchmal muss man es einfach „für heute gut sein” lassen.