Wie plant ihr grosse Projekte?

[~down~]

Hi. Ich suche Techniken und Tipps, wie man größere Projekte sinnvoll planen kann. Z.B. damit man weiß, in welche Objekte man den Code unterteilt, damit man die Übersicht nicht verliert oder auch um die Motivation aufrecht zu erhalten.

Ich hab auch schonmal von sachen wie "OOA", "UML" oder irgendwelchen "Modellen" was gehört. Wäre nett, wenn mir jemand diese Begriffe erklären könnte (wenn sie denn wirklich sinnvoll sind und zum Thema passen).

Danke im Vorraus

[DFYX]

Kommt drauf an, welche Art von Projekten. Spiele plan ich üblicherweise mit Bleistift und Papier. Da wird erst mal alles, was die Story angeht lexikonartig aufgeschrieben. Kann schon mal passieren, dass ich erst nach 2 Jahren und an die hundert Seiten überhaupt anfang, zu programmieren.

Bei Anwendungen und kleineren Programmen (Meistens nur zum Üben) bau ich meistens alles so auf, dass es später reicht, einzelne Module auszutauschen, statt alles neu zu machen, wenn was schief läuft. Allerdings kann ich da nicht sagen, wie weit sich das bei großen Projekten bewährt, weil ich noch nie was wirklich großes allein bis zum Ende durchgezogen hab. Eine grobe Aufteilung sollte man aber natürlich immer im Hinterkopf behalten und Notizen oder Diagramme können da meistens nicht schaden, wobei letztere eher allgemein gehalten werden sollten, nicht so, wie in manchen Büchern gepredigt wird, wo jedes if und jede Schleife eingezeichnet ist. Eher nach Sinnabschnitten unterteilt.

[Ynnus]

Wie plant ihr grosse Projekte?

...

Man nenne mich einen Tor aber ich plane meine Projekte meist nie im Vorraus.
Soll heißen, wenn es zu Problemen kommt und ich merke, on-the-fly gibts nur Bugs und es wird nichts, nehm ich einen Zettel und Stift und plane dann, wie es zu realisieren wäre. Aber eben nur für einzelne keine Teilbereiche. Alles drum und dran nicht, das hab ich meist im Kopf oder kommt beim Denken und Machen dann.

Zu Sachen wie UML -> Das ist eine Sammlung von Regelungen wie bestimmte Dinge dargestellt werden. Ich weiß nicht genau in welchen Bereichen das alles gilt aber bezogen auf Objectorientierte Programmierung bestimmt die UML, wie Klassen und Objekte gemalt werden. ALso vorher auf Zettel aufgemalt und wie Objekte verbunden werden mit Klassen und solche Sachen. Google mal nach UML Bildersuche, da findest du einige Beispielskizzen.

[Crash-Override]

Ich plane eigentlich nie. Ich nehm mir einfach erst mal ein Ziel das realistisch erscheint, also wenn ich einen Map-Editor schreibe dann eben das Ein-Layer-Mappen, dann Öffnen und Speichern, Mehrere Ebenen usw. Ab und zu plan ich aber auch vor, so deklamiere ich z.B. glecih am Anfang ein Layer für mehrere Ebenen usw.

[Manuel]

Hm... man mag es nicht glauben, aber selbst ich unter QBasic(!) plane manchmal was im Voraus . Für kleinere Projekte hab' ich für Gewöhnlich ein paar Hintergedanken im Kopf, aber bei richtig großen Projekten plane ich schon ein wenig voraus. Ein Beispiel bei einem Spiel: Ich schreibe erst IMMER einen Level-Editor dazu, bevor ich überhaupt auf die Idee komme, die Engine zu schreiben^^. Alles andere (Story etc... in Extremfällen sogar das Genre, ist mir schonmal passiert^^) schreibe ich erst, wenn ein Level-Editor fertig ist^^. Dabei mache ich mir oft Zahlennotizen, also Notizen, welche Zahl in einer dimensionierten Variable welche Grafik darstellt. Ansonsten plane ich eigentlich nie soviel voraus^^...

[dadie]

Planung ? Ist Das wichtigste !!

Zanfang macht man sich Klar was will ich machen.

Dan durchdenkt man sich WIE kann ich es lösen.

dann Welche Sprache währe die besste dafür.

Gibt es schon Änliche Projekte die mir helfen können ?

Anfangen zu Coden/Programmieren

Debugen

Fertig

[Dingsi]

UML (Unified Modelling Language) ist ein Satz von Regeln mit denen man den Aufbau und Ablauf von Programmen beschreiben kann. Grafisch. Dabei gehts übrigens nicht nur um objekt-orientierte Modelle sondern auch um z.B. den zeitlichen Ablauf von Programmen oder die Möglichkeiten mit denen ein Programm mit einem Benutzer interagieren kann. UML (ab Version 2 besonders) ist ziemlich voll, aufgeblasen und nicht immer leicht zu verstehen. mMn.

