Ich hab ne Idee
- Und Programmier sie.

^^ Ich hab da keine großen Vorbereitungen.

Also wenn ich eine Idee habe, dann mache ich den Computer an, VS auf, und dann einfach drauf los programmieren. Wenn ich alles vorplanen würde, dann hättet ihr bald einen neuen GeckoFX browser im Showroom .
Was gibt es da für Rituale? Außer villeicht die, das ich im Sommer lieber am Strand bin, als am Schreibtisch...

Wenn ich ne Idee hab notieren (im Unterricht wird schon mal die Form skizziert und einige Snippets ) und sobald ich wieder vor VS sitzte kommt noch für mich die Entscheidung VC#(XNA) oder VB(kein XNA) und dann gehts auch schon los. Dann kommen Probleme, Projekte werden mehrmals neu aufgelegt um neue Strukturen zu versuchen. Joa, irgendwie so.

Also bei mir ist das so... das ich mir erstmal allerlei Gedanken mache und diese im Hirn zwischen parke.
Dann geht es auch schon los, mein Visual Studio Projekt Ordner wird vermüllt indem ich erstmal ausprobiere, ob das auch Sinn macht, ob es für mich Realistisch ist.
Tja, und wenn ich dann 20 Projekt Mappen geöffnet habe wo nur Müll drinnen ist, geht es auch schon mit dem Hauptprojekt los.

Wenn es kleinere Projekte sind, wird einfach drauf los geschrieben.
LG.L

Bei kleineren "Fun"-Projekten plane ich eig. gar nicht
Ich schreib einfach drauf los

Wenn es um größere Aufträge geht, dann probiere ich einige Zeit herum und taste mich an die Funktion ran und sehe ob die Lösung akzeptabel ist oder ob ich umdenken muss
Sobald ich weiß, wie ich den Auftrag genau bewältige, plane ich sogut wie alles (Wie sollen die Variablen heißen? Welche Funktionen/Subs brauche ich? Ggf. wie und wo speichere ich Daten? usw.)




Mfg.
SAR

Wenn ich eine Idee habe, starte ich erstmal ein neues Projekt, setze dann alles um, achte nur darauf, dass es auch funktioniert. Sieht meistens unsauber aus und vom GUI will ich gar nicht erst reden. Wenn ich damit fertig bin, erstelle ich nochmal ein neues Projekt, ordne erstmal alles schön an und übertrage dann in einzelnen Schritten den Code und verbessere ihn.

Hi,

ohne vernünftige Vorbereitung geht nix (außer bei Mini- oder Testprojekten)
- Funktionsumfang durchdenken (Pflichtenheft) und notieren
- Programmstruktur planen (dafür ein paar kleine Einzeltests)
- Zeitaufwand schätzen und Angebot erstellen (bei Bedarf)
- Repository einrichten, evtl. BugTracking-Projekt einrichten, Projekt anlegen
- bei großen Projekten Arbeit auf einzelne Mitarbeiter verteilen
- programmieren (70% davon im Kopf, 30% in Code umsetzen)
- einzelne Teile zusammenführen
- ausführliche Tests
- Beta an Kunden ausliefern
- Fehlerbereinigung und Release ausliefern

Die ganzen vorbereitenden Arbeiten mache ich meist im Büro am Schreibtisch oder am interaktiven Whiteboard, teilweise auch mit dem Kunden (sofern vorhanden) zusammen. Dabei läuft eigentlich immer ein Radiostream. Die eigentliche Programmierung, mache ich meist unterwegs bzw. das Umsetzen in Code dann im HomeOffice oder bei wieder im Büro.


bye ...

LaMa5.

Kommt drauf an. Privat programmiere ich eigentlich recht wenig, weil ich nach Feierabend kaum Lust dazu habe, und meine Zeit lieber anderen Hobbys widme.
Wenn ich aber privat etwas mache, dann mache ich mir zu meiner Idee erst ein mal ein paar Stichworte. Damit mache ich gleichzeitig eine Art Brainstorming. So fallen einem schnell weitere interessante Funktionen aber auch mögliche Probleme ein.
Wenn ich eine Datenbankapplikation mache, dann schreibe ich mir auch schon die Struktur der Datenbank auf Papier auf.
Jedes Mal, wenn mir zwischendurch irgendetwas einfällt, dann schreibe ich das zu meinen Stichworten um es nicht zu vergessen.

