Was macht euch am Programmieren Spaß?
Was macht euch am programmieren spaß?
10 Antworten
DH @ Sven Kribitz, brilliant formuliert. Für mich ist es der Thrill eine Problemstellung A in eine Problemlösung B zu überführen in einem Denkprozess mit allem Wissen das mir zur Verfügung steht, auch das Internet selbstverständlich aber keine Youtoubevideos (Ausser die von Herrn Jörn Lovischach). Man wird also fürs Denken bezahlt und nicht fürs Arbeiten.
Eine Erinnerung aus meiner Zeit als Softwareentwickler:
Die Klientenfirma kaufte sich neue Laserdrucker mit verschiedenen Papierschächten für verschiedene Vordrucke (Logo farbig, verschiedene Firmenlogos und einer für nur auf weißem Papier). Soweit so gut, nur das Warenwirtschaftsprogramm sollte mitspielen und so haben sich das die Unternehmensberaterprofis das vorgestellt.
Hier kommt mein Part: „Herr Porpaczy, zaubern Sie".
Ich plagte mich gefühlte 42 Mannstunden damit ab, Druckerescapesequenzen zu programmieren und der ... Drucker endlich kapieren sollte welchen Schacht er nehmen sollte. Die verwendete Programmiersprache unterstützte das nicht also blieb mir nur das (Das ist like Assembler).
Die Erlösung war VPE (Virtual Print Engine). Jetzt war das wählen der Papierschächte einfach und es konnte irre geile Sachen zusätzlich. Nur halt ActiveX, so dachte mein Boss und als ich ihm gesagt habe, dass es mir gelungen ist, die DLL einzubinden rief er lauf: „Sieg!", das machte mich stolz wenn ich darauf zurückblicke und in, wenn nicht der renomiertesten Unternehmensberaterfirma in Tirol.
@M.(007)
1zu1, was Sven Kribitz schreibt.
Einzig der Sudoku-Analogie würde ich nicht ganz zustimmen.
Mich interessiert mehr, eine Lösung so aufzubauen, dass ich mit Änderungen daran nichts anderes zerschießen *kann*. Klar, das wird mir nicht gelingen, aber ich versuche zumindest so nahe heran zu kommen, wie es geht ^^
Und - das werden vermutlich einige nicht verstehen - ich hab einen riesen Spaß dabei, Lösungen für etwas zu finden, bei dem andere aufgegeben haben oder gesagt haben, dass es nicht geht :D Der Nachteil ist leider, dass die Lösungen dabei meist ziemlich komplex sind und das einfacher aufbauen ist gar nicht so einfach.
Oder Fehlersuche, ich suche gerne Fehler, allerdings nur, wenn es keine "Ich hab keine Ahnung, was ich tue, also copy&paste ich irgendwas"-Fehler sind, die kann ich gar nicht leiden :/ Debugging stört mich dabei nicht, aber meistens vermeide ich es, weil es einfach langsam ist.
Was mich am meisten stört, ist gar nicht mal der Stress (damit kommt ich irgendwie ganz gut klar), sondern wenn Kollegen sich auf ihrem alten Wissensstand ausruhen oder entscheidende Personen bewusst qualitative Arbeitsweise verhindern, nur weil es am Anfang ein klein wenig günstiger ist.
Natürlich ist dieses "nichts zerschießen" sehr von der Situation abhängig.
Ich meine damit hauptsächlich, dass ...
... jede Klasse und Methode für sich abgesichert ist. Eine Methode stellt sicher, dass Parameter im definierten Bereich stehen und dass am Ende der Methode ein gültiger Zustand zurück bleibt - auch im Fehlerfall. Genauso muss eine Klasse sofort funktionsfähig sein.
Geht das nicht, dann muss es einen definierten und somit auch überprüfbaren Zustand geben, der das Gegenteil (z.B. nicht initialisiert, Fehlerhaft, etc.) beschreibt. Es darf nie zu einem undefinierten Zustand kommen können.
... inhaltliche Abhängigkeiten von konkreten Datentypen beschrieben sind. Also kein Magic-Values, dafür gehen auch Enums, oder der Aufrufer muss die Auswertung dieser Magic-Values übernehmen, oder oder oder ...
... jede Klasse möglichst wenig veränderliche Inhalte hat. Z.B. Daten-Objekte, die wie eine billige *** durch zig Methoden durchgereicht und beliebig verändert werden, gibt es bei mir nicht, eher reiße ich mir einen Arm aus :D Wenn es doch änderbare Zustände geben kann, müssen die wieder klar definiert sein.
Das wären so meine gerade spontan ausformulierten Regeln :D
Somit kann es immer noch Seiteneffekte geben, aber die fallen dann schnell auf.
Vermutlich findet man vieles davon in der funktionalen Programmierung wieder, aber die ist mir etwas zu streng.
Natürlich geht das nicht immer, aber der Versuch kann es nur besser machen, denke ich ^^
Guten Morgen eineTolleFra144,
ich sage immer programmieren ist wie Sodoku spielen.
Ich implementiere irgendwo eine Lösung, bei der ich achten muss, dass nicht irgendwo anders etwas zerschossen wird.
Mir macht es vor allem Spaß neue Dinge zu implementieren und dabei kreativ sein zu können. Es ist ein tolles Gefühl eine Anwendung zu veröffentlichen, die viele Leute nutzen und man sieht, dass viele der eigenen Features verwendet werden und das Feedback gut ist.
Ebenso bin ich in Sachen programmieren sehr exakt und ordentlich. Ich finde es deshalb einfach sehr angenehm, saubere Strukturen zu schreiben.
Man könnte bei mir wahrscheinlich eher fragen, was mir am Programmieren am wenigsten Spaß macht. :o)
Stress. Wenn man eine Deadline hat und ein Feature noch durchgezogen werden muss. Dann kann man manchmal nicht zu sauber arbeiten und Bugs können die Folge sein. Aber es gehört dazu. Bis auf diesen Punkt macht mir alles beim Programmieren spaß!
Liebe Grüße und einen schönen Donnerstag noch!
Spaß macht vor allem, wenn man sieht, wie das Programm sich zu etwas entwickelt, mit dem man anschließend etwas tun kann, was man von Hand auf keinen Fall hätte tun können.
- das Entwickeln von irgendwelchen Algorithmen, die einfach noch nicht da sind (kein Standard - also nicht der 300ste Bubblesort). Ein Problem / Aufgabe solange per Kopfarbeit zerlegen, bis man es entsprechend in einer Programmiersprache aufschreiben kann.
- das Nach-Optimieren, Quellcode-Aufräumen, noch ein Quentchen Performance rauspressen. Früher (komme aus den 80ern) den Speicherbedarf noch um ein paar Bytes verringern.
- Debugging: in jedem Schritt genauso zu denken, wie der Compi das Programm abarbeitet und so rauszufinden, wo und warum das Programm von dem abweicht, was eigentlich beabsichtigt war. Dann kann man sich so schön ärgern, warum man es nicht gleich richtig gemacht hat.
- bei der Nacharbeit: wenn man endlich (nach endloser Nachfummelei) ein Proggy hat, das rock-solid arbeitet - halt der Erfolg.
Das bezieht sich dabei natürlich auch auf die jeweilige Aufgabe! :-)
Ich habe an Beschlagssystemen gearbeitet, bei denen auch die ganze Ermittlung auseinanderfliegen kann, wenn man einen Fehler macht. Leider habe ich diese nicht geschrieben und leider fangen die Tests nicht alles ab. :-)
Aber klar, im optimalsten Falle ist der Programmcode organisiert und leicht erweiterbar! :-)