WebStyleBoard

Interessantes Thema.
ich mache mir vorher eigntlich immer Skizzen (auf Papier, digital kann ich das absolut nicht), hauptsächlich von der Navigationsstruktur und der Datenbank.
Normalerweise halte ich mich dann aber sowieso nicht an die Skizzen, weil ich hier und da noch ein Problem entdecke, oder mir spontan was besseres einfällt :approve:

Ab und zu update ich dann mal diese Skizzen, gebe den datenbankspalten richtige Namen, zeichne verknüpfungen uns so. Das hilft zwar im aktuellen zusatand wenig, aber wenn du nach einem jahr mal wieder was ändern möchtest, wirst du dir dafür danken

Ansonsten habe ich hier unzähle Post-Its an der Wand, dem Schreibtisch, dem Bildschirm und den Boxen kleben, auf denen alles wichtige draufsteht :grin:

Wenn du das ganze allerdings nicht mehr komplett alleine machst, MUSST du alles dokumentieren, datenbankbeziehungen deutlich darstellen, nach Möglichkeit ein Projektmanagement-Tool und CVS verwenden. Wenn das ganze an den Kunden geht, kommst du sowieso nicht drum rum.

Bei solchen Sachen gibts ja immer ganz verschiedene Ansätze - und es kommt auch immer darauf an, was man denn nu macht.

Bei dem Entwurf von Internetseiten - bzw. dem Design derselben hab ich immer erstmal papier und stift benutzt um mir Gedanken zu machen, was ich erreichen will... einen sog. Anforderungskatalog (Requirements)... daran kann man eine Analysephase anknüpfen in der man dann schon mehr in die Details geht, wie man z.B. irgendwas umsetzen kann (welche Programmiersprache, Tools, Infrastruktur wird benötigt...) ... sowas nennt man in der Industrie auch gerne Requirements Engineering ... also eigentlich gehört dazu noch mehr.. aber im Prinzip bezeichnet dieser hübsche Begriff den gesamten Bereich vom Aufstellen der Requirements bis hin zur Erstellung des Pflichtenhefts für den Kunden.
Wenn man quasi selbst der Kunde ist - fällt dabei ne ganze Menge weg - aber die Frage "Was will ich erreichen - welche Unterziele kann ich dabei setzen?" ist schon gut zu stellen... und mit Hilfe dieser Anforderungen kann man dann zusehen, wie man's denn umsetzen kann.

Wenn jetzt nur das Design der Seite im Raum steht, kommen dann schnell Skizzen der Seiten dazu, die den Aufbau der Seite beschreiben... meinetwegen kann man auch die Navigationsstruktur skizzieren mit "Flussdiagrammen".

Bei der Programmierung wirds dann schon interessanter. Dabei kommt es auch ein wenig auf das verwendete Programmier-Paradigma an. Wenn man objektorientiert arbeitet, ist eine entsprechende Designphase fast unabdingbar... (ob die dann nur im Kopf stattfindet ist ja egal ). In einer solchen Phase kann man verschiedene Techniken eines Softwareengineers anwenden, um die Arbeit vernünftig strukturieren zu können... die statische Struktur eines Entwurfs - und die sog. Architektur eines Systems sind die primären Faktoren beim Entwurf einer Software oder was auch immer...
Die Architektur beschreibt dabei sowohl den statischen Aufbau (kann man z.B. mit Klassendiagrammen sehr gut erledigen) als auch die Interaktionsmöglichkeiten der Einzelkomponenten (Klassen)... was man nicht mehr so gut mit objektorientierter Methodik hinbekommt... da hilft es Blockdiagramme zu malen bei einfachen Projekten... damit man am Ende wirklich weiß, welche Komponenten mit welchem Verhalten mit anderen Komponenten zusammenarbeiten müssen, damit das ganze harmonisch zusammenpasst.
Selbst wenn man großer Anhänger des sog. Extreme Programmings ist - ein Buzzword der letzten Jahre, kommt man häufig zumindest nicht um die statische Struktur einer Software herum... solche Designentscheidungen sind die, die man später am schwierigsten ändern kann, daher muss man sich da wirklich vernünftig gedanken drüber machen. Bei anderen Dingen kann man erstmal versuchen die obersten Anforderungen zu erfüllen - wenn man dann feststellt, dass man nicht hinkommt - die grobe Struktur aber stimmt - kann man sog. Refactoring betreiben um das Design entsprechend zu verfeinern...

Also ganz grob gesagt - ich würd immer nen Mittelweg gehen... Konzepte aufstellen, Anforderungen aufsetzen, das ganze Analysieren, Design machen (Struktur festlegen) und dann loslegen mit der Implementierung... und je nachdem wie gut das Design war, kann man dann innerhalb der Implementierungsphase tatsächlich noch einiges anpassen...
Wenn das Design schlecht war, kommt man schnell zu dem Punkt, dass man bei geänderten Anforderungen (selbst wenn diese nicht so groß waren), das ganze Projekt beerdigen muss, alles wegschmeißen kann und von vorne programmieren muss ... und das will man ja meist dann doch vermeiden.

also ich für meinen Teil ... wenn ich was anfange, dann habe ich das meiste schon irgendwie im Kopp ... beispielsweise http://www.frustossi.de ... 3 Tage von der Idee bis zur Fertigstellung (zumindest so wie es imMo is)

Dabei kommt mir zu gute, dass ich mittlerweile schon ein feststehendes Grundsystem habe (Template/DB/Ordnerstruktur/bestimmte Variablen) ... diese Sachen haben sich im Laufe der Jahre eingeschliffen ... dadurch hab ich nicht soooo sehr an "Planungsarbeiten" zu tun.

Ich brauch aber auch noch Papier und Bleistift ... um die DB-Struktur auszutüfteln ...

Aber so ... ich code einfach drauf los mit dem groben Plan, den ich im Kopp hab. :pleased: und das Feintuning mach ich dann, wenn das Grobe fertig ist ... wenn mich dann noch nicht die Lust verlassen hat :arg: