Zu perfektionistisch zum Programmieren?
-
Hallo alle zusammen,
die Frage klingt vielleicht etwas komisch, aber ich habe bemerkt, dass ich mich beim Programmieren immer an Kleinigkeiten verharke und Stunden, oder sogar tagelang daran herumwerke bis es mir gefällt. Oftmals schmeiße ich es dann doch wieder über den Haufen und schreibe es zum hundersten mal neu. Für mich muss immer alles definiert sein und sogar für meine Notation habe ich alles ausgearbeitet und Wehe irgendwo ist ein Tab mehr als es soll. Es ist jetzt schon so schlimm geworden, dss ich kaum irgendetwas beim programmieren auf die Reihe bekomme, sondern im Grunde nur noch alles formatiere und designe. Dies hat mir in der Schule, besonders in Mathematik und Physik geholfen, weil da ja fast alles definiert ist. Bis jetzt hatte ich vor Informatik zu studieren, aber jetzt kommen mir Zweifel. Ich weiß natürlich, dass programmieren nur ein kleiner Teil der Informatik ist, aber oftmals kommt man dann doch in diese Sparte. Es gibt natürlich noch andere Fächer wie Wirtschaftsinformatik, aber dort ist der Informatik Anteil dann doch recht klein. Was ich mich nun Frage ist, ob einer einen Beruf kennt wo dieser "Definitionszwang" nützlich sein könnte. Rückblickend fällt mir auf, dass ich ihn schon lange habe, aber wirkliche Probleme hat er kir noch nie gebracht. Ich kann ganz normal mit anderen Leuten usw. Feiern gehen und bin kein Sozialnerd. Spontan ist mir Anwalt in den Sinn gekommen, weil da ist ja so gesehen wirklich alles definiert. Am interessantesten finde ich allerdings die naturwissenschaftlichen Fächer und da ich weiß, dass sich hier Leute aller Richtungen tummeln frage ich einfach mal nach.
Mit freundlichen Grüßen
-
A. Der Formalitätstrip wird dir spätestens nach der dritten Woche Uni-Mathe vergehen.
B. Spätestens in der Praxis, wenn du es mit halbwegs komplexen JavaEE-Systemen und anderen hübschen Middlewareimplementierungen zu tun hast, wirst du deine perfektionstische Ader sicher nicht mehr ausleben können. Idr. zählt weder 'Schönheit' (wie auch immer man diese objektiv bewerten kann?!), sondern nur pures Funktionieren für den Moment. Dazu sind die verwendeten Systeme oft viel zu komplex, als dass du diese wirklich verstehen kannst, um schön zu Programmieren.
C. Wenn du wirklich so oft deinen Code wegschmeißt, solltest du vllt. überlegen, etwas Zeit in Softwarearchitektur zu investieren. Ansonsten könnte es auch lohnenswert sein, Lisp zu lernen und sich mit den verschiedenen Grundlagen von Programmiersprachen und deren Paradigmen auseinander zu setzten. LTU wäre hier ein guter Einstiegspunkt.
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.
-
lol
-
Wehe irgendwo ist ein Tab mehr als es soll.
Hast du keinen vernuenftigen Texteditor oder was? Das wird normalerweise von der IDE uebernommen. Auch gibt es Codebeautifier, die das fuer dich uebernehmen und alles vollautomatisch. Ich kenne auch nicht deinen Programmierstil, aber z.B. Kommentare rechts neben Quelltext buendig auszurichten, macht keinen Sinn.
troll0r schrieb:
A. Der Formalitätstrip wird dir spätestens nach der dritten Woche Uni-Mathe vergehen.
Sorry, bei mir nicht.
B. Spätestens in der Praxis, wenn du es mit halbwegs komplexen JavaEE-Systemen und anderen hübschen Middlewareimplementierungen zu tun hast, wirst du deine perfektionstische Ader sicher nicht mehr ausleben können .... verwendeten Systeme oft viel zu komplex, als dass du diese wirklich verstehen kannst, um schön zu Programmieren.
Ich sage eher, dass sie so komplex sind, weil sich niemand vorher mal ernsthaft Gedanken darueber gemacht hat.
LTU wäre hier ein guter Einstiegspunkt.
Immer dieser Abkuerzungswahn, als ob es so schwer ist, LTU auszuschreiben. Mein erster Gedanke war die Fluggesellschaft. Auch sollte nicht davon ausgegangen werden, dass jeder lambda the ultimate kennt.
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 ...
-
knivil schrieb:
B. Spätestens in der Praxis, wenn du es mit halbwegs komplexen JavaEE-Systemen und anderen hübschen Middlewareimplementierungen zu tun hast, wirst du deine perfektionstische Ader sicher nicht mehr ausleben können .... verwendeten Systeme oft viel zu komplex, als dass du diese wirklich verstehen kannst, um schön zu Programmieren.
Ich sage eher, dass sie so komplex sind, weil sich niemand vorher mal ernsthaft Gedanken darueber gemacht hat.
du weißt nicht, wovon ich rede. Hast du echte Erfahrung außerhalb der privaten Frickelei und der "Forschung" an einer Bildungseinrichtung?
-
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.