Habe ich vor eine Technologie zu nutzen, dann informiere ich mich im Vorfeld, ob sie geeignet ist, und wie man sei ungefähr nutzt. Unter Umständen wird ein „einfacher“ Prototyp erstellt, an dem ich die Technologie ausprobiere, bevor es ans Eingemachte geht.

Und dann geht es auch schon los.

Ich bin kein Freund von „Ich mach mal 20 Projekte, irgendwas wird schon dabei sein.“. Dafür habe ich auch gar keine Zeit. Es ist einfacher etwas zu machen, wenn man weiß, wo man hin will, und wie der Weg zumindest grob aussieht.

Aber UML-Diagramme und Ähnliches erstelle ich nicht.

Also bei mir ist es so bei meinen Programmen.
- Idee im Kopf aufbauen.
- Eine Skizze in meine Blöcke zeichnen (Im Unterricht oder am Schreibtisch)
- Alle nötigen Funktionen und weiteres aufzählen.
- Zeitaufwand schätzen und alles aufteilen.
- Grunddesigns in Photoshop erstellen.
- Mich an Visual Basic setzen und etwas programmieren.
- Die erste Beta testen und testen lassen.
- Fehler beheben und Release veröffentlichen.

Vorgehensweise bei Webseiten.
- Ideen sammeln von anderen Seiten
- Meine Ideen in meinen Milimeterblock zeichnen mit allen Maßen (Pixel)
- Mich an Dreamweaver setzen und nfangen zu skripten.
- Wen es mir gefällt, auf meinen Server Hochladen.

Gruß, Marin

Im Betrieb ist die Vorgehensweise eigentlich ziemlich strikt vorgegeben.

Privat nutze ich meist Mindmaps zur Planung und Vorbereitung. Die Software "FreeMind" ist da empfehlenswert.
Da pack ich dann alles rein, was mit dem Projekt zu tun hat: evtl. Datenbank mit Tabellen und Feldern, geplante Funktionalitäten, GUI / Formulare usw.
Bisher hab ich privat nur "one man show"-Projekte realisiert, von daher entfallen Groupware, SVN-Repository oder dergleichen.

Ich bin kein Freund von "Erst alles planen, dann alles programmieren". Von daher fang ich mit dem Programmieren meist auch direkt an.
Das Projekt selbst und die Mindmap laufen dann parallel. Es kommen immer mal wieder Ideen hinzu oder werden abgeändert. Auch Bugs und deren Lösung halte ich in der Mindmap fest.
Fertige Module oder Funktionen bekommen in der Mindmap ein grünes Häkchen. Neue Ideen haben einen Stern, Bugs einen Rotstift. So hab ich durchgängig in allen Mindmaps etwa das gleiche Schema.

Wenn ich was aus Büchern brauche, greif ich entweder ins Bücherregal oder suche in meiner eBook-Sammlung. Die openbooks von Galileo Computing nutze ich auch sehr oft. Hinzu kommt natürlich Google als meine Startseite im Browser. Musik läuft bei mir immer. Entweder irgendwelche Alben oder ein Radiostream aus der Kategorie "Hard Rock / Metal" in iTunes. Das sind derzeit meist Kink Aardschok (Holland) oder La Grosse Radio Metal (Frankreich).

Hi,

Fonsi schrieb:

Bisher hab ich privat nur "one man show"-Projekte realisiert, von daher entfallen Groupware, SVN-Repository oder dergleichen.

Auch bei OneManShow-Projekten macht ein Versionskontrollsystem durchaus Sinn. Man kann beispielsweise mit wenigen Klicks zu einer vorherigen Version zurückspringen, falls mal etwas nicht so funzt wie es sollte. Oder man kann jederzeit nachvollziehen, mit welcher Version sind welche Features hinzugekommen bzw. welche Bugs wurden gefixt, was für spätere Fehlermeldungen sehr sinnvoll ist.


