Wie bereitet man sich richtig vor, wenn man etwas programmiert?

redrew99

Gockel mal nach Programmabläufplänen
( http://de.wikipedia.org/wiki/Programmablaufplan ) und Software dazu.
Z.B. Eclipse mit UML-plugin.

Dürfte aber noch zig andere Programme dafür geben.

Notfalls sollte es auch mit MS Office gehen.

RussianTux

Thilo87 schrieb:

Hallo,

ich weiß nicht, wie man das genau nennt unter Programmierern. Beim Film würde man es halt Drehbuch nennen

Vielleicht meinst du ein Konzept?

Thilo87 schrieb:

Sonst fällt mir während des Programmierens noch dieses und jenes ein, was auch noch gemacht werden muss, und dann fehlt das und das ist unpraktisch u.s.w...

Deswegen muss man die Softwarearchitektur auf Erweiterbarkeit durch mögliche Plugins, "modular" strukturieren, wenn du Beispielweise eine Funktion gebastelt hast, spielt es eigentlich keine Rolle was innen drin passiert, Hauptsache die Kommunikation nach Außen bleibt unverändert, nur mal so als Anmerkungsbeispiel.

Thilo87 schrieb:

Als kleine Übung möchte ich mir ein paar Funktionen bauen, die Einstellungen des Programms speichern können. Und das möglichst unkompliziert.

Textdatei, ASCII schreiben und auslesen...

Thilo87 schrieb:

Ja und da wäre ich bei meiner Frage: Wie schreibt man das "Drehbuch"?

Im Grunde genommen gibt es dafür keine vorschriften, nimmst ein Blatt und ein Stück Papier und zählst alles auf was das Programm können muss, also alle Ziele die erreicht werden müssen, nimmst du dir ein zweites und notierst wie dein Programm aufgebaut werden soll (Interface (Grafisch?), Module / Klassen, Kommunikation zwischen Modulen, Standards die du berücksichtigst (welche Bibliotheken du dabei nutzt)). Es gibt auch Modelliersprachen wie UML, aber was du davon hällst musst du selber sehen

Thilo87 schrieb:

- Einstellungen sollen überall im Programm abrufbar sein
- Einstellungen sollen überall im Programm verändert werden können
- Einstellungen sollen automatisch gespeichert werden
- Es sollen verschiedene Einstellungen gespeichert und abgerufen werden können (Einstellungspaletten)
- Alle Einstellungspaletten werden in einer Datei gespeichert, die jeweils ausgewählte wird markiert z.B. mit Boolean
- Steuerelemente sollen beim Laden der Einstellungen automatisch angepasst werden
- Einstellungen sollen automatisch abgespeichert werden, wenn die Steuerelemente geändert werden

Das sind schon mal einige Ziele...

Thilo87 schrieb:

Ja so ungefähr. Und dann habe ich aufgeschrieben, was für Funktionen ich in etwa brauche.

- globale Struktur für die Einstellungen
- Funktion zum Laden der Einstellungen der ausgewählten Einstellungspalette
- Funktion zum Abspeichern der Einstellungen
- Funktion zum Anpassen der Steuerelemente an die gewählte Einstellungspalette
- Funktion zum Anpassen der Einstellungen an die Steuerelemente

Ich würde das alles in Klassen zusammensetzen, Klassen für jeweilige Speicherverwaltung, Klassen des eigentlichen Kern-Programms die jeweils miteinander kommunizieren.

Thilo87 schrieb:

- ???Aber was ist, wenn ich direkt Einstellungen ändern möchte, ohne dass dabei der Nutzer ein Steuerelement verändert? Dann würden die Einstellungen nicht automatisch gespeichert werden.
- Man könnte auch immer wieder die Einstellungen abfragen, also die Steuerelemente, dann werden sie sofort automatisch geändert, wenn man z.B. ein Häkchen setzt oder halt irgendetwas verändert. Ich müsste nur noch bei jedem Steuerelement eine Funktion Einstellungen_aktualisieren aufrufen.

Ich hab zwar nicht ganz verstanden, aber ich denke ich würde die Einstellungen als Globale Variablen während der Programmausführung im RAM lassen und erst beim beenden abspeichern (wenn auf diese Einstellungen nichts anderes mehr zugreift versteht sich.)

Thilo87 schrieb:

Das sind jetzt nur Notizen, in 5 Minuten geschrieben. Gibt es ein "Drehbuch zur Drehbucherstellung"? Wie man sich richtig und effektiv auf das Programmieren vorbereitet? Ich meine, wenn umfangreiche Spiele programmiert werden, wird ja auch nicht einfach drauf los programmiert nach dem Motto "mal sehen was dann schlussendlich bei rauskommt". Da wird wahrscheinlich auch sehr intensiv vorbereitet und beim Programmieren dann nur noch der reine Text in Computersprache übertragen. Also wisst ihr, wie man da möglichst effektiv vorgeht?

Darüber werden Bücher geschrieben, diese kann man in Google natürlich auch finden wenn man nach etwas wie "Programm Architektur / Planung / Projekt Konzeption" sucht. Ein "Programmierer" unterscheidet sich vom "Coder" indem er seine Projekte genauestens konzipiert.

In der modernen Game- und Software-Industrie wird 90% des Budgets für die Planung des Projekts ausgegeben, die restlichen 10% sind dann zum eigentlichen Code schreiben und nachträglicher Fehlerbehebung.

MfG Russian Tux

RussianTux schrieb:

In der modernen Game- und Software-Industrie wird 90% des Budgets für die Planung des Projekts ausgegeben, die restlichen 10% sind dann zum eigentlichen Code schreiben und nachträglicher Fehlerbehebung.

Das wünschen sich Profs für Software-Entwicklung vielleicht so. Mit der Realität hat das aber wenig zu tun.

hustbaer

StimmtNicht schrieb:

RussianTux schrieb:

In der modernen Game- und Software-Industrie wird 90% des Budgets für die Planung des Projekts ausgegeben, die restlichen 10% sind dann zum eigentlichen Code schreiben und nachträglicher Fehlerbehebung.

Das wünschen sich Profs für Software-Entwicklung vielleicht so. Mit der Realität hat das aber wenig zu tun.

Genau.

@RussianTux:
Wenn man keine Ahnung hat, einfach mal die Fresse halten.

RussianTux

hustbaer schrieb:

StimmtNicht schrieb:

RussianTux schrieb:

In der modernen Game- und Software-Industrie wird 90% des Budgets für die Planung des Projekts ausgegeben, die restlichen 10% sind dann zum eigentlichen Code schreiben und nachträglicher Fehlerbehebung.

Das wünschen sich Profs für Software-Entwicklung vielleicht so. Mit der Realität hat das aber wenig zu tun.

Genau.

@RussianTux:
Wenn man keine Ahnung hat, einfach mal die Fresse halten.

Sehr nett und professionell geantwortet .. danke

Mechanics

RussianTux schrieb:

hustbaer schrieb:

StimmtNicht schrieb:

RussianTux schrieb:

In der modernen Game- und Software-Industrie wird 90% des Budgets für die Planung des Projekts ausgegeben, die restlichen 10% sind dann zum eigentlichen Code schreiben und nachträglicher Fehlerbehebung.

Das wünschen sich Profs für Software-Entwicklung vielleicht so. Mit der Realität hat das aber wenig zu tun.

Genau.

@RussianTux:
Wenn man keine Ahnung hat, einfach mal die Fresse halten.

Sehr nett und professionell geantwortet .. danke

Ich wollte es gestern auch schon sagen, aber mir ist keine so höfliche Formulierung wie hustbaer eingefallen, deswegen habe ich gewartet, bis es jemand für mich formuliert ^^

Einfach drauf los - funzt immer :schland:

IrgendeinName

redirectexception schrieb:

Einfach drauf los - funzt immer :schland:

Wenns etwas größer wird eben nicht.

@TE
Kauf dir ein Buch über Softwareengineering, wenn dich so etwas interessiert. Es gibt ganz verschiedene Methoden, informier dich am Besten über alle.

RussianTux

redirectexception schrieb:

Einfach drauf los - funzt immer :schland:

Eine Cryengine 2 auf "einfach-drauf-los"? Viel Spaß!

IrgendeinName

RussianTux schrieb:

redirectexception schrieb:

Einfach drauf los - funzt immer :schland:

Eine Cryengine 2 auf "einfach-drauf-los"? Viel Spaß!

#ifndef CRYENGINE_H
#define CRYENGINE_H

#include <iostream>

class CryEngine2
{
	public:

		CryEngine2(int amount)
			:amountOfTears(amount)
		{}

		void Cry()
		{
			std::cout << "Crying " << amountOfTears << " tears\n";
		}

	private:
		int amountOfTears;

};

#endif

RussianTux

x)))