Kleine Projekte plane ich weniger und Code meistens einfach drauf los.

Größere Projekte (Davon hab ich bis jetzt 2.. (Ich zähl jetzt mal nur Yinc.VM :D)) plane ich meist erstmal im Kopf durch und mal mir dann das Modell in Form einer abgespeckten UML auf (Papier und Stift. Ihr glaubt gar nicht wie wertvoll sowas ist). Also ich male die Klassen, deren Member und wie die Klassen untereinander interagieren. Dabei immer nach der OO-Philosophie: Die Daten stehen im vordergrund, die Implementation ist nebensächlich..

[Fowler]

Größere Projekte (Davon hab ich bis jetzt 2.. (Ich zähl jetzt mal nur Yinc.VM )) plane ich meist erstmal im Kopf durch und mal mir dann das Modell in Form einer abgespeckten UML auf (Papier und Stift. Ihr glaubt gar nicht wie wertvoll sowas ist).

...

in der Tat, wenn du das Projekt in UML-Form hast, ist das Programmieren eher nebensache, da darin ja schon zu erkennen ist, wie die Sache ablaufen soll.

Allerdings darf man sein Modell später auch immer mal wieder leicht abändern, wenn man die kleinen Fehlerchen entfernt, die sich da sicher eingeschlichen haben geht zumindest mir meistens so...

[Latency]

Nutzt ihr denn auch andere Diagramme wie z.B. ER-Diagramme, oder Sequenzdiagramme?

Ich persönlich muss da sagen, dass ich mich doch hauptsächlich auf Klassendiagramme beschränke und hin und wieder auf PAP zurückgreife. Struktogramme oder ähnliches nutze ich selten.

Meine Klassendiagramme hingegen sind oft recht umfangreich, zudem hab ich mir angewohnt jede Funktion mit JavaDoc ähnlichen Kommentaren auszustatten und in jeder *.src File die eine Klasse enthält oben ein UML-Klassendiagramm in Text einzufügen. Also so etwa:

Code:

/*
 |-----------------------------------------------|
 |         LoginException : MyException		 |
 |-----------------------------------------------|
 |- nick:string					 |
 |- uid:int					 |
 |- sid:string					 |
 |-----------------------------------------------|
 |+ __construct(string $message, int $code):void |
 |+ GetNick():string				 |
 |+ GetUID():int				 |
 |+ GetSID():string				 |
 |+ GetDetails():Array[String]			 |
 |-----------------------------------------------|
 */

[Floydpower]

ich persönlich mag solche planungen nicht
sie sind mir viel zu aufwendig ohne nutzen.
ich finde sie nur in kombination mit mehreren leuten die an einem projekt arbeiten (für mich!!!!) sinnvoll

ich mag es viele abshcnitte eines programmes zu unterteilen
udn wenn ein teil eben sehr komplex wird einfach weitere unterteilungen.
ich pass einfahc nru auf ne bestimmte logik zu behalten so dass ich mich net unnötig pro modul umdenken muss

wenn ich mal komplexeres überdenke benutz ich n struktugram
ist simpel und effektiv

UML bringt mich aber zum kotzen (sorry ist echt so)
bei projekten mit vielen leuten ists ja okay (wurd auch dafür konzipiert ) aber naja
Klassendiagramme find ich zwar nicht überflüssig aber nervig
ich hab meistens sowas schon lange im kopf.

aber im grossne und ganzen sollte jeder selbst für sich entscheiden wie er vorangehen will solange er keine vorgaben bekommt (uml *hust* in einem betrieb *hust*) aber naja hier wird es bestimmt net so viele leute geben die bei einem softwareunternehmen als prgger arbeiten

ER-Modelle find ich auch meistens unnötig
aber manchmal sind sie doch hilfreich deswegen würde ich nicht zwangsläufig nein sagen

aber wie gesagt man muss entscheiden was hilfreich wäre für das projekt

Dingsi hat ja auch gesagt bei kleinen projekten coded er einfahc drauf los
wieso auch soviel aufwand betreiben wenns sowieso shcon klar ist

[codec]

Planung ? Ist Das wichtigste !!

Zanfang macht man sich Klar was will ich machen.

Dan durchdenkt man sich WIE kann ich es lösen.

dann Welche Sprache währe die besste dafür.

Gibt es schon Änliche Projekte die mir helfen können ?

Anfangen zu Coden/Programmieren

Debugen

Fertig

...

Machst du mit Absicht nach jeder Zeile nochmal ein Return? Vielleicht damit deine Spams nicht ganz so spammig aussehen?

@Topic:

Ich plane meist nie. Es sei denn ich langweile mich grad mal in der Schule und hab da noch so ein paar Ideen.
Dann mach ich meist ein paar Zeichnungen und kritzel was auf ein Blatt, dass versteh dann meist nur ich - aber so kann meine Ideen keiner klauen.

[Lukas]

