Alles genau überlegen oder einfach mal drauf los programmieren?

[Gast]

Früher hab ich mir viel bis ins Detail überlegt, aber jetzt mach ich es oft so, dass ich einfach mal ein paar Klassen programmiere ohne jedes Detail genau zu planen und wenn man irgendwelche Patterns verwendet, dann passt das ganze auch gut zusammen. Vorallem bei UIs geht das ganz gut.

Wie sieht das bei euch aus? Wie genau plant ihr?

[kloffy]

In der Theorie: erst alles genau überlegen.
In der Praxis: einfach mal drauf los.

So ist es zumindest in meiner Erfahrung als Programmierer.

Edit: Kann man aber generell nicht sagen, kommt auf Art und Umfang des Projekts an.

[ethrandil]

Edit: Kann man aber generell nicht sagen, kommt auf Art und Umfang des Projekts an.
Dito.

- eth

[Gast]

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?

[Marscel]

Meistens so, dass aus ein bisschen drauf los Programmieren und ein paar Tests dann ein kleines Projekt wird, das ein bisschen weitergeplant wird.

Ernsthafte Probleme (= Schreiben bis zur Unbrauchbarkeit) hab ich dadurch noch nicht bekommen.

[Trap]

Planen kann man nur, wenn man weiß, was auf einen zukommt. Bei den meisten Softwareprojekten werden die Anforderungen nur in Reaktion auf frühe Versionen der Software genauer definiert, anfangs ist vieles wichtige noch offen gelassen. Von "Fertige Software eintippen"-Projekten hab ich noch nicht gehört.

Die Arbeit an der Software kann man planen, die Software und Termine für ihre Fertigstellung eher nicht.

[Gast]

Die Kompetenz liegt in der Planung.

Programmierung ist ja quasi durch die Syntax bzw. Programmiermodelle- und techniken vorgegeben, aber das zusammen zu bringen und sinnvoll umzusetzen ist eine Herausforderung.

Trap, es gibt durchaus Firmen die oft Fertiglösungen herstellen. Bestes Beispiel ist eine Firma in meiner Gegend, die für kleine bis mittelständische Betriebe Webpräsenzen erstellt. Es wird mehr oder weniger ein fertiges Template nur auf die Bedürfnisse umgestaltet (und auf diese Art und Weise quasi ständig dasselbe Produkt verkauft).
Entwicklung selbst ist bei denen tendenziell von untergeordneter Bedeutung.

[RMC]

Wie so oft: die Mischung machts!

Ohne irgendeine Vorüberlegung gemacht zu haben ist genauso blöd wie das Programm bis zur Unkenntlichkeit theoretisch zu zerlegen (Wohlmöglich noch im Top-Down Design).

[Trap]

Trap, es gibt durchaus Firmen die oft Fertiglösungen herstellen. Bestes Beispiel ist eine Firma in meiner Gegend, die für kleine bis mittelständische Betriebe Webpräsenzen erstellt. Es wird mehr oder weniger ein fertiges Template nur auf die Bedürfnisse umgestaltet (und auf diese Art und Weise quasi ständig dasselbe Produkt verkauft).
Entwicklung selbst ist bei denen tendenziell von untergeordneter Bedeutung.
Richtig, das halte ich übrigens für ein sehr sinnvolles Geschäftsmodell, Komponenten oder Frameworks verkaufen ist schwierig, immer wieder mit eigenem Framework eine fertiges Produkt entwickeln und das zu verkaufen ist einfacher.

Solche Leute wissen nach mehreren ähnlichen Aufträgen genau genug welche Software am Ende rauskommt, trotzdem machen sie kein "fertige Software eintippen", die Software haben sie ja schon und sie werden sie wohl kaum für jedes Projekt neu schreiben.

Fertige Software eintippen kann ich mir nur in ganz wenigen Umständen vorstellen, wenn man eine Gruppe Leute abwirbt und ähnliche Software haben möchte wie sie vorher entwickelt haben zum Beispiel ;)
"Fertige Software eintippen" ist ja nur möglich, wenn man das komplette Know-How hat, aber keine Software die das implementiert.

