10 Antworten auf die Frage: Welcher Programmierfehler hat die schlimmsten Auswirkungen? - JAXenter
Aus dem Entwickler-Nähkästchen: Teil 4

10 Antworten auf die Frage: Welcher Programmierfehler hat die schlimmsten Auswirkungen?

Kaum ein Phänomen gehört mehr zu den ständigen Begleitern eines Entwicklers im Programmieralltag als der leidige Fehler im Programm. Irren ist menschlich – doch haben manche Irrtümer gravierendere Auswirkungen als andere. Im vierten Teil unserer Serie „Aus dem Entwicklernähkästchen“ thematisieren wir deshalb die Erfahrungen der Entwickler mit dem Fehlerteufel und fragen:

Welcher Programmierfehler hat deiner Erfahrung nach die schlimmsten Auswirkungen?

Erst entwickeln – Testen und Dokumentieren machen wir später. Jeder entwickelte Code muss getestet und bestmöglich dokumentiert werden. Viele Entwickler haben leider versäumt, sich dieses Mantra rechtzeitig zu verinnerlichen, und das obwohl die Vorteile klar auf der Hand liegen. Wer jemals mit Legacy-Anwendungen arbeiten musste, die wenig bis gar nicht getestet sind, weiß JUnit umso mehr zu schätzen. Martin Dilger, Pentasys AG

Mangelnde Modularisierung oder „Jeder kennt jeden“. Solche Fehler
führen sehr schnell zu unwartbarem Code und lassen sich oft nur mit
sehr großem Aufwand korrigieren. Jonas Helming, TU München

Endlosschleifen und rekursive Aufrufe, die nicht enden wollen.
Markus Demolsky, Soreco Group AG

Meiner Erfahrung nach kommt es nicht auf die Art des Programmierfehlers an, sondern auf den Zeitpunkt, wann ein Fehler entdeckt wird bzw. zu welchem Zeitpunkt in der Entwicklung ein Fehler eingebaut wurde.
Je früher ein Fehler eingebaut bzw. je später er entdeckt wird, desto fataler wird es. Jens Hildebrand, SYSTEMA GmbH

Programmierfehler: Code Duplication. Schlimmer: Schlechtes Design oder Architektur. Andreas Leidig, andrena objects ag

Weniger ein Programmierfehler als das Paradigma, Technik und Fachlichkeit zu trennen. Der Erfolg eines Projekts hängt nicht unwesentlich von der Fähigkeit der Entwickler ab, die fachlichen Anforderungen zu erfassen und zu bewerten. Den Ansatz, dem Programmierer ein Modell zur Verfügung zu stellen, das er „mal so“ herunterprogrammieren kann, halte ich in einem normalen Enterprise-Projekt für kaum realisierbar. Uwe Sauerbrei, emCON www.emcon-partner.de

Die gute alte NullPointerException! David Linsin, Synyx GmbH & Co. KG

Generell glaube ich, dass ein Fehler, der früher gemacht wird und unentdeckt bleibt, oft gravierendere Auswirkungen hat als ein später eingebauter Fehler. Davon abgesehen halte ich Fehler im Zuschnitt der Applikation, also sozusagen Architekturfehler, für sehr gravierend, da diese Fehler sich durch den gesamten Code hindurch ziehen und im schlimmsten Fall das Implementieren jedes neuen Features langwieriger und umständlicher, und damit wiederum fehleranfälliger machen. Nicole Rauch, andrena objects ag

try {…} catch(Excpection e} {e.printStackTrace();} Fehlende Ausrichtung auf das spätere Operating. Fehler passieren, das ist nicht schlimm! Aber ein Fremder sollte möglichst schnell wissen, was passiert ist, in welchem Kontext und was man u.U. nun tun sollte! Und man sollte immer daran denken: Die können und wollen alle nicht Programmieren! Holger Prang, www.vielsichtig.de

„Copy & Paste“ und dessen kleiner Bruder „Copy, Paste & Modify“
anstatt der Einführung einheitlicher und wiederverwendbarer Komponenten bieten nicht nur eine erhöhte Fehlerduplikationsrate und ein Mehr an Wartungskosten – auch die Abhängigkeiten zwischen den verschiedenen Komponenten werden reduziert. Toll! Enrico Schnepel, Unister GmbH

Und welcher Programmierfehler hat deiner Erfahrung nach die schlimmsten Auswirkungen?

Kommentare
  1. Martin Wildam2013-11-26 17:56:48

    Ich halte mich da an ein Zitat aus dem Film "Alarmstufe Rot 2": "Der Anfang einer jeden Katastrophe ist eine verdammte Vermutung."

    Und ich meine damit die Prämissen unter denen Programmcode geschrieben wird. Da gibt es viele Prämissen, von denen nichts in irgendwelchen Kommentaren steht, weil es für den Originalprogrammierer "eh klar" war oder es ihm/ihr einfach nicht bewußt war/ist.

    Und selbst erlebe ich das natürlich auch immer und immer wieder, daß ich selbst implizit Annahmen treffe. Das geht von einfachen Variableninhalten- oder Tabelleninhalten, die nicht ausreichend geprüft werden bis hin zu benötigten Software-Komponenten.

    Solche falschen Prämissen können sogar zur Wahl der ungeeigneten Technologie führen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.