Alles genau überlegen oder einfach mal drauf los programmieren?
-
achja, was ich noch vergessen habe.
lass dich da nicht von irgenwelchen plan-freaks belabern, dass du alles komplett durchplanen musst. Das ist der falsche weg.
Auch im RL, ganz neben bei bemerkt.
-
Man sollte schon immer
1. denken
2. planen
3. rumcodenNur der Umfang ist variabel und sollte jeder an seinen Fähigkeiten und dem Umfang des Projektes/der Mitarbeiteranzahl fest machen.
Erstmal nachdenken was willst du haben und was soll das Programm später können, das sollte UNBEDINBGT sein, sonst musst du unter Umständen den späteren Quellcode komplett umschreiben weil du das letzte gewollte Feature nicht mehr rein bekommst.
Hier gibts auch diverse Techniken wie Brainstorming etc, aber die Hauptsache ist ein intensives Nachdenken wie das Ergebnis nachher aussehen soll und was es können soll(evtl mit mehreren und dann von Dritten, zB Endanwendern Feedback einholen ob das toll ist was du erdacht hast), denn in der Planungsphase sind Veränderungen am schnellsten zu machen(besser einen Satz schreiben und etwas streichen, als den Quellcode umrödeln).
Wenn es ein Kundenauftrag ist, ist das gewollte ja auch für die Kostenplanung nicht grad unwichtig.Beim Planen ist es halt die Kunst soviel zu planen wie nötig, aber nicht mehr.
Zu wenig führt nachher besonders bei mehreren Mitarbeitern oder Aufgaben die man das erste Mal angeht zu Chaos, weil nix zusammenpasst.
Zu viel führt zu verdammt viel verschwendeter Zeit, in der man Offensichtlichkeiten aufschreibt.
Wenn ich etwas programmiere fällt mir meistens spontan ein Weg ein, es zu machen und ich weiß auch ganz genau, ob und wo es dabei Probleme geben könnte.
Wenn ich da auf "problemlos" komme, brauch ich auch nicht zu planen, bei sowas habe ich immer recht :p
Bestenfalls nochmal kurz zu überlegen ob der erdachte weg der Beste ist.
Aber "Regel" is halt, wenn du weißt, du kannst den jeweiligen Teilbereich von Anfang bis Ende der Programmierung ohne Planung problemlos überblicken, dann brauchst du da auch nicht viel planen da.Naja und programmieren sollte klar sein, ohne gehts nicht, wobei obiges eigentlich das ist wofür man in einer Firma wesentlich besser bezahlt wird und es gibt nichts langweiligeres als ein von anderen voll durchgeplantes Projekt nur umzusetzen :p
-
IPERKA!
Informieren
Planen
Entscheiden
Realisieren (hier tut man dann mal was)
Kontrollieren
Auswerten=> Saubere Arbeit
Bei Hobbies würd ich mir das aber dreimal überlegen
-
dreaddy schrieb:
Naja und programmieren sollte klar sein, ohne gehts nicht, wobei obiges eigentlich das ist wofür man in einer Firma wesentlich besser bezahlt wird und es gibt nichts langweiligeres als ein von anderen voll durchgeplantes Projekt nur umzusetzen :p
So ein Projekt will ich mal sehen! Ich kann mir nicht vorstellen, dass man ein größeres Projekt so planen kann, dass man es ohne Änderungen des Plans umsetzen kann. Irgendwann kommt immer was an das keiner gedacht hat,
-
Sicher, ist Theorie und bei perfekter vorheriger Planung und fest definierten Projektzielen auch möglich, halt der "Optimalfall".
1-2 mal passiert sowas dann meistens doch, weil am Markt plötzlich irgendwas modern geworden ist was unbedingt rein muss oder man eben doch was vergessen hat.
Aber besser 1-2 mal als 10-20 mal ;>
-
Moin
Die kunst der planung ist es auch unvorhergesehenes mit einzuplanen und so kompensieren zu können. Was bringt es wenn schon während der entwicklungsfase eines projektes sovile änderungen reinkommen, das der code bereits bei abgabe an den kunden nicht mehr wartbar ist.
ich kann mich da nur an den schweineberg erinnern, der die kosten eines software projektes im zeitverlauf dargestellt hat. Sa ungefähr so aus wie eine Parabel dritten grades.
zum zeitpunkt null haben wir auch null kosten, die bei vorschreitender Projektzeit auch zunehmen, Planungskosten, entwicklungskosten. ( erst 2 entwickler dann 10 )diese kosten ereichen kurz vor markteinführung ihren höhepunkt, und flachen dann langsamer oder auch schneller ab. In dieser zeit ist der meiste aufwand im bereich support und kundenbetreuung.
Danach kommt eine art talsole, das Projekt kostet nur noch wenig geld, da nur weing änderungen, neue anforderungen eingearbeitet werden müssen, und die aufgrund der "guten" Planung einfach zu integrieren sind.
Anschliesend steigen die Kosten wieder, da implementierung neuer Anforderungen, Fehlerbeseitigungen immer komplizierter werden. Der code wird langsam nicht mehr wartbar, da Anforderungen nicht mit dem implementierten software konzept vereinbar sind. Im Code mitlerweile so vile triks und kniffe enthält um die anforderungen fast nicht mehr implementiert bekommt. Ab dann kommt ein zeitpunkt an dem die änderung dermassen teuer wird, das eine neuimplementierung des ganzen Projektes billiger, wirtschaftlicher und unter umständen auch stabiler ist als ein nachtägliches "reinwürgen"
Je länger es dauert bis das ende des software zyklusses ereicht ist desto besser wurde am anfang des Projektes geplat. Die grundlage dafür wird am anfang eines projektes festgelegt. Nachträgliches gegensteuern ist nur schwer möglich und meist extrem teuer. ( ich glaub es waren die ersten 10% der kosten, die über die lebensdauer eines Projektes entscheiden )
gruss
-
volkard schrieb:
was prof84 macht, liegt nicht nur an eventuellen projektgrößen, sondern auch daran, was er kann. und was das ist, erkennt man schnell.
internet-surfen und googlen?
-
Bei Kleinprojekten (<5000 LoC, 50 Klassen) kann man eigentlich "freihändig" anfangen. Bei größeren Projekten, die über Monate/Jahre hingehen, und mehrere Leute dran arbeiten, die u.U. auch wechseln, ist eine Planung von Nöten. Irgendwann kommt man sowieso in Refactoring-Phasen, in denen man größere Teile der Software umbaut. Bei guter Planung ist das seltener notwendig. Bei schlechter Planung ist man dann nur noch mit Refactoring beschäftigt, sodaß dann nix mehr weitergeht.
Tatsache ist, daß komplexe Software zu produzieren unheimlich aufwendig ist.
Im vorherein aufgestellte Zeitpläne kann man gleich mit zwei multiplizieren und werden trotzdem nicht eingehalten. So manches Team bestehend aus 5 Entwicklern bringt unter Umständen mehr weiter, als ein Moloch mit 50 Entwicklern. Alles eine Sache der Planung, Entwicklungsmethode (Waterfall, Agile Development, Extreme Programming ...) und vorallem Motivation der Teammitglieder.MfG, Michael
... beruflich in einem größeren Projekt (Medizinische Software, 6 Entwickler, ca. 10 Mannjahre investiert, Java, Agile Development) eingebunden.
-
hallo ihr.
Trotzdem, ich bleibe dabei. Planen ist keine Freikarte für perfekten Code. Je mehr man beim Planen "hängen bleibt", um so mehr Dinge fallen einem ein, die verbessert werden können. Das ist zwar schön und gut, passiert aber beim Drauflosprogrammieren genauso. Beim planen (beim Programmieren meistens auch) legt man bloß irgendwann fest, dass nichts mehr neues erfunden werden soll, weil man da nicht mehr weiter kommt.
Ein Problem vom ausgiebigen (== langdauernden) Planen ist, dass die Hemmschwelle vom neues anzufangen, wenn man merkt dass man was falsches zusammengeplant hat, um einiges höher, als beim Drauflosprogrammieren.das gilt natürlich für den Hobbybereich. Ich denke mal, dass der Threadstarter, sich auch hobbymäßig mit der Programmierung beschäftigt. Bei Hobbys a) geht es *nicht* ums Geld (außer Stromkosten) b) die zeit ist *nicht* begrenzt (außer durch den tod)
-
Es spricht auch nix dagegen sich erstmal hinzusetzen und nen prototyp zu hacken. Und die erkenntnisse aus diesem Prozess dann in die Planung einzubeziehen...