Wenn man als Coder den Fehler nicht findet...

[Gast dnyc]

Hallo,

bin fast verzweifelt. Habe jetzt 1 1/2 Stunden einen Fehler gesucht und ihn nicht gefunden und bin darüber so empört, dass ich mich hier mal mitteilen muss. Kennt ihr das? Fehler versucht einzugrenzen, alten Code wiederverwenden, Debuggen, Verzweifeln, merken, dass das Problem beim alten Stand auch schon da war ohne das es bemerkt wurde und dann schlussendlich das Problem anders lösen... Jetzt funktioniert es zwar, aber trotzdem ein Armutszeugnis.

Habt ihr das schon mal gehabt? Dass ihr einen Fehler auch nach Stunden nicht findet. Gerade bei großen Projekten kann das doch ein Ding der Unmöglichkeit sein, einen Fehler zu finden. Wenn es dann noch ein System ist, welches produktiv eingesetzt wird, dann gute Nacht. xD

Wäre interessant, eure Stories zu hören. :D

VG

[Kleinrechner]

Mach dir keinen Kopf, ist war nervig, aber ganz normal!

[KeeperOfCoffee]

Liegt es evlt. an deiner "Strategie".

Ich kenne das von früher. Jetzt arbeite ich alleine an einem größeren Projekt (2-3 Jahre schon eingeplant) und finde Fehler innerhalb von Minuten....wenn ich Mist mache, dann weiß ich auch warum

Bevor ich irgendwas implementiere mache ich mir eigentlich stets einige Minuten Gedanken zu möglichen Fehlerquellen (sowohl vom Anwender oder der Datenbank).

Als Entwickler ist man aber stehts etwas "blind", da man stets eine eigene Sichtweise verfolgt, wie das Produkt zu verwenden ist. Man kommt einfach oft nicht auf die teilweise schrägen Ideen der Anwender.

Nicht umsonst bekommen Praktikanten und auch Azubis (gerade in den ersten Wochen, wenn man die Anwendung kennen lernen soll) oft die Aufgabe das Programm zu testen und sich Fehler zu notieren bzw. was ihnen komisch vorkommt.

[Rabber]

1,5 Stunden empfinde ich ehrlich gesagt als nicht sonderlich viel. 

Klar, es hängt vom Programm ab, wie groß und komplex der Code ist, etc. pp.. Im Zweifel kann man bei der Fehlersuche jedoch problemlos 1+ Tage verbrauchen. Zumindest kenne ich das so und zwar nicht nur bei mir, sondern auch bei Kollegen, welche langjährige Erfahrung haben und fit in ihrer Materie sind.

Ich würde mir da keinen Kopf machen. Wichtig ist, dass Du die Fehler findest, behebst und das nicht regelmäßig x Tage braucht. Ob es nun 1 Stunde mehr oder weniger ist, sollte kein Maßstab sein. Qualität geht da vor Geschwindigkeit.

[Rienne]

Es kommt auch immer darauf an, welche IDE oder sonstige Plugins/Addons/Unterstützung man nutzt, und welche Hilfe diese bei der Fehlersuche bieten.
Ich muss mich zum Beispiel zurzeit in SAPUI5 einarbeiten. Dazu kann man entweder über eine Web IDE oder in Eclipse entwickeln. In keinen der beiden gibt es aktuell eine verwertbare Syntaxprüfung, so dass man gut und gerne mal Ewigkeiten sucht, warum die Anwendung, die eben noch fehlerfrei lief, jetzt auf einmal gar nichts mehr. Und am Ende stellt man dann fest, dass man in Zeile x bei Datei y ein Komma vergessen hat.

Es ist auch ganz normal, dass man bei der Entwicklung und den Tests gar nicht alles überprüfen kann, was beim Produktivbetrieb passieren könnte. Das liegt daran, dass man andere Daten nutzt, nicht die selbe Auslastung hat, gar nicht daran denkt, was der Anwender alles "falsch" machen könnte, ... .

Ich kenne es zu genüge, dass man oftmals mehrere Stunden und sogar mit mehreren Leuten vorm Debugger sitzt und das Coding Zeile für Zeile durchgeht und genau schaut welche Werte die verschiedensten Variablen annehmen, und man selbst dann oftmals nicht viel schlauer ist als vorher.

[JimTheLion]

Ich hab irgendwann diese Woche ein kleines Weg-Werf-Script für eine Datenmigration geschrieben, so Zeugs mit normalen Operationen die man jeden Tag braucht.

Hatte beim Absenden von der Abfrage aber ein falsches Array für die Parameter reingeworfen und eine Stunde lang gesucht, warum er denn die Parameter nicht zuordnen kann, weils n Schusseligkeitsfehler von mir war konnte auch nichtmal der Debugger helfen.