Wie siehts mit Frostbite 2.o aus?

otze

Bücher über Softwareengineering bringen meiner Meinung nach nichts, solange man selbst kein Projekt in den Sand gesetzt hat. Die Fehler in der Softwareentwicklung sind häufig relativ subtil. Ich denke, man hat am Meisten von diesen Büchern, wenn man sie liest und dann auf seine Erfahrung von Projekten zurückschauen kann: "Was ist schief gegangen, weil ich das nicht beachtet habe?".

Insofern würde ich mir erst mal kein Buch kaufen, sondern einfach drauf los Programmieren. Mit deinem Anforderungskatalog bist du schon auf einem guten Weg. Wenn du den hast, einfach anfangen. Fang aber mit etwas an, was du in vielleicht 10000 Zeilen fertig bringen kannst(okay, das wirst du nicht abschätzen können, aber zu wenig wirds unter Garantie nicht). Das ist groß genug, dass du dir über Softwaredesign Gedanken machen kannst und klein genug, dass dich die Fehler nicht komplett scheitern lassen.

Was mir an deinem Softwareplan auffällt:

- Es ist alles sehr wage. Das ist okay, solange du dir nur grob überlegen willst, was deine Software tun soll, aber es reicht nicht, um sich daraus Gedanken über einen Programmentwurf zu machen. Was zum Beispiel fehlt ist eine konkrete Definition von "Einstellungen" und "Steuerelementen". Dadurch ist mir nicht klar, was genau das Problem ist, auf das du stößt.

