![[HaBo]](/styles/default/logoklein.png){kind=small}
Wie programmiert ihr?
- Themenstarter bad_alloc
- Beginndatum
Ich versuche mir immer einen genauen Plan zu machen und mich in die spätere Situation zu versetzen, um möglichst viele Probleme oder gar möglich Designprobleme gleich im voraus zu erkennen und dann zu vermeiden.
Allerdings schaffe ich das nie ganz, meist nur bis zu einem bestimmten Zeitpunkt. Wenn ich dann nicht mit dem Programmieren anfange, werde ich wahnsinnig.
Scheinbar geht es hier den meisten so. Hätte ich nicht gedacht.
Allerdings schaffe ich das nie ganz, meist nur bis zu einem bestimmten Zeitpunkt. Wenn ich dann nicht mit dem Programmieren anfange, werde ich wahnsinnig.
Scheinbar geht es hier den meisten so. Hätte ich nicht gedacht.
Also ich beginne einfach mal! Wenn dann was nicht klappt und ich gar nicht mehr weiterkommen, so mach ich ein Strukdogramm um den überblick wieder zu bekommen und versuche das Problem erst mal auf Papier zu lösen...
Ich weiss ich würd mir viel Arbeit sparen, aber ich halte mich einfach nicht dran... Naja was solls!
Ich weiss ich würd mir viel Arbeit sparen, aber ich halte mich einfach nicht dran... Naja was solls!
Ich weiß nicht wie sein Zettel aussieht, aber nachdem was unser Infolehrer uns beigebracht hat, stehen dort die grundlegenden Schleifen, Prozeduren, etc drauf, auf die das Prog aufbaut. Bei mir sieht das aber alles sehr durcheinander aus und nicht so schön geordnet wie ers immer haben wollte. 
@:::Lük:::
Ich mache das eher in der Art eines Pflichtenheftes. Ich schreibe selten die einzelnen Prozeduren auf, das würde zu lange dauern. Ich schreibe auf, was das Ziel des ganzen ist, was dabei nicht rauskommen wird, und einzelne Teilschritte, an die ich mich, wie bei einer Checkliste, halten kann.
Das hat den Vorteil, dass ich das auch gleich dem Kunden geben kann, der es dann entweder absegnen oder ablehnen kann. Dabei stelle ich meistens auch schon fest, ob und wie es möglich ist, und erkenne Probleme und Schwachstellen im Vorfeld.
Leider lässt sich damit nicht immer alles im Vorfeld erschlagen. Kommt oft vor, dass ich dann ein Problem finde, wenn es ins Detail geht, welches ich bei der Planung übersehen habe, oder nicht sehen konnte. Aber in 95% aller Fälle lässt sich irgendeine Lösung finden.
Ich mache das eher in der Art eines Pflichtenheftes. Ich schreibe selten die einzelnen Prozeduren auf, das würde zu lange dauern. Ich schreibe auf, was das Ziel des ganzen ist, was dabei nicht rauskommen wird, und einzelne Teilschritte, an die ich mich, wie bei einer Checkliste, halten kann.
Das hat den Vorteil, dass ich das auch gleich dem Kunden geben kann, der es dann entweder absegnen oder ablehnen kann. Dabei stelle ich meistens auch schon fest, ob und wie es möglich ist, und erkenne Probleme und Schwachstellen im Vorfeld.
Leider lässt sich damit nicht immer alles im Vorfeld erschlagen. Kommt oft vor, dass ich dann ein Problem finde, wenn es ins Detail geht, welches ich bei der Planung übersehen habe, oder nicht sehen konnte. Aber in 95% aller Fälle lässt sich irgendeine Lösung finden.
naja bei größeren Projekten aufjeden fall strukturiert und geplant, UML lässt grüßen
bitmuncher
Senior-Nerd
Bei mir kommt es darauf an, was ich programmiere. Kleine Sachen, die man in 1-2 Stunden mal dahin tippt und die man nie wieder erweitern muss, wird nicht viel geplant. Bei Projekten, die ich auch in 1-2 Jahren noch weiterentwickeln muss, wird alles bis in's Detail geplant, UML-Diagramme entworfen, Versionsverwaltung verwendet usw.
bitmuncher
Senior-Nerd
Die bevorzugten UML-Editoren bitte in einem extra Thread klären, sonst ufert das hier wieder aus.
ich programmiere meistens einfach drauf los, bei größeren Projekten (so ab 500 zeilen Code in Java) mach ich mir gedanklich einen Plan und stricke dann eine Methode nach der anderen...
ist vielleicht nicht effektiv, aber so bleibt man flexibel *denk*
ist vielleicht nicht effektiv, aber so bleibt man flexibel *denk*
bei mir schaut's ebenfalls so aus, dass ich kleine Sachen einfach drauf los code,
je größer und universell einsetzbarer der Code jedoch werden soll, desto genauer plane ich - Checkliste über Funktionalitäten, UML-Diagramme, Struktogramme, Ablaufpläne, Datenbank-Strukturen - alles per Hand so mit Zettel und Stift, ganz ohne Computer (falls das noch jemand von euch kennt ;-) )
( Hintergrund ist einfach der, dass ich nen verdammt schwachen Akku hab und dann eben insbesondere Zugfahrten zur Software-Planung nutze
)
je größer und universell einsetzbarer der Code jedoch werden soll, desto genauer plane ich - Checkliste über Funktionalitäten, UML-Diagramme, Struktogramme, Ablaufpläne, Datenbank-Strukturen - alles per Hand so mit Zettel und Stift, ganz ohne Computer (falls das noch jemand von euch kennt ;-) )
( Hintergrund ist einfach der, dass ich nen verdammt schwachen Akku hab und dann eben insbesondere Zugfahrten zur Software-Planung nutze
)
Original von easteregg
und es kommt sowieso alles anders als ich das geplant hab
Das ist in den ersten Projekten tatsächlich so. Man sollte dann nach dem Projekt noch mal nachhalten, was anders gelaufen ist, und warum. So kann man für zukünftige Projekte lernen, und seine Planungen optimieren, sonst arbeitet man irgendwann unwirtschaftlich.
Also bei mir kommt es ganz darauf an, was es denn werden soll.
Eine C++ - OpenGL Application plane ich meist genauer, da die sonst wirklich extrem schwer zu durchblicken sind, wenn sie dann mal größer werden ( > 1500 zeilen ).
Bei vergleichbar großen PHP-Projekten fällts mir allerdings immer ein bisschen schwerer, das übersichtlich zu halten. Da muss ich entweder genauer planen oder später das ein oder andere Mal noch was umstrukturieren.
Kleine Projekte oder 'Projekte', in denen ich nur einige für mich neue Features von z.B. OpenGL ausprobieren will, plane ich nicht besonders, sondern programmiere einfach drauflos (meist auch alles in eine Datei, bis auf die Datei, in der mein opengl-framework liegt).
Eine C++ - OpenGL Application plane ich meist genauer, da die sonst wirklich extrem schwer zu durchblicken sind, wenn sie dann mal größer werden ( > 1500 zeilen ).
Bei vergleichbar großen PHP-Projekten fällts mir allerdings immer ein bisschen schwerer, das übersichtlich zu halten. Da muss ich entweder genauer planen oder später das ein oder andere Mal noch was umstrukturieren.
Kleine Projekte oder 'Projekte', in denen ich nur einige für mich neue Features von z.B. OpenGL ausprobieren will, plane ich nicht besonders, sondern programmiere einfach drauflos (meist auch alles in eine Datei, bis auf die Datei, in der mein opengl-framework liegt).