Passiert.

[Rabber]

Mit der IDE hast Du in jedem Fall Recht. In der C# Welt z.B. ist es ein Unterschied wie Tag und Nacht, ob man Tools wie den ReSharper sein eigen nennt oder alles mit Visual Studio selbst machen muss. Und das, obwohl VS bereits eine Menge an Bord hat. Nichtsdestotrotz können gute Addons dort problemlos zig Stunden Zeitersparnis bedeuten.

Auch der Hinweis auf die realen Bedingungen. z. B. bei asynchroner Programmierung gibt es dort die wildesten Fälle von Deadlocks, Race Conditions und Co.. Da kann es bereits Stunden mit x Beteiligten dauern, bis man die überhaupt zuverlässig nachstellen kann. Von "Fehler gefunden" oder "behoben" haben wir dann noch lange nicht gesprochen.

[KeeperOfCoffee]

Ich mag auch Addons wie ReSharper und CodeRush. Ich denke aber, dass sie in Zukunft weniger genutzt werden, da das VS  Team immer mehr Funktionen dieser Tools integriert. Wenn es darum geht Fehler nachzuvollziehen finde ich Logging aber immer noch am hilfreichsten.

[arlegermi]

Ich halte vernünftige Debug-Fähigkeiten ja für einen der wichtigsten Skills, die ein Entwickler überhaupt nur haben kann. Jeder macht Fehler - deshalb ist's wichtig, diese so schnell wie möglich zu finden und beheben.

Aber na klar sitzt man manchmal wie der Ochs vorm Berg und sieht nicht, dass man gerade die falsche Variable auf null prüft. Oder dass man gar nicht den Code ausführt, auf den man schon 'ne Stunde starrt. Hatte ich neulich: Kunde meldet Fehler, dass irgendein Parameter nicht ausgewertet wird. Gucke bei uns in den Code - kann gar nicht sein (Details hier egal), völlig unmöglich. Dann fang' ich an, zu überlegen, ob das im Zuge von Multithreading doch passieren kann, ob es irgendeinen .NET-Schmu gibt, der zu "unmöglichem" Verhalten führt, etc etc.

Bis ich dann irgendwann mal auf die Idee gekommen bin, beim Kunden nochmal nachzubohren, ob der auch wirklich den aktuellsten Patch einsetzt. Ne, natürlich nicht. 

[Ulfmann]

Hi,

ich weiß nicht so ganz, ob die ganzen Verweise auf IDEs und Plugins hier so hilfreich sind oder ob es nicht viel mehr um generelles Vorgehen und Erwartungshaltung geht. Es macht sicher total Sinn, sich sehr gut mit seinem Editor / IDE auszukennen und soviel wie möglich rauszuholen, aber mir sind die Ratschläge alle etwas zu speziell. Mir persönlich hätten Tips für Visual Studio oder C# herzlich wenig genützt, da ich mit beidem nicht arbeite. Aber nix für ungut!

Zum Thema: Wie sieht es denn mit eurer Testabdeckung aus? Lässt dich das Problem durch einen Test reproduzieren? Gerade in einer großen Codebase ist das (für mein Verständnis) unerlässlich. Ansonsten: wenn ich das Gefühl habe, dass mir ein Bug lachend zuwinkt und ich nur zu blöd bin, schnappe ich mir jemanden und erkläre ihm das Problem. In 90% der Fälle fällt mir beim Reden / Demonstrieren die Lösung auf.

[Maniska]

vor 42 Minuten schrieb Ulfmann:

In 90% der Fälle fällt mir beim Reden / Demonstrieren die Lösung auf.

Oder der andere guckt kurz und zeigt auf den Fehler den man aus Betriebsblindheit einfach nicht sieht...

[Whiz-zarD]

Fehler entstehen immer und je nach Komplexität sind 1,5 Stunden danach zu suchen jetzt nicht wirklich viel. Gerade wenn der Fehler in Laborbedingungen nicht auftritt und man die Daten vom Kunden benötigt und erst mal den Datensatz unter den Millionen finden muss, der für den Fehler verantwortlich ist. Auch nett sind Speicherprobleme, die mal sporadisch auftreten. Da sitzt man gerne mal ein paar Tage, um heraufzufinden, was eigentlich los sei.

Nach meiner Erfahrung entstehen aber die meisten Fehler häufig durch unstrukturierten Code. Code, der zu viel auf einmal macht und Seiteneffekte produziert oder es wird irgendwo Null zurückgegeben, obwohl Null keinen Sinn macht, etc. Gerade bei objektorientierten Sprachen ist es aus meiner Sicht wichtig, die SOLID-Prinzipien verinnerlicht zu haben und sie auch einsetzt. Es klappt nicht immer aber wenn man immer wieder versucht, sich daran zu halten, dann wird der Code schon übersichtlicher. 