Ich code meistens einfach so drauf los. Dann merke ich, dass das nicht hinhaut, und fange nochmal von vorne an. Dabei versuche ich dann, die Fehler, die ich vorher gemacht habe, zu vermeiden.
Naja, auf Dauer komme ich so nicht wirklich weiter. In letzter Zeit versuche ich auch, mir etwas mehr Planung anzugewöhnen, weil ich erkannt habe, dass man so weiter kommt. Mit so Sachen wie UML kann ich mich allerdings nicht anfreunden.

[Jesus_666]

Ich bin zwar in der Führungsetage eines großen Projekts (Yao/der PortaMaker), da sind wir aber noch nicht so weit gekommen, daß wir Klassenhierarchien, Abläufe oder anderen UML-beschreibbaren Kram zu verwalten hätten. Ich werde aber irgendwann mal die Roadmap schreiben, die ich schon vor Wochen hätte schreiben sollen. Naja, wir sind eh noch Meilen vom ersten Milestone entfernt... Eigentlich sind wir mehrere Tagesreisen und eine Ozeanüberquerung davon entfernt, den ersten Milestone am Horizont zu sehen. o_o

Für ein vergleichsweise kleines Projekt (DSAster) habe ich nur eine Roadmap erstellt und werde wohl auch nicht viel mehr tun, abgesehen von durchgehender Javadoc-Dokumentation.
BTW, es ist irgendwie arm, daß ich den javadoc-Output erst noch durch ein Skript jagen muß, damit er meine Kommentare korrekt anzeigt... (Standardmäßig kommen die von javadoc erstellten Seiten dank fehlender Angabe des Encodings nicht gut mit UTF-8 klar - ratet mal, in welchem Format alle Kommentare vorliegen.)*



* Ja, ich habe mit Absicht "Javadoc" abwechselnd groß und klein geschrieben. Wenn ich von "javadoc" spreche, dann ist das der Programmname (weil der nun mal klein geschrieben wird).

[Kali-Yuga]

tyi, wie plane ich meine projekte? eigentlich garnicht was aber ratsam ist (weiß nicht obs schon welche geschrieben haben), ist dass du so viele komentare in deinen quellcode wie nur möglich schreibs und du die ganzen sachen wie die includes, die hauptschleife, die macros u.s.w. in eigene dateien schreibst und die dann verbindest

[Silencium]

Kommt immer drauf an was ich schreibe, bei Anwendungen ist ein UML immer drin, meistens fange ich mit Papier und Bleistifft an ^^
Bei Microprozessoren reicht mir ein PAP

[MuadDib]

Den Thread hab ich glatt übersehen . Nun, bei kleineren Sachen gibts im Großen und ganzen kaum Planung, vielleicht ein paar überlegen bzgl. logischer Strukur, das meiste wird aber on-the-fly entwickelt.

Bei ReVolTe, unserer Volume Rendering Funktionsbibliothek, die ich durchaus als größeres Projekt sehe, war der Ansatz da schon etwas anderer. Auf UML haben wir zwar verzichtet, weils ja im Grunde überhaupt nicht objektorientiert war, dafür haben wir aber das ganze API bereits im Vorhinein modelliert und die nötigen Funktionsköpfe zumindest mit Namen vorbereitet. Geholfen hat uns dabei unser Basis-Volume Renderer, den wir in lauter Einzelteile zerlegt hatten und in die nötigen Pakte untergebracht haben.
Resultat ist, dass man mit ReVolTe auf nahezu jeder Architektur (ab GeForce 4 und Radeon 8500) und jedem OpenGL-fähigen Windowing Toolkit einen Volume Renderer mit Transferfunktionen und Maussteuerung in knapp 100 Zeilen Code implementieren kann (und das schliesst den Window Toolkit spezifischen Code zur Fenstererstellung, etc. mit ein...).

ReVolTe wird gerade in ein paar größeren medizinischen Projekten eingesetzt, an zwei arbeite ich selbst mit. Hier ist natürlich der Umfang um einiges größer, und wir müssen uns noch ein ganzes Segmentierungs und Volumsberechnungs-API einfallen lassen, wo wir ganz, ganz sicher auf OOP setzen, und damit auch sicher unsere Struktur in Klassendiagrammen zeichnen (auch Use Case und Sequenzdiagramme, die machen sich in einer Diplomarbeit halt besonders gut).

Beim Entwickeln hätte ich mich nie erwischt, etwas anderes als Klassendiagramme zu benötigen. Sequenzdiagramme und Use-Case Diagramme sind zwar ziemlich klasse in einer Diplomschrift und veranschaulichen für einen Aussenstehenden die Abläufe besonders gut. Die Erfahrung hat aber gezeigt, dass die Dinger meistens erst nach Implementierung gemalt werden und somit in der Planung in den seltensten Fällen wirklich vorkommen (auch wenn jeder predigt, dass man sich unbedingt daran halten soll, es machen die wenigsten).

ER-Diagramme sind ja eher etwas für den Datenbank-Entwurf ... und da halt mich auch eher raus