- Du vermischt verschiedene Ebenen. An einigen Stellen beschreibst du abstrakt die Aufgaben deines Programmteils, an anderen beschäftigst du dich bereits mit konkreten Implementationsfragen: trenne das! Die Frage, wie die verschiedenen paletten gespeichert werden sollen gehört irgendwo zwischen Anforderungen und Programmentwurf.

hallo otze,

warum heißt du eigentlich so ähnlich wie ein weibliches geschlechtsteil? :schland:

Th69

Er heißt doch gar nicht agina

otze

Und ich dahcte all die jahre, ich würde mich wie eine Ruhrpottfußballlegende nennen. Unglaublich, warum hat mir das all die jahre noch niemand gesagt?

Mechanics

otze schrieb:

Bücher über Softwareengineering bringen meiner Meinung nach nichts, solange man selbst kein Projekt in den Sand gesetzt hat. Die Fehler in der Softwareentwicklung sind häufig relativ subtil. Ich denke, man hat am Meisten von diesen Büchern, wenn man sie liest und dann auf seine Erfahrung von Projekten zurückschauen kann: "Was ist schief gegangen, weil ich das nicht beachtet habe?".

Natürlich, aber die "handwerklichen" Grundlagen müssen da sein. Schichtenarchitektur, Design Patterns, Architekturmuster, Dependency Injection usw. sind ja erst einmal nur Bausteine, die jeder beherrschen sollte, aber bei weitem nicht jeder tut. Und die kommen nicht von alleine, die muss man irgendwo gelernt haben.