Boehrsi.de - IT und Gaming Blog

I'm a coder - Nervige Dinge beim Programmieren

Erstellt am event Uhr von account_circle Boehrsi in label Boehrsi
I'm a coder - Nervige Dinge beim Programmieren Bild

Ich entwickle gerne Software, sowohl professionell, wie auch privat, doch manchmal gibt es einfach unschöne Aufgaben, nervige Bugs oder andere Situationen auf die man lieber verzichten würde. Die Top 5 der nervigsten Dinge beim Programmieren - für mich persönlich - möchte ich heute im Rahmen einer weiteren I’m a coder News vorstellen.
Unklare / nicht durchdachte Aufgabenstellung: Egal in welchem Kontext, immer mal wieder stolpert man über nicht fertig gedachte Ideen und Ansätze. Daraus resultiert dann oft eine Änderung der eigentlichen Aufgabe, noch während man initial dabei ist. Dadurch ändern sich auch gerne grundlegende Dinge, sodass ordentlich Hirnschmalz benötigt wird, um entsprechende Anpassungen zu machen ohne komplett neu beginnen zu müssen. Solche Dinge kann man durch ordentliche Planung einschränken, aber leider niemals komplett ausschließen. Gerade im privaten Bereich empfehle ich in diesem Kontext alles zu notieren und ein paar Tage reifen zu lassen, denn wenn man blind drauflos schreibt, landet man häufig in besagter Situation.
Trial and Error Bugfixing: Ein Bug wird entdeckt und die Jagd nach Ursache und Lösung geht los. Auf dem Weg zu Lösung gibt es einige Zwischenschritte und manchmal hat man das Pech einen nicht reproduzierbaren und entsprechend auch nicht wirklich lösbaren Bug zu finden. Dabei kann man dann nur herumprobieren, um sich an eine Lösung anzunähern. Ebenso sieht es aus wenn man zwar genau weiß wo das Problem ist, aber eine klare Lösung nicht erkennbar oder gar möglich ist. Somit kann man auch hier nur via Trial and Error Ansatz versuchen das Problem zu lösen. Am frustriertesten finde ich dabei die Menge an Zeit die man investiert ohne Fortschritte zu machen und ohne Code zu erstellten. Meistens kommt man trotzdem zu einer Lösung und alles ist wieder gut, es gibt allerdings definitiv dankbarere Aufgaben. Wirklich tun kann man gegen diese Art von Problemen leider auch nichts, denn diese Art von Bugs kommt bei der Entwicklung einfach auch vor.

Plattform-Bugs: Je nachdem für welche Plattform man entwickelt kommt dies häufiger oder seltener vor, aber es ist immer extrem nervig. Ich rede von Plattform-Bugs, also Fehlern die direkt auf dem System für welches ihr entwickelt vorhanden sind. Gegen selbige kann man quasi gar nichts machen und Workarounds sind meistens von Nöten. Und ob man überhaupt schafft was man eigentlich erreichen wollte ist fraglich, denn wenn die Plattform sich sträubt hat man quasi keine Alternativen, außer einen komplett anderen Entwicklungsweg einzuschlagen. Auch gegen dieses Problem kann man leider nicht wirklich etwas machen, außer zu hoffen das die Plattform, die dazugehörigen SDKs und ähnliches gut gepflegt sind.
Build-Zeiten / IDE Probleme: Egal welche Sprache oder Plattform man wählt, man hat eine IDE in welcher man entwickelt und irgendwann kommt der Moment indem man sich sein Programm zum Testen bauen lassen will. Dabei muss man dann die Build-Zeit abwarten und schon kann es mit dem Testen losgehen. Doch was wenn die Build-Zeit bei mehreren Minuten liegt und man täglich 50+ Mal bauen muss? Genau, man wartet bis zum verrückt werden und wenn dann auch noch die IDE selbst kleiner Macken hat, ist der Wahnsinn nicht weit. Shortcuts die durch System-Shortcuts überschrieben werden, ein nicht automatisch ausgewähltes Suchfeld und viele andere kleine Dinge kommen mir dabei spontan in den Kopf. Hier hilft es Probleme in der IDE direkt zu adressieren und zu beheben und nicht auf die lange Bank zu schieben. Denn ihr müsst bedenken, dass sie euch immer und immer wieder nerven werden. Nehmt euch also dieselbe Zeit die ihr euch für einen Bugfix nehmen würdet, um eure IDE für den täglichen performanten Gebrauch fit zu machen. Bezüglich Build-Zeiten hilft es oft Mittels Plattform-Optimierungen und ein paar Google-Suchen das Ganze Projekt zu optimieren. Dies kann wahre Wunder wirken, z.B. im Android + Gradle Bereich und falls gar nichts mehr hilft, ist es vielleicht auch Zeit für neue Hardware.
Externe Fehler und die Beweispflicht: Wir alle machen Fehler und in großen Projekten, mit vielen involvierten Parteien, ist es schwer herauszufinden wo das Problem liegt. Diese Situation gibt es immer wieder und meistens ist jeder der Meinung man selbst hätte alles richtig gemacht. So ist quasi jeder in der Position, dass er zum einen versucht das Problem zu finden, zum anderen aber auch zu zeigen, dass es eben nicht am eigenen Code liegt. Das Zusammenspiel aus Server / Client / Datenbank kann hier schon reichen, wobei bei größeren Projekten ja noch diverse weitere Parteien involviert sind, welche wesentlich externer sind als die hier genannten. Wichtig ist niemals Probleme mit dem eigenen Code komplett auszuschließen, denn auch man selbst ist nicht perfekt. Zusätzlich sollte man sich aber auch keine Fehler einreden lassen, wenn man seinen eigenen Code geprüft hat und er einwandfrei funktioniert. Kommunikation ist hier das A und O, da man sich sonst in einem nervigen hin und her verliert, anstatt das eigentliche Problem angehen zu können.
Soweit eine kleine Anekdote von meiner Seite, wie sieht es bei euch aus? Was nervt euch beim Programmieren am meisten?

Kommentare  
Kommentar erstellen
Mit dem Abschicken des Kommentars erklären sie sich mit der in der Datenschutzerklärung dargelegten Datenerhebung für Kommentare einverstanden. Spam, unangebrachte Werbung und andere unerwünschte Inhalte werden entfernt. Das Abonnieren via E-Mail ist nur für E-Mail Adressen erlaubt die Sie rechtmäßig administrieren. Widerrechtliche Abonnements werden entfernt.