bye ...

LaMa5.

Klar, auch wenn man alleine programmiert, kann ein SVN sinn machen. Ich hatte bisher aber meist überschaubare Projekte, da hab ich vor größeren Änderungen den gesamten Projektordner von Hand zu Fuß gesichert.

Ich will mich jetzt aber mal an ein größeres Projekt mit mehreren Leuten wagen, wo dann auch ne Groupware und ein SVN-Repository zum Einsatz kommen. Nur leider ists wohl garnicht so einfach, interessierte volljährige Leute zu finden.

Ich halte von Planung auch nicht viel, außer im Job wo es notwenig ist.

Aber für meine Projekte, klein oder Umfangreich, programmiere ich eigentlich immer direkt drauf los, ich habe eine Idee im Kopf und versuche sie so gut wie möglich umzusetzten.
Wenn die Funktionalität hergestellt ist und ich mit dem Code noch nicht zufrieden bin lege ich ein neues Projekt an wo ich dann den Code optimiere, was natürlich schneller geht da ich große Codestücke aus dem alten Projekt verwenden kann.
Diese Vorgehensweise mache ich sowohl in VB als auch in PHP so und kam auch noch niemals einen Punkt wo mir das im Wege stand.

Ich war schon immer ein "Typ ohne Plan" also auch wenn ich früher daheim im Bastelkeller etwas gebastelt habe, immer einfach drauf los und was nicht passt wurde passend gemacht und selbst das war noch schneller als sich im vorfeld darüber gedanken zu machen und zu Planen, Teile Berechnen und Schablonen zu erstellen oder sowas.

Als erstes überlege ich mir den aufbau und die funktionen, dann was ich alles dafür brauche(Klassen etc).
Dann in vs setzte ich mich an das eigentliche Projekt.
Als erstes mache ich mich an das/die Model(e) (Die Programmlogik, einzelne klassen die unabhängig vom view arbeiten, und so auch in anderen projekten verwendet werden können) das bedeutet ich mache die funktionen alle vorher, dann kann ich später so viel ich will an dem view rumspielen ohne denken zu müssen: "Man langsam sollte ich mich um die Funktionen kümmern"
dann mache ich dann meistens den view(Form, design, whatever)
Am ende gehe ich an den Controler teil, damit wende ich die Modele auf die views an, Modele und views mache ich dann meistens so dass ich sie ohne viel umschreiben in andere Projekte importieren kann, und der controller wird dann individuell auf model und view angepasst.

Dodo schrieb:

…selbst das war noch schneller als sich im vorfeld darüber gedanken zu machen und zu Planen, Teile Berechnen und Schablonen zu erstellen oder sowas.

So denken leider auch viele Projektleiter in kleinen Unternehmen.
Es kommt auch immer auf den Umfang (Was ist „klein“?) und die Art an. Habe schon an einigen Projekten mitgearbeitet, die anfangs unzureichend geplant wurden. Irgendwann erreicht man einen kritischen Punkt (Projektgröße, Anzahl der Installationen, Dauer seit Release, …), an dem man nicht einfach große Umbauten vornahmen oder mal eben komplett von neu anfangen kann. Je nach Projektart ist dieser kritische Punkt schnell erreicht (schlechtes ein Datenbank-Model macht sich ganz schnell bemerkbar, lässt sich aber nur schwer korrigieren, wenn die Software mal im Umlauf ist).
Und dann bastelt man immer so schiefe Lösungen um die „Altlasten“ rum, ach dem Motto „Hauptsache funktioniert irgendwie, und nach mir die Sinnflut“. Daraus resultieren natürlich oft Fehler (auch Indirekte), was wieder zur Aufwand und noch mehr Altlasten führt.