vor 33 Minuten schrieb Ulfmann:

Zum Thema: Wie sieht es denn mit eurer Testabdeckung aus? Lässt dich das Problem durch einen Test reproduzieren? Gerade in einer großen Codebase ist das (für mein Verständnis) unerlässlich.

Dafür muss aber der Code aber erstmal testbar sein. Wenn ich das richtig verstehe, ist @dnyc ein Quereinsteiger und ich weiß nicht, was er schon über Unittests weiß. Das ist leider immer noch so ein Kapitel, die Quereinsteiger/Anfänger erst so richtig mitbekommen, wenn es eigentlich schon zu spät ist, da man solche Themen in der Fachliteratur gerne ausklammert.

[KeeperOfCoffee]

Desweiteren werden Unit-Tests von vielen kleinen und mittelständischen Unternehmen abgelehnt aus Zeit/Kostengründen

[monolith]

vor 18 Minuten schrieb Whiz-zarD:

Dafür muss aber der Code aber erstmal testbar sein. Wenn ich das richtig verstehe, ist @dnyc ein Quereinsteiger und ich weiß nicht, was er schon über Unittests weiß. Das ist leider immer noch so ein Kapitel, die (...)/Anfänger erst so richtig mitbekommen, wenn es eigentlich schon zu spät ist, da man solche Themen in der Fachliteratur gerne ausklammert.

Oder sie haben halt mal davon gehört, aber... na sie haben halt mal davon gehört. Und dabei bleibt es dann auch erst mal.

vor 14 Minuten schrieb KeeperOfCoffee:

Desweiteren werden Unit-Tests von vielen kleinen und mittelständischen Unternehmen abgelehnt aus Zeit/Kostengründen

Ja. Bei Tests muss man zwar immer eine sinnvolle Balance finden (Paretoprinzip?). Aber 0% code coverage (oder irgend eine beliebige andere Metrik) ist sicher keine sinnvolle Balance

Bearbeitet 7. Dezember 2018 von monolith

[Ulfmann]

Stimmt. War hier bei uns früher auch so und ich hab mich jedes Mal tierisch darüber aufgeregt, wenn es denn heißt "Oh, diesen Bug hat im Code Review niemand entdeckt und auch beim click-testing ist das nicht aufgefallen. Jetzt mussten wir das zu dritt einen Tag lang fixen." (+ Review und Deploy).

Was jetzt mehr Zeit bzw. Geld frisst... naja. Aber es stimmt natürlich, wenn die Datenstruktur zu komplex ist und es bisher nicht einen Unit- oder Integrationtest gibt, hätte ich wohl auch keinen Bock, damit anzufangen. Das würde ich jetzt gar nicht mal an Quereinsteiger/Anfänger festmachen. Aber dann geht natürlich richtig viel Zeit drauf.

[thereisnospace]

vor 15 Minuten schrieb KeeperOfCoffee:

Desweiteren werden Unit-Tests von vielen kleinen und mittelständischen Unternehmen abgelehnt aus Zeit/Kostengründen

Unit Tests aus Kostengründen abzulehnen ist einfach nur falsch. Das zeugt von Unwissenheit über die Auswirkungen von spät erkannten Softwarefehlern.

Unit Tests sollten grundsätzlich immer durchgeführt werden. Auch sollte eine unabhängige dritte Partei (mit dritte Partei meine ich unabhängig vom Entwicklerteam) frühzeitig den Entwicklungszyklus begleiten, beraten und abschließend auch testen. In welcher Form ist dann immer vom Budget abhängig. Generell sollten aber immer mindestens Blackbox Tests auf Systemtestebene durchgeführt werden, um schwerwiegende Fehler zu vermeiden. Ob diese dann durch exploratives Testen oder mithilfe von Testanalyse und fundierten Methoden wie Testfallerstellung mithilfe der Grenzwertanalyse oder/und Äquivalenzklassenbildung durchgeführt werden, ist dann wirklich abhängig wie viel Geld und Zeit zur Verfügung steht.

Aber wir kommen vom Thema ab.

[Rienne]

Also manchmal lobe ich mir ja das Vorgehen von SAP was solche Dinge angeht, auch wenn ich sonst immer wieder und immer gerne über SAP und ABAP schimpfe. Dort gibt es z.B. die strikte Trennung zwischen Entwicklungs-, Test-/QS-System und Produktivsystem. Und im Produktivsystem darf auch nicht einfach mal so etwas umgeschrieben werden. Auch hat SAP einen sehr mächtigen und einen der umfangreichsten Debugger, in dem man auch zu belieben Punkten abspringen kann und auch direkt jedes Coding, was von SAP selber kommt, sehen und überprüfen kann. Unit-Tests sind in SAP auch problemlos durchzuführen.

