Zur Navigation

Sie werden wachsen...

1 C)-(iLL@

Wenn man als Programmierer glaubt schon alles durchgemacht zu haben, ist diese Annahme == FALSE. Was kostet es uns oft Nerven, irgendwelche banal scheinenden Fehler zu debuggen... beispielsweise lehrte mich mein letztes Projekt:
1) Ein Programm funktioniert manchmal auch mit Endlosschleife, nur nicht so gut.
Tatsächlich hatte ich eine while-Schleife implementiert, in der der Zähler nicht raufgezählt wurde. Das brachte die seltsamsten Effekte, die Seite hörte in der Mitte auf zu laden, lud dann wieder doch...
2) Wenn man mit Javascript document.selection für die Positionierung von Text in einem Textfeld verwendet, sollte man sich möglichst daran erinnern, ob man nicht schon am Anfang des Projekts irgendwo eine Select-Formularkomponente eingefügt hat, welche "selection" heißt...
Der IE mag das nicht sonderlich - und wie aussagekräftig der JS-Debugger dieses Teils ist, wissen wir ja.
3) MySQL ist anders. Die Syntax UPDATE TABLE SET FIELD= 'text'||FIELD ergibt 0 oder 1.
Aber: MySQL ist gleich. Die Funktion CONCAT gibt es auch in JS, Delphi, Pascal, ...

Zusatz hierzu:
Lege immer ein Backup an, wenn Du ein Update über viele Datensätze machst, oder versuch es zuerst mit einem Datensatz, auch - nein - besonders wenn Du Dir sicher bist.
ich glaub das erklärt sich von selbst.
4) Nein, der Fehler liegt nicht im regulären Ausdruck, da kannst Du noch so viel rumbasteln. Es ist strtolower, das die Umlaute nicht kennt.
Auch diese halbe Stunde hätte ich mir sparen können.

Tja, was habe ich gelernt? Wenn debuggen der Vorgang ist, Fehler zu korrigieren, ist programmieren der Vorgang, Fehler einzubauen. Gute Programmierer bauen Fehler derart effizient ein, dass sie kaum bemerkt werden. Je komplizierter der Code, umso banaler der schlimmste Fehler.

11.07.2005 00:56

2 Jörg

Jo, grad bei einem größeren Projekt sollte man immer auf eine längere Korrekturphase gefasst sein :) - und diese wird wohl auch noch dadurch langwieriger, dass sie nicht immer ganz so viel Spaß macht wie die vorangegangene Aufbauphase. Aber manchmal gibt's schon recht eigenartige Bugs

11.07.2005 09:45

3 Sven

schlimm ists wenn man einen fehler nicht findet und alles schon 5 mal durchgeschaut hat, und am ende stellt man fest das es nur nen doofer langweiliger tippfehler war ^^

13.07.2005 09:21

4 C)-(iLL@

Heute habe ich gelernt was das allertollste ist.
Lass einen DAU auf dein Programm los, von dem Du glaubst, es sei bombensicher. Du wirst die tollsten Fehler entdecken.
Die derart unlogische und unbedarfte Bedienung durch ein solches User-Exemplar bringt jede Lücke zum Vorschein. Beispiel: Du sagst dem DAU, er darf mit dem CM keine Hochformat-Bilder hochladen, weil das nicht vorgesehen ist. Du baust eine Fehlermeldung am Anfang ein, testest es, denkst es abgeschlossen. Du änderst was am Programm, testest die neuen Sachen davon ausgehend, dass die alten noch funktionieren. Dann kommt DAU und macht genau das was Du gesagt hast er sollte es nicht tun und lädt Hochformat-Bilder hoch - TADA, deckt einen Select-Fehler auf.
Oder: Du sagst Dau, er solle nur 3 gewisse Seiten nicht löschen, weil Sie für die Funktion nötig sind. Was macht DAU 1 Stunde später? Genau, löscht eine der Seiten. Also... frisch ans Werk und das ganze unterbinden, neue Fehlermeldung... NB: Jetzt weiß ich endlich, warum man so viele Fehlermeldungen braucht.
Ich glaube ich gebe ein Inserat in die Zeitung und stelle mir einen DAU stundenweise zum Testen an. Als Programmierer wird man viel zu verbohrt auf logische Bedienung...

17.07.2005 23:07

5 Jörg

Als Programmierer wird man viel zu verbohrt auf logische Bedienung...

ja, und dann kommt noch hinzu, dass man selbst die eigene Software in- und auswendig und damit den richtigen Weg der Bedienung kennt - was anderes ist es, wenn man zum ersten Mal damit konfrontiert wird. Man muss damit rechnen, dass Anwender alles mögliche wie auch alles unmögliche ausprobieren :)

18.07.2005 08:41

6 C)-(iLL@

Man muss damit rechnen, dass Anwender alles mögliche wie auch alles unmögliche ausprobieren :)
Jup, das ist klar. Ich kann leider nicht jedesmal von einem ganzen Programm einen Branch-Test machen, wenn ich was ändere. Sollte man, ich weiß - die "Blackbox" - *lach*. Erkläre das mal jemand der Autoindustrie :) Die lassen auch ihre Käufer testen, um Modelle wieder einzuziehen - und deren Produkte sind etwas teurer... Wenn der Anwender einen Fehler findet kostet dies mich viel weniger Zeit als wenn ich ihn suchen muss ;)

18.07.2005 10:35

Nur Mitglieder können in diesem Forum Antworten schreiben.

Login | Registrieren