Aus meiner Erfahrung spart man selten Zeit, wenn man die Planung weglässt. Denn die Zeit, die man einspart, muss an hinten, oft um ein vielfaches länger, wieder reinstecken, wenn man blind rumprobiert, Bugs sucht und behebt.
Es erscheint einem aber so, weil Planung lästig ist, und man mit dem programmieren meist relativ flott „fertig“ ist, und das mehr Spaß macht, als Planen. Man unterschlägt dann oft den Aufwand, der dann hinten dran kommt.

Bei mir läuft's so:

1. Idee einfallen lassen
   
2. Überlegen, wie sich diese umsetzten lässt und ob sie überhaupt sinnvoll ist
   
3. Einzelne (höchst wahrscheinlich benötigte) Klassen schoneinmal im Kopf planen
   
4. Bevor der Rechner angemacht wird -> Bestand an Kippen sichern (Minimum 10 Stück)
   
5. Rechner an, Techno-/Trance-/House-/Reggae-/Metal- oder Rock-Musik anschalten, Projekt anlegen
   
6. Die wichtigesten Klassen direkt anlegen und in einem runterschreiben
   
7. GUI entwickeln -> Meistens nur das nötigste, da für mich das GUI wirklich nur eine visuelle Schnittstelle und keinen Tempel darstellt...
   
8. "Hauptprogramm" entwickeln (Form inkl. Events): Einrichten, Runterschreiben
   
9. Testen...
   
10. Mitten drin die wichtigsten Grafiken erstellen
    

Und wenn ich dann mal einen Abend intensivster Arbeit abgeschlossen hab und der nächste schon wieder anfängt, wird im Code einfach wild umher geschaut, was noch verbessert werden muss, was verbessert werden kann, was ich hinzufügen kann...

MfG,
X-Zat / Momo

PS: Am liebsten vor dem eigenen Schreibtisch von 15:00-18:00 oder 20:00-01:00 und mit meiner Katze - Ihre "Lieblings"-Positionen zum nerven: abwechselnd auf der Tastatur, halb in meinem Gesicht oder komplett vor dem Monitor ô.o

@GambaJo: Wie gesagt in einem Beruf ist das wieder eine andere Sache, da Plane ich auch, da es dort u.a. ja auch einen gewissen Zeitrahmen gibt den man auch einhalten muss. Aber bei privaten Projekten wo kein Zeitdruck oder Releasedate gesetzt ist kann man ja solange rumwurschteln wie man möchte.

Da ich jedoch nur im privaten Bereich programmiere bzw. was ich Nebengewerblich an Webprogrammierung mache, reicht es ohne Planung.

Dodo schrieb:

@GambaJo: Wie gesagt in einem Beruf ist das wieder eine andere Sache, da Plane ich auch, da es dort u.a. ja auch einen gewissen Zeitrahmen gibt den man auch einhalten muss. Aber bei privaten Projekten wo kein Zeitdruck oder Releasedate gesetzt ist kann man ja solange rumwurschteln wie man möchte.

So siehts bei mir auch aus, nur dass ich momentan nach 10 Std. keine Lust mehr habe privat weiter zu machen...

@Dodo: Das war auch eher allgemein gedacht, als auf dich bezogen.

Ich kenne das halt aus kleinen Unternehmen, dass wenn man da als Entwickler in seine Zeitschätzung die Planung mit einrechnet, die Jungs oft vom Hocker fallen, sich dann aber wundern, wenn hinterher das Telefon im Support nicht still steht.

Privat plane ich nicht sehr detailliert, aber ich mache es, denn dann hat man einen Überblick, was noch offen ist. Wenn man Licht am Ende des Tunnels sieht, dann kann man sich eher motivieren sich nach Feierabend noch dran zu setzen.

Wenn man kein Schüler, Student oder Rentner ist, jeden Tag stundenlang entwickelt, andere Hobbys und Freundin/Frau (vielleicht sogar Kinder) hat, dann muss man schon gut mit seiner Freizeit haushalten. Sonst fängt man ein Projekt an, kommt vielleicht alle paar tage oder Wochen mal dazu etwas zu machen, und vergisst natürlich, wo man dran war, was man machen wollte, usw. Dann stirbt das Projekt eh irgendwann.