[KeeperOfCoffee]

vor 16 Minuten schrieb Gottlike:

Unit Tests aus Kostengründen abzulehnen ist einfach nur falsch. Das zeugt von Unwissenheit über die Auswirkungen von spät erkannten Softwarefehlern.

Was du nicht sagst, aber versuche das mal sturren Leuten aus der GL oder Leitern von Abteilungen zu erklären die "seit Jahrzehnten im Geschäft sind und sowas ja noch nie gebraucht wurde"

[thereisnospace]

vor 2 Minuten schrieb KeeperOfCoffee:

Was du nicht sagst, aber versuche das mal sturren Leuten aus der GL oder Leitern von Abteilungen zu erklären die "seit Jahrzehnten im Geschäft sind und sowas ja noch nie gebraucht wurde"

Dan muss man den Leuten mal solche Zahlen vor die Nase halten ^^ Aber ja, ich kenne das auch aus meinem Umfeld. Zum Glück sind wir mittlerweile sehr etabliert und akzeptiert im Unternehmen, sodass man sich über unsere Arbeit freut und die auch gerne bezahlt.

[MapReduce]

Ich saß einmal ganze 1,5 Wochen an ein Unity3D Projekt.... Ich wollte einen WebRequest über selbst signierte SSL Zertfikate machen...  

[Enno]

Versuch mal Fehler in Kassensystemen zu finden.

Ja ich kann die Grundsätzlichen Fehler finden. Aber keiner kann simulieren was passiert wenn 300 Kassen an einem Standort gleichzeitig Arbeiten in der Hochsaison zu Weihnachten und das Haus proppen voll ist.

Da kommen Fehler hoch bei denen Staunt sogar der Hersteller der Software.

Oder es kommen dann Fehler hoch das die ZVT unregelmäßig abschmieren. Bis mal einer drauf kommt das die Interneteitung zu klein ist. Und im Hochlastbetrieb die Antwortzeiten des Dienstleisters zu lang werden und damit die ZVT mit Fehlern abbrechen. Tja im Test mit 1-2 Terminals wird sowas IMMER funktionieren. Weil eigentlich wars nen Timeout aber durch nen Tipfehler in der Fehlerbehandlung brach er dann mit ner total kryptischen Meldung ab.

[Minerva/8]

Wahre Geschichte:

Unsere Mobile APP schickt keine Daten mehr an Kundenserver.

Erste Frage unsererseits an den Systemadministrator des Kundens: Blockt die Firewall was oder hat sich sonst was geändert?

Antwort: Nein alles ok.

Nach einer Woche verzweifelter Fehlersuche haben wir dann das Zepter in die Hand genommen und uns mal per Fernwartung selbst beim Kunde umgeschaut.

Ergebnis: Im Router-Log nur rote fette Fehlermeldungen. Was war das Problem? Die Firewall hat "unseren" Port geblockt.

Manche Probleme kann man also gar nicht alleine lösen

Bearbeitet 7. Dezember 2018 von Minerva/8

[Gast dnyc]

Wow, danke für die große Resonanz. :) Sehr interessant eure Beiträge!

Wenn ich schätzen müsste, dann hab ich bisher von 100% müßigen Fehlern 90% gefunden und den Rest dann entweder anders gelöst oder es nochmal neu implementiert und dann hat es plötzlich geklappt. Wie ist das so bei euch? Habt ihr schon mal einen Bug "behoben" indem ihr einfach eine andere Lösung entwickelt habt? Oder schafft ihr es, sämtliche Fehler immer 100% ohne Umwege zu lösen? Zum Beispiel habe ich einen Overlay programmiert, mit dem man Replies in einem Thread posten kann, aber der Overlay, der zuletzt inkludiert wird seltsamerweise nicht angezeigt. Also habe ich einfach die schon vorhandene Textbox umfunktioniert, dass man nun auch Replies zu Posts machen kann. Ist dann halt nur ein Umweg.

@Whiz-zarDJa, also ich bin noch kein Quereinsteiger, habe aber vor eine Umschulung zum FiAe zu machen. Und ein bisschen habe ich schon Angst vor solchen Situationen. Dem anders als im privaten muss man ja immer zu einer Lösung gelangen. Etwas nicht zu schaffen ist nicht drinne, alles muss perfekt sein.

[arlegermi]

vor 47 Minuten schrieb dnyc:

Oder schafft ihr es, sämtliche Fehler immer 100% ohne Umwege zu lösen?

?

[KeeperOfCoffee]

vor einer Stunde schrieb dnyc:

sämtliche Fehler immer 100% ohne Umwege zu lösen

Ich bleibe dabei: Die Kunst liegt darin vor einer Implementierung möglicher Fehlerquellen zu finden bzw. problematische Szenarien.