Zu perfektionistisch zum Programmieren?
-
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.
-
Dann verstehe ich Deine Aussage nicht.
Es wurde Informatik/Mathematik vorgeschlagen, aber darauf hingewiesen, dass beide zunächst mal nicht viel mit Programmieren zu tun haben. Darauf konterst Du mit "Ich programmiere taeglich mit Scheme und mittlerweile mit Haskell. Hat ganz und gar nicht mit Programmieren zu tun ...
". Und jetzt kommt raus, dass Du Dich weder in den Bereich Mathematik noch in den Bereich Informatik einordnest, sondern einfach ein Programmierer sein willst. Das ist ja vollkommen in Ordnung, aber wo ist dann der Bezug zu der Aussage über Mathematik und Informatik? Mir scheint das fehlt ein Satzanfang wie "Ich bin Informatiker und..." oder "Ich bin im Bereich angewandte Mathematik tätig und..." um einen sinnvollen Bezug herzustellen. Nach nichts anderem habe ich gefragt, Du mußt Dich also auch nicht angegriffen fühlen. Ich will Dir bestimmt nicht verbieten, Deinen gesunden Menschenverstand walten zu lassen.
-
dann wäre Mathematik u./o. theoretische Informatik für dich geeignet. Mit Programmieren hat dies aber natürlich wenig zu tun.
Die Aussage, dass Mathematik u./o. theoretische Informatik nichts mit Programmieren zu tun hat, halte ich fuer falsch. Lisp oder Scheme haben das Lambdakalkuel als Vorbild, auch Haskell als modernes Lisp arbeitet intern mit diesem. Mit ihnen wird in auch (zu wenig) in der Industrie gearbeitet. Und das Lambdakalkuel ist wohl was ziemlich theoretisches in der Informatik. Andere Konzepte sind z.B. in Prolog realisiert. Mit Anwortmengenprogrammierung werden Hubschrauber gesteuert oder Triebwerkskonfigurationen ueberprueft. Wer solll denn diese Programme schreiben?
PS: Ich bin Informatiker. Nein, ich steuere keine Hubschrauber etc.
-
Nunja, dass Programmiersprachen und anderen Informatikanwendungen Dinge aus der theoretischen Informatik zugrunde liegen finde ich wenig überraschend. Das ist (hoffentlich) in so ziemlich allen Bereichen, die sich mit Informationsverarbeitung befassen so. Programmierung setzt also immer auf die theoretischen Grundlagen auf.
Aber ob die Theorie wirklich immer so viel mit Programmierung zu tun hat? Immerhin war man in den 30er-Jahren, als das Lambda-Kalkül eingeführt wurde noch weit von Programmierung und Computern entfernt. Sicherlich kann man als Informatiker sehr programmierlastig arbeiten, im Bereich theoretische Informatik sehe ich das aber eher nicht.
-
Aber ob die Theorie wirklich immer so viel mit Programmierung zu tun hat?
In diesem Fall schon. Waehrend damals lambda-Ausdruecke mit Bleistift und Papier z.B. als Uebung aufgeschrieben wurden, so schreibe ich aehnliche Ausdruecke nun in meinen Texteditor und fuehre sie aus.