Hallo liebe IT Community,

 

Da es mir selber schon oft passiert ist, bin ich nun auf der Suche nach Strategien und Tipps womit man verhindern kann das man sich in Details bei der Programmierung stecken bleibt. 

Wie verhindert Ihr das ihr zusehr in Details geht oder zuviel Zeit in einer Funktion oder Behebung von Problemen und Lösungen investiert?

 

lg

brit

Wenn man zu sehr in den Details feststeckt, dann sollte man sich überlegen, ob die Lösung überhaupt die richtige ist?
Zu viele Details bedeutet oftmals auch zu viel Code, der auch instabil ist. Man will wohl zu viel auf einmal erledigen. Daher wäre es wohl ratsam, hier ein Schlussstrich runterzusetzen und noch mal die Aufgabe überdenken. Evtl. müssen die Teilschritte noch mal unterteilt werden. Ratsam wäre auch mit einem Kollegen über die Aufgabe zu sprechen. Oftmals kommen da Ideen, an die man nicht gedacht hat. Pair-Programming kann in solchen Situationen auch hilfreich sein.

 

Mein vorschlag wäre sich vorher gedanke über die umsetzung und möglichen risiken machen. Sprich nen UML oder ähnliches und ne fehlermatrix wie wahrscheinl es ist das so ein fehler eintritt. Muss ich das abfangen oder reicht ne allgemeines abfangen.

vor 33 Minuten schrieb Hellspawn304:

Mein vorschlag wäre sich vorher gedanke über die umsetzung und möglichen risiken machen. Sprich nen UML oder ähnliches und ne fehlermatrix wie wahrscheinl es ist das so ein fehler eintritt. 

Wie wahrscheinlich ein Fehler auftritt, kann man häufig auch gar nicht beurteilen. Ich habs auch schon erlebt, dass ein gesamtes Entwicklerteam der Meinung ist, dass bestimmte Konstellationen selten bis gar nicht auftreten und schwupps hatte schon die ersten Kunden diese Konstellation. 

Viele Fehler lassen sich schon damit abfangen, wenn man Programmierregeln aufstellt.z.B. dass Listen niemals Null sein dürfen oder dass Null kein gültiger Rückgabewert ist. Auch hilft Praktiken, wie TDD schon sehr gut, sich kurz zu halten. Fehler, die auftreten könnten, können auch somit leichter getestet werden. Wer kleine Schritt macht, der kann dann auch zwischenzeitlich sein Code refaktorisieren und kann dabei alle Testfälle immer wieder laufen lassen.

Da gebe ich dir recht aber vorm coden solltest du dir gedanken mach ob es überhaupt sinn macht bestimmte sachen in ein testcase zu packen oder nicht.

Ich sehe eigentlich keinen Grund, ein Fehlerfall nicht zu überprüfen.
Wenn ein Fehler auftreten kann, so selten wie er auch sein mag, sollte man ihn auch abfangen.

Man verrennt sich eigentlich nicht aufgrund der Menge der Fehler, die auftreten können, sondern aufgrund der Komplexität des Codes und die Komplexität erhöht sich wegen ganz anderen Dingen.

Aber die Ausgangslage ist ja eine andere. Du vermittelst völlig richtige Regeln und Prinzipien, damit ein Boot nicht unter geht, die Frage, die gestellt wurde, ist aber, was tust du bei Schiffbruch... (ich und meine Vergleiche immer, ich weiß)

Ich würde versuchen, den Fehler soweit wie möglich einzugrenzen. Kommentiere überflüssigen Code aus, stell den kleinstmöglichen Testcase her, bis du die Zeile gefunden hast, die Schuld an allem ist. Dann schreib einen Test, der den Fehler provoziert, repariere es und teil deine Erkenntnis ggf. mit deinem Team. Falls sich der Fehler partout nicht lokalisieren lässt, hol dir jemanden an den Bildschirm und beschreibe, was passiert und wann der Fehler auftritt. Oft entdeckt man beim erklären selbst die Lösung (Rubber Duck).

vor 49 Minuten schrieb Ulfmann:

Aber die Ausgangslage ist ja eine andere. Du vermittelst völlig richtige Regeln und Prinzipien, damit ein Boot nicht unter geht, die Frage, die gestellt wurde, ist aber, was tust du bei Schiffbruch... (ich und meine Vergleiche immer, ich weiß)

Schiffbruch ist für mich noch was anderes. Schiffbruch ist, wenn das Produkt schon beim Kunden ist und es beim Kunden nicht erwartungsgemäß läuft. Vielleicht verstehe ich den TE auch nur falsch. Ich habe es so verstanden, dass der TE nicht mehr weiß, wo vorne und hinten ist. Also mit so vielen Spitzfindigkeiten beschäftigt ist, sodass kein stabiler Zustand erreicht werden kann. Jede Änderung provoziert dann den nächsten Fehler. 

Für mich müsste erstmal klarer umrissen werden was ich mir unter

vor 6 Stunden schrieb Britanny:

Wie verhindert Ihr das ihr zusehr in Details geht

vorstellen kann.

Im Normalfall geht es ja darum, dass Funktionen eben alles abdecken was sie abdecken sollen. Deshalb weiß ich nicht, wie man da zu viel Zeit investieren kann um dieses Ziel zu erfüllen... außer man sitzt 2 Stunden davor um sich das nächste Testszenario auszudenken.

vor 6 Stunden schrieb Britanny:

oder zuviel Zeit in einer Funktion oder Behebung von Problemen und Lösungen investiert?

Der Teil ist einfach.

Wenn ich an einem Bug sitze und nach einer gewissen Zeit kein Stück voran gekommen bin, frage ich jemanden ob er mal ein paar Minuten mit rüber sehen kann. Siehe @Ulfmanns Post.

Nun, bei mir im Betrieb ist es aber nicht möglich jemanden zu fragen weil ich quasi der einzige Anwendungsentwickler hier bin und niemand sich hiermit dem programmieren und Anwendungsentwicklung auskennt. Hier gibt es nur Fachinformatiker für Systemintegration. 

Ein Punkt den ich mir setze ist das ich mir zeitliche Etappen setze.So das ich einmal am Tag wenn ich eine Funktion oder Testbare/Vorführbare Code habe diesen jemanden zeige und erkläre. Dadurch erhoffe ich mir nicht nur ein Feedback sondern ich setze mir eine zeitliche, wenn auch grobe Frist.

Das ist natürlich nur ein Punkt. Ich möchte aber mehr lernen wie man ein eine Anwendung, ein Ziel organisiert um dieses nicht nur sicher zum 100% Abschluss bringt, sondern auch in einer festgelegten Zeit. Das hört sich nach Projekt und Zeitmanagement an  Aber ich denke gerade als Anwendungsentwickler hat man damit sehr viel zu tun. 

 

lg 

brit