Wie kann ich besser programmieren?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
PyByte
User
Beiträge: 25
Registriert: Samstag 16. Oktober 2010, 03:32

Hallo Community,

ich mache immer wieder die Erfahrung, dass wenn ich eine Programmiersprache soweit gelernt habe, dass ich damit erste Programme entwickeln kann, dann habe ich ganz neue Schwierigkeiten beim programmieren.
Sobald ein Programm nur ein wenig komplexer wird wird sofort deutlich dass nun ein gewisses Wissen über design pattern und bestimmte Richtlinien gefragt ist.
Auch tue ich mich immer wieder schwer damit Variablen sinnvoll zu benennen. Immer wieder tauchen Fragen auf wie "welcher ist der saubere Stil von den x Möglichkeiten?" oder "welche Vorgehensweise ist in dieser Programmiersprache üblich?".

Am schlimmsten empfinde ich es wenn ich vor einem Problem stehe und merke dass man es durch verschiedene Vorgehensweisen lösen kann. Was manchen die Sache vielleicht einfacher macht empfinde ich meistens als störend, da ich die häufig tiefer verborgenen Vor- und Nachteile nicht erkenne und somit die verschiedenen Vorgehensweisen nicht miteinander vergleichen kann.
Was nicht selten dazu führt dass sich verschiedene Vorgehensweise im nachhinein inkompatible zueinander verhalten. Dann erst fällt dann die Entscheidung für eine Vorgehensweise. Was aber dann zu nervigen Umbauarbeiten am Code führt.

Habt ihr Tipps wie ich besser werden kann? Kann man da irgendwie gezielt besser werden? Oder gibt es keine Alternative zu "mache tausende Fehler und ein Dutzend schlechte Programme und lerne daraus"?
Benutzeravatar
__blackjack__
User
Beiträge: 13110
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@PyByte: Ich würde sagen letztendlich das was im letzten Satz steht.

Was das mit den Umbauarbeiten angeht: Da kann man entgegenwirken in dem man sich vorher Gedanken über Schnittstellen macht, so dass man zwar hinter der Schnittstelle etwas umbauen muss, wenn man eine Vorgehensweise ändert, das aber möglichst keine Auswirkungen über die Schnittstelle hinaus hat.

Und verschiedene Vorgehensweisen, bei denen man erst beim entwickeln merkt, das man eine andere, bessere braucht, kommt auch bei erfahrenen Programmierern vor. Zum Beispiel weil man die Anforderungen am Anfang falsch eingeschätzt hat, oder sich Anforderungen auch im Laufe der Zeit ändern. Oder man lernt eine neue Bibliothek kennen, die nützlich wäre, wenn man seinen Code etwas anders geschrieben hätte.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
__deets__
User
Beiträge: 14541
Registriert: Mittwoch 14. Oktober 2015, 14:29

Ich denke auch, dass letztlich nur Uebung, Uebung, Uebung den Meister macht. Allerdings gibt es mE einige hilfreiche Vorgehensweisen, die zielfuehrend sind.

Anfaenger, aber auch gestandene Entwickler, leiden oft unter YAGNI - you ain't gonna need it. Also Code der geschrieben wird in der Annahme, dass er spaeter nuetzlich wird. Die Erfahrung zeigt, dass dies oft nicht der Fall ist, und fuehrt zu mehr Verschwendung und Frustration wenn Komponenten integriert werden.

Ein Weg dieses Problem zu addressieren, und auch allgemein die Qualitaet des Codes zu verbessern, ist die Nutzung von TDD - test driven development. Damit hat man zum einen fuer den Code gleich eine Nutzung, die zB Design-Fehler aufzeigt. Die Notwendigkeit, bestimmte Dinge fuer Tests moeglichst weg zu bekommen zeigt, wo gute Schnittpunkte sind, um seinen Code nicht zu sehr aneinander zu koppeln. Und weil man keinen Code schreiben sollte, der nicht dann auch gleich getestet wird, schuetzt man sich ein bisschen vor YAGNI.

Und auch fuer wechselnde Anforderungen, die immer zum tragen kommen bei Code der etwas laenger lebt, kann man damit besser begegnen. Weil man bei notwendigen Refactorings sich nicht blind auf deren Funktionieren verlassen muss.
Benutzeravatar
pillmuncher
User
Beiträge: 1484
Registriert: Samstag 21. März 2009, 22:59
Wohnort: Pfaffenwinkel

@PyByte: "An expert is a person who has made all the mistakes that can be made in a very narrow field." -- Niels Bohr.
In specifications, Murphy's Law supersedes Ohm's.
Antworten