Abo
  1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Wunschkennzeichen: Warum "Null…

Fremdscham

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Fremdscham

    Autor: anion21 14.08.19 - 23:05

    Ich als Entwickler schäme mich für alle Berufsgenossen, die IT-System so schlampig programmieren, dass Fehler dieser Art passieren.

  2. Re: Fremdscham

    Autor: michael_ 15.08.19 - 08:59

    shame shame shame shame shame shame

  3. Re: Fremdscham

    Autor: 0110101111010001 15.08.19 - 09:03

    +1

    Gibt leider genügend Leute, die so Programmieren.

  4. Re: Fremdscham

    Autor: Megusta 15.08.19 - 09:13

    eher Schadensfreunde :)

  5. Re: Fremdscham

    Autor: gentux 15.08.19 - 11:29

    anion21 schrieb:
    --------------------------------------------------------------------------------
    > Ich als Entwickler schäme mich für alle Berufsgenossen, die IT-System so
    > schlampig programmieren, dass Fehler dieser Art passieren.

    Da schämst du dich ziemlich wahrscheinlich für die Falschen. Ich arbeite selbst in einer Firma, die Software für Behörden erstellt und ich kann dir sagen, dass die Auftraggeber oft keinen Plan haben und sagen dir zum Beispiel, dass du einen Integer erwarten kannst und wundern sich, dass aus "0 000 0058" dann "58" wird und fragen warum die Nullen vorher plötzlich weg sind, Integer seien schliesslich numerische Werte. Dann baust du irgendwelche Validationen ein und zwei Wochen später wird der Override für eben diese verlangt und dann auch intensiv benutzt.

    Wir haben auch schon mal (versehentlich) den Keyboard-Shortcut für den Override mit einer anderen Funktion belegt. Ging eine beängstigend kurze Zeit, bis das von den Nutzern bemerkt und gemeldet wurde!

    Vielleicht müsste man die Projektmanager auf Kundenseite einfach vor Projektbeginn einfach mal in einen speziellen Grundlagenkurs schicken, wo sie in kurzer Zeit lernen, wie Daten in der IT verarbeitet werden, das würde Zeit, Nerven und Geld sparen.

  6. Re: Fremdscham

    Autor: spYro 15.08.19 - 12:18

    Stimme dem zu.
    Hier geht es ja nicht einmal um direkte Code-Injection mit Anführungszeichen usw, hier geht es darum, dass das Kennzeichen "NULL" als plain NULL-value in der DB gespeichert wurde.
    Ein einfaches ".toString()" hätte hier schon gereicht (auch wenn das natürlich keine cleane Lösung ist).
    Das hat noch nicht einmal etwas mit moderner Programmierung zu tun, so etwas war auch schon vor 20 Jahren "Stand der Dinge".

  7. Re: Fremdscham

    Autor: spYro 15.08.19 - 12:24

    Kenne natürlich nicht alle Details eures Szenarios, aber ein Kunde (der also nicht selbst Software Entwickelt) sollte immer nur nicht-technische Anforderungen stellen.
    Also z.B. "Werte wie 123, 456 oder 001 sollen gespeichert und abegrufen werden können".
    Als Software-Entwickler merkt man dann, dass die Zahlen keine Mathematische darstellung (aka. es werden keine mathematischen Operationen mit ihnen durchgeführt) sind und außerdem führende Nullen vorhanden sind. Also entscheidet man sich (ersteinmal) für string/text/varchar.

    Firmen, die "blind" technische Anforderungen des Kunden umsetzen ohne dass der Kunde Expertise in diesem Feld vorweisen kann, würde ich mit Vorsicht genießen.

  8. Nicht ganz korrekt

    Autor: demon driver 15.08.19 - 15:19

    anion21 schrieb:
    --------------------------------------------------------------------------------
    > Ich als Entwickler schäme mich für alle Berufsgenossen, die IT-System so
    > schlampig programmieren, dass Fehler dieser Art passieren.

    Selbst dem erfahrensten Entwickler können nochmal dumme Anfängerfehler passieren.

    Zum Beispiel könnte beim ersten Entwurf einer Maske zum schnellen Testen ein Feld eingebaut worden sein, zunächst ohne beim Auslesen auf null zu testen, das will man aber natürlich sofort nachholen, wenn's soweit ok aussieht und die Datenübergabe funktioniert – und dann vergisst man genau das.

    Wenn der Code dann aber so den Weg bis in die Produktion geht, dann liegt das daran, das an der Stelle nicht wirklich getestet wurde. Und wenn nicht wirklich getestet wird, dann gibt es ein grundsätzliches Problem, das aber eher in der Organisation liegt als in der Entwicklung.

  9. Re: Fremdscham

    Autor: Plasma 15.08.19 - 15:42

    gentux schrieb:
    --------------------------------------------------------------------------------
    > Vielleicht müsste man die Projektmanager auf Kundenseite einfach vor
    > Projektbeginn einfach mal in einen speziellen Grundlagenkurs schicken, wo
    > sie in kurzer Zeit lernen, wie Daten in der IT verarbeitet werden, das
    > würde Zeit, Nerven und Geld sparen.

    Dann hast du deinen Beruf falsch verstanden. Nicht der Projektmanager muss lernen wie ein Computer Daten verarbeitet, das braucht den nicht zu interessieren. Die IT muss lernen wie die reale Welt, die Domäne für die eine Software geschrieben wird, Daten verarbeitet und wie sie diese bestmöglich abbilden kann.

    Da aber leider immernoch viel zu viele Informatiker und andere Leute die mal Programmieren gelernt haben meinen, sich an dieser "mäh, die da sind schuld!"-Haltung aus den frühen 90ern festklammern zu müssen, werden noch viele Jahre ins Land gehen bis diese ständigen und ermüdenden Grabenkämpfe endlich vorüber sind.

  10. Re: Fremdscham

    Autor: demon driver 15.08.19 - 16:13

    Plasma schrieb:
    --------------------------------------------------------------------------------
    > gentux schrieb:
    > ---------------------------------------------------------------------------
    > > Vielleicht müsste man die Projektmanager auf Kundenseite einfach vor
    > > Projektbeginn einfach mal in einen speziellen Grundlagenkurs schicken, wo
    > > sie in kurzer Zeit lernen, wie Daten in der IT verarbeitet werden, das
    > > würde Zeit, Nerven und Geld sparen.
    >
    > Dann hast du deinen Beruf falsch verstanden. Nicht der Projektmanager muss
    > lernen wie ein Computer Daten verarbeitet, das braucht den nicht zu
    > interessieren. Die IT muss lernen wie die reale Welt, die Domäne für die
    > eine Software geschrieben wird, Daten verarbeitet und wie sie diese
    > bestmöglich abbilden kann.
    >
    > Da aber leider immernoch viel zu viele Informatiker und andere Leute die
    > mal Programmieren gelernt haben meinen, sich an dieser "mäh, die da sind
    > schuld!"-Haltung aus den frühen 90ern festklammern zu müssen, werden noch
    > viele Jahre ins Land gehen bis diese ständigen und ermüdenden Grabenkämpfe
    > endlich vorüber sind.

    Hier hast du aber den Sachverhalt nicht verstanden. Es ging darum, dass die IT Projektvorgaben von Laien bekommen hat, die fälschlich glaubten, ausreichende IT-Kompetenzen zu haben, um der IT technische Details vorgeben zu können, was dann halt zu falschen Vorgaben führte.

    Und da gibt es dann genau zwei Optionen – entweder die Auftraggeber verzichten auf technische Vorgaben, oder aber sie eignen sich den nötigen Sachverstand an bzw. nehmen sich Fachleute dazu.

  11. Re: Fremdscham

    Autor: eidolon 15.08.19 - 18:00

    Plasma schrieb:
    --------------------------------------------------------------------------------
    > Dann hast du deinen Beruf falsch verstanden. Nicht der Projektmanager muss
    > lernen wie ein Computer Daten verarbeitet, das braucht den nicht zu
    > interessieren. Die IT muss lernen wie die reale Welt, die Domäne für die
    > eine Software geschrieben wird, Daten verarbeitet und wie sie diese
    > bestmöglich abbilden kann.

    Und was bringt das, wenn die IT das weiß, aber vom Auftraggeber/Projektleiter Vorgaben bekommt, wie es umzusetzen ist?

  12. Re: Nicht ganz korrekt

    Autor: ibsi 15.08.19 - 18:01

    demon driver schrieb:
    --------------------------------------------------------------------------------
    > Wenn der Code dann aber so den Weg bis in die Produktion geht, dann liegt
    > das daran, das an der Stelle nicht wirklich getestet wurde. Und wenn nicht
    > wirklich getestet wird, dann gibt es ein grundsätzliches Problem, das aber
    > eher in der Organisation liegt als in der Entwicklung.
    Richtig. Und warum? Weil wenn man schon wenig Geld für gute Entwickler ausgeben möchte. Da kann man doch nicht noch Tester bezahlen. So was von unnötig ;)

  13. Re: Fremdscham

    Autor: ibsi 15.08.19 - 18:03

    Schritt 1:
    Auf das Problem hinweisen

    Schritt 2:
    Wenn das Problem akzeptiert wird, alles super.
    Wenn das Problem nicht akzeptiert wird, und es heißt: SO und nicht anders...
    dann kannst Du:
    * Es ignorieren (sehen tut es eh keiner, Hauptsache es läuft)
    * Kündigen
    * Sich eine Schriftliche Bestätigung holen und es dann genauso umsetzen wie gewünscht

    Schritt 3:
    Mit den Schultern zucken und sich denken *ist nicht meine Kohle*

  14. Re: Nicht ganz korrekt

    Autor: demon driver 15.08.19 - 19:34

    ibsi schrieb:
    --------------------------------------------------------------------------------
    > demon driver schrieb:
    > ---------------------------------------------------------------------------
    > > Wenn der Code dann aber so den Weg bis in die Produktion geht, dann liegt
    > > das daran, das an der Stelle nicht wirklich getestet wurde. Und wenn nicht
    > > wirklich getestet wird, dann gibt es ein grundsätzliches Problem, das aber
    > > eher in der Organisation liegt als in der Entwicklung.
    > Richtig. Und warum? Weil wenn man schon wenig Geld für gute Entwickler
    > ausgeben möchte. Da kann man doch nicht noch Tester bezahlen. So was von
    > unnötig ;)

    Genau! :-D

  15. Re: Fremdscham

    Autor: gentux 16.08.19 - 10:10

    spYro schrieb:
    --------------------------------------------------------------------------------
    > Kenne natürlich nicht alle Details eures Szenarios, aber ein Kunde (der
    > also nicht selbst Software Entwickelt) sollte immer nur nicht-technische
    > Anforderungen stellen.

    Das ist nicht so leicht, weil es mehr als eine Software und mehr als einen Lieferanten gibt. Ein Kunde muss also vermitteln. Wir kennen die anderen Lieferanten nicht und können auch unmöglich direkt mit denen kommunizieren um eine geeignete Schnittstelle zu erarbeiten und müssen uns auf den Kunden verlassen, dass seine Schnittstelle auch funktioniert, was es meistens auch tut, aber dann kommt ein Edge-Case (wie eine unbekannte aber erforderliche Nummer, die aber diesmal eben nicht der Validierungsregel entspricht) und dann werden kritische Bugs gemeldet, die vermeidbar gewesen wären.

  16. Re: Fremdscham

    Autor: gentux 16.08.19 - 10:24

    Plasma schrieb:
    --------------------------------------------------------------------------------
    > Dann hast du deinen Beruf falsch verstanden. Nicht der Projektmanager muss
    > lernen wie ein Computer Daten verarbeitet, das braucht den nicht zu
    > interessieren. Die IT muss lernen wie die reale Welt, die Domäne für die
    > eine Software geschrieben wird, Daten verarbeitet und wie sie diese
    > bestmöglich abbilden kann.

    Ja, das geht wunderbar, solange du der einzige Betrieb bist, der an diesen Kunden Software liefert. Sobald du Schnittstellen zu Software hast, von dem du keinen blassen Schimmer hast und auch noch nie in natura gesehen hast, musst du dich an Spezifikationen der Schnittstelle halten, egal wie sinnhaftig oder nicht sie sind. Ansonsten bist du nämlich verantwortlich, wenn du da (vernünftigerweise) was Besseres erarbeitet hast und das auf der anderen Seite nicht korrekt funktioniert und musst im schlimmsten Fall Entschädigung zahlen. Wenn der Kunde eines kann, dann die Spezifikation mit der Realität vergleichen.

    > Da aber leider immernoch viel zu viele Informatiker und andere Leute die
    > mal Programmieren gelernt haben meinen, sich an dieser "mäh, die da sind
    > schuld!"-Haltung aus den frühen 90ern festklammern zu müssen, werden noch
    > viele Jahre ins Land gehen bis diese ständigen und ermüdenden Grabenkämpfe
    > endlich vorüber sind.

    Ich denke die stammen einfach von erfahrenen Informatikern die wissen, dass es in der Praxis ganz anders ist, als man es in der Theorie mal gelernt hat. Daran haben nicht andere Schuld, es ist meistens einfach viel komplexer als es sich Leute (spezifisch in Führungs- und Leitungspositionen) oft bewusst sind und haarfein scheinende Details können enorm wichtig sein. Man vergisst Randfälle und geht nur vom Best case aus und der Kunde testet nur diese.

    Klar könnten wir Entwickler mehr testen, doch meistens gibt es keine sorgfältig erarbeitete Testdaten sondern der Kunde verwendet einfach Vorjahresdaten aus der Produktion, die er natürlich niemals rausgeben dürfte, und ich nicht auf meiner Maschine haben will, wenn das einer hackt und auf pastebin stellt, dann wäre ich für den Rest meines Lebens geliefert.

  17. Re: Nicht ganz korrekt

    Autor: peh.guevara 16.08.19 - 10:39

    demon driver schrieb:

    > Zum Beispiel könnte beim ersten Entwurf einer Maske zum schnellen Testen
    > ein Feld eingebaut worden sein, zunächst ohne beim Auslesen auf null zu
    > testen, das will man aber natürlich sofort nachholen, wenn's soweit ok
    > aussieht und die Datenübergabe funktioniert – und dann vergisst man
    > genau das.


    "Test Driven Development" und das pasiert nicht.

  18. Re: Nicht ganz korrekt

    Autor: gentux 16.08.19 - 11:18

    peh.guevara schrieb:
    --------------------------------------------------------------------------------
    > "Test Driven Development" und das pasiert nicht.

    Da muss der Kunde mal Testfälle liefern. Solche, die genau dem entsprechen, was er dann später verarbeitet haben möchte. Daran scheitert es oft, die Kunden nehmen dann echte Daten und die dürfen natürlich nicht deren Haus verlassen (und ich würde die nicht bei mir haben wollen, wenn sie nicht bei mir sind, können sie auch nicht bei mir gestohlen worden sein)

    Für TDD müsste man also den Test jeweils beim Kunden durchführen lassen, erkläre denen mal, dass du jederzeit remote verbinden möchtest um zu schauen ob der zuletzt eingecheckte Code noch durchläuft.

  19. Re: Nicht ganz korrekt

    Autor: demon driver 16.08.19 - 12:08

    peh.guevara schrieb:
    --------------------------------------------------------------------------------
    > demon driver schrieb:
    >
    > > Zum Beispiel könnte beim ersten Entwurf einer Maske zum schnellen Testen
    > > ein Feld eingebaut worden sein, zunächst ohne beim Auslesen auf null zu
    > > testen, das will man aber natürlich sofort nachholen, wenn's soweit ok
    > > aussieht und die Datenübergabe funktioniert – und dann vergisst man
    > > genau das.
    >
    > "Test Driven Development" und das pasiert nicht.

    Klar, aber man braucht das Buzzword nicht dafür. Man darf halt das Testen bloß nicht vergessen.

    (Abschweifung: Wieviele x für "x-driven development" gibt es eigentlich, die man alle machen sollte? Oh, und das alles natürich "agile"?)

  20. Re: Nicht ganz korrekt

    Autor: demon driver 16.08.19 - 12:17

    gentux schrieb:
    --------------------------------------------------------------------------------
    > peh.guevara schrieb:
    > ---------------------------------------------------------------------------
    > > "Test Driven Development" und das pasiert nicht.
    >
    > Da muss der Kunde mal Testfälle liefern. Solche, die genau dem entsprechen,
    > was er dann später verarbeitet haben möchte. Daran scheitert es oft [...]

    Es ist aber auch ein systematischer Fehler in der Entwicklung, vom Kunden zu erwarten, er wäre in der Lage dazu, die für eine vernünftige Testabdeckung erforderlichen Testfälle zu überblicken.

    Ein vernünftiges Testmanagement hat in der eigenen IT ausgewiesense Testspezialisten, die zusammen mit dem Kunden die nötigen Testszenarien erarbeitet und den Kunden überhaupt erst mal in die Lage versetzt, die Testfälle zu sehen. An der Stelle können die dann spezifiziert werden und Testdaten zusammengestellt usw....

    Disclaimer: Auch in meiner bisherigen Karriere war sowas bisher eher die Ausnahme...

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. EnBW Energie Baden-Württemberg AG, Karlsruhe
  2. Landratsamt Reutlingen, Reutlingen
  3. Joyson Safety Systems Aschaffenburg GmbH, Berlin
  4. über experteer GmbH, Köln, Düsseldorf, Hannover, Frankfurt, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 49,70€
  2. 139,00€ (Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Sonos Move im Test: Der vielseitigste Lautsprecher von Sonos
Sonos Move im Test
Der vielseitigste Lautsprecher von Sonos

Der Move von Sonos überzeugt durch Bluetooth und ist dank Akku und stabilem Gehäuse vorzüglich für den Außeneinsatz geeignet. Bei den Funktionen ist der Lautsprecher leider nicht so smart wie er sein könnte.
Ein Test von Ingo Pakalski

  1. Update für Multiroom-Lautsprecher Sonos-App spielt keine lokalen Inhalte mehr vom iPhone ab
  2. Smarter Lautsprecher Erster Sonos-Lautsprecher mit Akku und Bluetooth
  3. Soundbars Audiohersteller Teufel investiert in eigene Ladenkette

Hue Sync: Hue-Effektbeleuchtung dank HDMI-Splitter einfacher nutzbar
Hue Sync
Hue-Effektbeleuchtung dank HDMI-Splitter einfacher nutzbar

Mit Hue Sync können Philips-Hue-Nutzer ihre Lampen passend zu Filmen oder Musik aufleuchten lassen - bisher aber nur recht umständlich über einen PC. Die neue Play HDMI Sync Box ist ein Splitter mit eingebautem Hue-Sync-Controller, an den einfach Konsolen oder Blu-ray-Player angeschlossen werden können.
Ein Hands on von Tobias Költzsch

  1. Signify Kleiner Schalter und Steckdose für Philips Hue
  2. Smart Home Philips-Hue-Leuchtmittel mit Bluetooth
  3. Smart Home Philips Hue mit Außenbewegungsmelder und neuen Außenlampen

Elektrautos auf der IAA: Die Gezeigtwagen-Messe
Elektrautos auf der IAA
Die Gezeigtwagen-Messe

IAA 2019 Viele klassische Hersteller fehlen bei der IAA oder zeigen Autos, die man längst gesehen hat. Bei den Elektroautos bekommen alltagstaugliche Modelle wie VW ID.3, Opel Corsa E und Honda E viel Aufmerksamkeit.
Ein Bericht von Dirk Kunde

  1. Elektromobilität Stromwirtschaft will keine Million öffentlicher Ladesäulen
  2. Umfrage Kunden fühlen sich vor Elektroautokauf schlecht beraten
  3. Batterieprobleme Auslieferung des e.Go verzögert sich

  1. Samsung: Galaxy Fold bleibt extrem empfindlich
    Samsung
    Galaxy Fold bleibt extrem empfindlich

    Die versprochenen Überarbeitungen von Samsung an dem Falt-Smartphone Galaxy Fold, scheinen nach dem missglückten Marktstart doch nicht weitreichend genug zu sein. Eine offizielle Pflegeanleitung zeigt, wie empfindlich das Gerät weiterhin ist.

  2. Outlook, Exchange und Windows: Innenministerium bestätigt zu große Microsoft-Abhängigkeit
    Outlook, Exchange und Windows
    Innenministerium bestätigt zu große Microsoft-Abhängigkeit

    Das Bundesinnenministerium möchte eine "digitale Souveränität" bei Software in der Verwaltung erreichen. Dem stehen jedoch Monopolisten entgegen, allen voran Microsoft, wie eine Untersuchung im Auftrag des Ministeriums bestätigte.

  3. Energiespeicher und Sektorkopplung: Speicher für die Energiewende
    Energiespeicher und Sektorkopplung
    Speicher für die Energiewende

    In Norddeutschland testen Wissenschaftler, Unternehmer und Energieversorger gemeinsam, wie sich technische Innovationen in die Netze von Strom und Gas integrieren lassen. Doch steuerliche Regelungen bremsen manche Projekte.


  1. 11:21

  2. 10:51

  3. 09:57

  4. 19:00

  5. 18:30

  6. 17:55

  7. 16:56

  8. 16:50