Zu perfektionistisch zum Programmieren?
-
die Frage klingt vielleicht etwas komisch, aber ich habe bemerkt, dass ich mich beim Programmieren immer an Kleinigkeiten verhake und Stunden, oder sogar tagelang daran herum werke bis es mir gefällt. Oftmals schmeiße ich es dann doch wieder über den Haufen und schreibe es zum hundertsten mal neu.
(in den zwei Sätzen waren übrigens drei orthographische Fehler drinnen, hab's mal korrigiert, da Du so penibel bist)
Du wärst im OS-Development-Bereich vielleicht richtig. Da kommt es wirklich auf jede kleine Veränderung an. http://www.c-plusplus.net/forum/viewtopic-var-t-is-247814.html
-
knivil schrieb:
D. Definitionszwang? Wenn du dies wirklich ernst meinst, dann wäre Mathematik u./o. theoretische Informatik für dich geeignet. Mit Programmieren hat dies aber natürlich wenig zu tun.
Ich programmiere taeglich mit Scheme und mittlerweile mit Haskell. Hat ganz und gar nicht mit Programmieren zu tun ...
Und was sagt uns das? In welchen der Bereiche würdest Du Dich wie einordnen?
-
Zu perfektionistisch im Design, aber nicht in der Lage ein paar Absätze in deinen post einzufügen, um ihn einigermaßen lesbar zu machen?
Irgendwo hast du ein Problem.
-
Wenn man nicht gerade Termindruck hat ist Code Wegschmeißen doch gar kein Problem. Es gibt haufenweise Projekte welche in einer Version 2 als kompletter rewrite erscheinen. Wenn man etwas zum ersten mal schreibt wird man selten den kompletten Umfang und alle möglichen Probleme im Voraus sehen. Solange man also daraus lernt und man es nächste mal besser macht ist alles in ordnung.
-
Tobiking2 schrieb:
Wenn man nicht gerade Termindruck hat ist Code Wegschmeißen doch gar kein Problem.
Als ich programmieren lernte hat man von uns verlangt auf Anhieb ein fehlerfreies Programm (unter Zeitdruck) zu schreiben.
Nix mit "Das kann ich ja später noch ändern/reparieren."
-
das bis ins kleinste detail durchzugehen würde wohl mehr zeit verbrauchen als schon einmal einen kleinen entwurf anzufertigen
-
troll0r schrieb:
D. Definitionszwang? Wenn du dies wirklich ernst meinst, dann wäre Mathematik u./o. theoretische Informatik für dich geeignet. Mit Programmieren hat dies aber natürlich wenig zu tun.
naja, ich würde dann auch zu mathe oder philosophie raten. ohne definitionen läuft da garnix. andererseits kann man beim programmieren auch vieles definieren, z.b. du entwickelst bibliotheken und zwingst damit anwendern deine definitionen von schnittstellen, objekten und benutzungsregeln auf. aber wenn du 'ne richtig sadistische ader hast, dann entwickle programmiersprachen. dabei kannste deinen definitionstrieb so richtig ausleben und flüche der benutzer werden dir sicher sein.
-
EOP schrieb:
Als ich programmieren lernte hat man von uns verlangt auf Anhieb ein fehlerfreies Programm (unter Zeitdruck) zu schreiben.
Nix mit "Das kann ich ja später noch ändern/reparieren."
Und wie komplex waren die Programme anno dazumal? Und ich meine nicht Algorithmus XYZ, den man sauber umsetzen muss, sondern ein umfangreiches Design mit Dutzenden von Komponenten, Fremdbibliotheken die man noch nicht wirklich kennt und oben drauf noch ein paar schwammige Anforderungen, die während der Entwicklung ständige Änderungen im Code nötig machen.
-
Ein "Pefektes Programm" erfüllt die Voraussetzungen:
- Möglichst schnell mit einfachsten Mitteln programmiert
- Jederzeit übersichtlich - auch für andere - geschrieben
- Stabiles Laufverhalten
- Mögliche Ausnahmefälle sind abgefangen
- Leichte Wartbarkeit zur nachträglichen Fehlersuche und Erweiterung
Es kommt nicht darauf an, einen "schönen" Code zu schreiben, sondern einen "sicheren" und "schnellen"!
-
berniebutt schrieb:
Ein "Pefektes Programm" erfüllt die Voraussetzungen:
- Möglichst schnell mit einfachsten Mitteln programmiert
- Jederzeit übersichtlich - auch für andere - geschrieben
- Stabiles Laufverhalten
- Mögliche Ausnahmefälle sind abgefangen
- Leichte Wartbarkeit zur nachträglichen Fehlersuche und Erweiterung
Es kommt nicht darauf an, einen "schönen" Code zu schreiben, sondern einen "sicheren" und "schnellen"!oehm. da fehlt das wichtigste:
Es tut genau das was es soll.
-
berniebutt schrieb:
Ein "Pefektes Programm" erfüllt die Voraussetzungen:
- Möglichst schnell mit einfachsten Mitteln programmiert
- Jederzeit übersichtlich - auch für andere - geschrieben
- Stabiles Laufverhalten
- Mögliche Ausnahmefälle sind abgefangen
- Leichte Wartbarkeit zur nachträglichen Fehlersuche und ErweiterungDu hast gute Testabdeckung vergessen
Es kommt nicht darauf an, einen "schönen" Code zu schreiben, sondern einen "sicheren" und "schnellen"!
Code, der nicht "schön" ist, ist meist schlecht zu lesen. Code, der schwer zu lesen ist, ist noch schwerer nachzuvollziehen, geschweige denn dass man "Sicherheit" garantieren kann. -> Wirklich sicherer Code sollte auch halbwegs schön sein.
-
@ xroads42: gut! Dann könnte man auch noch hinzufügen: "Ich habe die Zielsetzung verstanden".
@ pumuckel: Dein Verständnis von "schön" unterscheidet sich nicht wesentlich von meinen Ausführungen. Bei Bauingenieuren ist eine "schöne" Brücke meist auch jene, die mit dem geringsten Aufwand (Geld, Material) gebaut werden kann.
Das Thema ist aber komplex. Ich selbst führe bei jeder Programmentwicklung ein Ablaufprotokoll mit, das ich jederzeit auskommentieren kann. So spare ich mir vieles mühsame Debuggen. Macht etwas mehr Mühe, zwingt zur Sorgfalt, und ist später leicht reaktivierbar. Soviel zum Punkt Testabdeckung.
-
berniebutt schrieb:
Es kommt nicht darauf an, einen "schönen" Code zu schreiben, sondern einen "sicheren" und "schnellen"!
... was aber nicht selten dasselbe ist.
Oder sein sollte, wenn die Implementationssprache so gewählt ist, daß sich das Problem gut in die Sprachmittel abbilden läßt.
-
Zum Problem wirds nur dann, wenn jemand krampfhaft versucht "schönen Code" zu schreiben, in dem Zuge das Projekt auch mehrfach umschreibt weil es noch nciht schön genug ist und am Ende nach 3 Monaten immer noch nix laufen hat obwohl die eigendliche Aufgabe in 3 Wochen hätte geschafft werden können... (Leider konkretes Beispiel aus meinem Umfeld...)
Wenn ich die Wahl habe zwischen einer häßliche Lösung die ich dafür innerhalb der Deadline fertigstellen kann und einer schönen Lösung durch die ich dann aber die Deadline verfehle...
Ich habe oft das (zugegeben subjektive) Gefühl das besonders Anfänger sich unheimlich viele Gedanken über "Schönheit" des Codes machen und darin auch irre viel Zeitaufwand investieren wogegen Profies einfach die Lösung nehmen die für die Aufgabe passt, sie implementieren und dann weiterziehen zum nächsten Problem...
-
loks schrieb:
Ich habe oft das (zugegeben subjektive) Gefühl das besonders Anfänger sich unheimlich viele Gedanken über "Schönheit" des Codes machen und darin auch irre viel Zeitaufwand investieren wogegen Profies einfach die Lösung nehmen die für die Aufgabe passt, sie implementieren und dann weiterziehen zum nächsten Problem...
Das Gefühl habe ich auch. Ist dann aber OK, wächst sich ja sozusagen raus.
-
Ich habe oft das (zugegeben subjektive) Gefühl das besonders Anfänger sich unheimlich viele Gedanken über "Schönheit" des Codes machen und darin auch irre viel Zeitaufwand investieren wogegen Profies einfach die Lösung nehmen die für die Aufgabe passt, sie implementieren und dann weiterziehen zum nächsten Problem...
Völlig falsch. Genau das Gegenteil ist der Fall!
-
lol²³² schrieb:
Ich habe oft das (zugegeben subjektive) Gefühl das besonders Anfänger sich unheimlich viele Gedanken über "Schönheit" des Codes machen und darin auch irre viel Zeitaufwand investieren wogegen Profies einfach die Lösung nehmen die für die Aufgabe passt, sie implementieren und dann weiterziehen zum nächsten Problem...
Völlig falsch. Genau das Gegenteil ist der Fall!
Genau. Oft ist es so, dass Anfängercode lediglich funktionieren soll, während bei fortgeschrittenen Programmierern viel mehr Wert auf sauberes Design gelegt wird. Dass sich das lohnt, merkt man oft erst mit genügend Erfahrung. Bei objektorientierten Problemen gehört dazu z.B. das Überlegen im Voraus, wie die Zusammenhänge zwischen Klassen aussehen sollen (beispielsweise mit UML). Sowas macht keiner, der erst gerade angefangen hat.
Natürlich gibt es auch Einsteiger, die versuchen, alles von Anfang an schön zu machen. Das ist meines Erachtens aber nicht besonders sinnvoll, weil man da kaum Kriterien für "Schönheit" bzw. "Sauberkeit" kennt, sondern diese erst mit gemachten Fehlern lernt (indem man merkt, wie hässlicher Code aussieht und welche Probleme er mit sich bringt). Oft macht man sich dadurch mehr Aufwand als nötig und kommt trotzdem keinen Schritt weiter. Das heisst natürlich nicht, dass man als Anfänger grundsätzlich keine solchen Überlegungen anstellen soll, aber viele Dinge sind einem eben gar nicht bewusst.
-
Nexus schrieb:
Oft ist es so, dass Anfängercode lediglich funktionieren soll, während bei fortgeschrittenen Programmierern viel mehr Wert auf sauberes Design gelegt wird. Dass sich das lohnt, merkt man oft erst mit genügend Erfahrung.
Stimmt, so _sollte_ es sein. Ein Anfänger sollte sich darum kümmern Grundlagen zu verstehen, Konzepte zu begreifen und die Sprache zu lernen. Die Frage, ob das denn nu schön oder häßlich is sollte in der Phase hinten anstehen.
Jedoch scheint es mir oft das Anfänger eben genau das nicht machen sondenr im Gegenteil übermässig viel Zeit mit Begriffen wie "Schönheit" und "Eleganz" verbringen ohne die zugrunde liegenden Konzepte zu begreifen.
-
Ich habe oft das (zugegeben subjektive) Gefühl das besonders Anfänger sich unheimlich viele Gedanken über "Schönheit" des Codes machen und darin auch irre viel Zeitaufwand investieren wogegen Profies einfach die Lösung nehmen die für die Aufgabe passt, sie implementieren und dann weiterziehen zum nächsten Problem...
Anfänger machen sich meistens viele Gedanken über premature Optimization.
-
Jester schrieb:
Und was sagt uns das? In welchen der Bereiche würdest Du Dich wie einordnen?
Ist Logik nur den Mathematikern vorbehalten oder darf man als Programmierer nicht gesunden Menschenverstand walten lassen? Logik spiegelt sich vor allem in Programmen als auch beim Programmieren wieder. Ich wuerde mich als Programmierer bezeichnen.