Alles genau überlegen oder einfach mal drauf los programmieren?
-
Kommt auf die PROJEKTDIMENSION an!
Kommt auf den Architekt/Manager an!Also wenn Du schon so fragst, ist eine Bottom-Up Entwicklung (testgetrieben, Prototyping) für Dich wahrscheinlich das Beste.
Und dann ständiges Refactoring ... Patterns ankucken, anpassen, implentieren, refactoring, Testen, ...Studium <-> Praxisrefektion!³³
Ich kann in meiner Liga (10M - 1G€) natürlich nicht so verfahren.
Also auch eine wichtige Frage: Was willst Du mit den Code erreichen?
-
Was ist denn 1G für eine Maßeinheit wenn es um Geld geht? noch nie gelesen
-
steht für 10^9. ist aber falsch hier. wirtschaftler kennen sowas nicht oder meiden es und schreiben 1 Mrd €. was prof84 macht, liegt nicht nur an eventuellen projektgrößen, sondern auch daran, was er kann. und was das ist, erkennt man schnell.
-
-
volkard schrieb:
steht für 10^9. ist aber falsch hier. wirtschaftler kennen sowas nicht oder meiden es und schreiben 1 Mrd €. was prof84 macht, liegt nicht nur an eventuellen projektgrößen, sondern auch daran, was er kann. und was das ist, erkennt man schnell.
-
volkard schrieb:
steht für 10^9.
2^30
-
Wenn man keine Ahnung hab...
2^30 waere Gi.
-
also bei mir ist es eher das einfach drauf loslegen. nur selten mache ich einen plan wie ich etwas programmiere. und wenn ich ein plan mache dann nicht in uml oder pap (für assembler) oder ähnliche sachen sonder schmiere mir kurz auf ein blatt papier zusammen was das projekt alles machen und können soll. dies ist aber eher ein merkzettel damit ich die ideen die ich einbauen möchte nicht vergesse.
selbst bei dem schon 3jährigen project das ich mache habe ich und mache es immer noch so das ich einfach drauf los hacke und das sehe was ich noch verbessern oder einfügen kann wobei mir wieder die merkzettel helfen.
jedoch wenn man ein projekt mit mehreren leuten macht, ist, glaube ich, eine uml oder ähnliches nicht verkehrt.
-
außer, wenn für dich so einiges auf dem spiel steht, wie knappe termine, weil jede verschiebung etwas (auch etwas mehr) geld kostet, so ist es besser zu planen. Im hobby-umfeld, solltest du einfach drauf los programmierern.
ich wiederhole: "einfach drauf los programmieren".
Warum?
was bringt es dir total etwas durchzuplanen. du hast alle zeit der welt. du kannst durch die fehler, die du beim drauflosprogrammieren machst, so einiges mehr lernen, als wenn du dich zunächst mal dich für paar jahre mit nem bleistift, radiergumme und tausend seiten blatt hinhost, und zeichnest.
du hast da nichts greifbaren, woran du dich erfreuen kannst, außer papieriges mit gekritzel. das praktische verschiebst du auf immer später, bis die motivation am ende ist.
wie kann man so anfangen zu programmieren?
programmiere einfach drauf los. so lernst du einiges mehr.ich denke auch mal dass du nicht erst struktogramme erstellt hast, als du vor hattest gehen zu lernen. (ich gehe mal davon aus, dass struktogramme zu deiner zeit etwas total cooles waren, denn ich weiß nicht wie das uml-äquivalent dazu heißt, falls du jüngeren baujahres sein solltest).
-
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...