[maximAL]

schrittweise planung mit divide and conquer.

[Monger]

Ich glaube, es hängt vorallem davon ab, ob man weiß was man tut. Damit meine ich: wenn Software-Entwicklung gleichzeitig ein Stück weit Forschung ist, wird das mit der Planung naturgemäß nix.

So was ich mitgekriegt habe, haben sich die modernen Konzepte ohnehin schon von dem voll durchgeplanten und voll kontrollierbarem Modell verabschiedet. Die versuchen nur noch, das Risiko von wirklich fatalen Fehlschlägen möglichst niedrig zu halten.

Das heißt aber nicht, dass man Code nur so hinschludern darf. Syntaktisch richtigen Code kriegt inzwischen jeder hin, aber "guten" Code, mit dem man auch in zwei Jahren noch was anfangen kann, das erfordert schon ein gutes Stück Weitsichtigkeit. Je größer ein Projekt wird, desto erbarmungsloser rächen sich solche Kleinigkeiten.

[Demirug]

Monger, der Sammelbegriff dafür ist Agile Softwareentwicklung.

[Jesus]

Ich denke auch hier prallen 2 Welten aufeinander. Natürlich ist einfach drauf los irgendwie blöd, aber anders wird man einfach viele Probleme auf die man anders im Vorfeld vorbereitet sein müsste nie haben die kommen dann so oder so auf einen zu.

Ich bau mir dabei meist erstmal ein "Gerüst" auf (=reinhacken), ohne gross nachzudenken, aber um mir möglichst viel Raum für Änderungen zu lassen (die ganz sicher kommen) und dann folgt die feinarbeit. Also quasi erst GUI dann Code, grob gesagt :)

Man aber kann unmöglich alles planen, leider wollen das die Vorgesetzten aber immer so :)

[Arokh]

ganz früher habe ich immer einfach drauf los programmiert, in der Regel so daß ich ein paar Zeilen geschrieben habe, die irgendwo im Programm untergebracht sein sollten, und das restliche Progamm dann irgendwie drumherum gestrickt. Besonders gerne hab ich damals auch globale Variablen benutzt ;)
Struktogramme? Schnittstellen? Parameter? Was soll der Trödel, war meine damalige Denkweise.

Später dann, nachdem ich OOP gelernt hatte, ging ich dazu über, als erstes meine Klassen zu basteln - das Klassenkonzept als Entwurfswerkzeug sozusagen. Beim Implementieren der Methoden fiel ich dann aber doch recht häufig auf meine ältere Verfahrensweise zurück: erste eine Zeile geschrieben, die auf jeden Fall in der Methode vorkommen sollte, und dann die übrige Methode drum herum gebastelt.
Besonders auf der Arbeit, wo das Klassengerüst schon durch die Architektur des Programms, das ich am weiterentwickeln war, festgelegt war, passierte mir das sehr oft.

In jüngster Zeit schließlich habe ich mir endlich das angewöhnt, was mir von allen Seiten immer schon gepredigt wurde - ein Programmentwurf mit Diagrammen und Zeichnungen. Ich bin halt einfach dahintergestiegen, daß das die Wartung eines Programmes drastisch vereinfacht. Bis ins letzte Detail gehen meine Diagramme dabei aber auch nicht - jedenfalls nicht sofort. Wichtig ist die Interaktion zwischen den Entwicklungsstadien: erst male ich meine Diagramme relativ grobschnittig, implementiere den Programmcode entsprechend, und für Verfeinerungen male ich dann wieder Diagramme. Oder ändere die Diagramme nachträglich ab, wenn sich herausstellt, daß das Programm so wie anfänglich gedacht nicht implementierbar ist.

[TheFallenAngel]

ganz verschieden....

hängt in erster linie vom projektumfang, dessen komplexität, anforderungen, ... ab wie ich programmiere bzw. programmieren zu habe

kleinere tools welche ich für mich selbst schreibe sind aber meist java-hacks, produziert ohne mir viel zu überlegen ^^

cya

[Gast]

Kopierer... http://www.c-plusplus.de/forum/viewtopic-var-t-is-160855.html