PHP-Projekte planen

Irgendwann gelangt wohl jeder mal an den Punkt, an dem er merkt, dass ihn das »drauflos programmieren« in eine Sackgasse ohne Wendemöglichkeit geführt hat und man nimmt sich vor, das nächste Mal vorher zu planen. Ein guter Vorsatz, der jedoch nicht immer so leicht in die Tat umzusetzen ist.
In Büchern und im Netz gibt es zwar einige Kapitel/Artikel zu diesem Thema, die man jedoch fast alle zu einem Satz zusammenfassen kann

Setz dich erst mal hin, schreibe auf, was die Seite für Bereiche und Funktionen haben soll und dann gehst du Stück für Stück daran, dies umzusetzen

Prima! Da wäre wohl niemand drauf gekommen, oder?
Tatsache ist leider, dass man auf diese Weise wahrscheinlich in die gleiche Sackgasse gerät — diesmal jedoch mit Stadtplan und vielleicht nicht ganz so schnell.
Es ist mit Sicherheit ein guter Start, wenn man ausformuliert, was die fertige Seite denn nun bieten soll. Für ein erfolgreiches Projekt sollte man jedoch auch noch einige andere Überlegungen anstellen, bevor man die erste Zeile tippt.

[more]

Für einige dieser Überlegungen reicht zunächst eine einfache Checkliste

  1. Auf welche/n PHP-Version/en soll die Seite hinterher lauffähig sein?
    Wenn die Seite nur auf einem Server laufen soll, auf dem PHP5 installiert ist, so muss man nicht unbedingt Rücksicht auf Abwärtskompatibilität genommen werden und man kann die neuen Deklarationen und Funktionen ohne Probleme nutzen.
    Läuft auf dem Server dagegen PHP4, sollte der Quellcode so gestaltet sein, dass er auch bei einem Update auf die 5er-Version noch funktioniert. Bei einer PHP-Version vor 4.1.0 muss zusätzlich noch an die (hier nicht vorhandenen) Superglobals gedacht werden.

  1. Gibt es Daten, die gespeichert werden sollen und wenn ja, auf welche Weise?
    Wenn das System mit mehreren Datenbanken lauffähig sein soll, sollte man auf ein System wie ADOdb oder PEAR::DB setzen (es kann natürlich auch etwas sein, das man selbst schreibt).
    Wenn man dagegen mit nur einer Datenbank (z. B. MySQL), oder mit Textdateien arbeitet, sollte man sich an dieser Stelle überlegen, an wie vielen Stellen ein Datenbankzugriff erfolgt. Braucht man nur an zwei oder drei Stellen im Script Daten aus der Datenbank, dann lohnt sich in der Regel eine entsprechende Datenbank-Klasse nicht. Benötigt dagegen fast jede Datei entsprechende Daten, sollte man dagegen schon eine Klasse oder Funktionsbibliothek zusammenstellen.

  1. In welcher Form soll die Ausgabe des erzeugten HTML-Quelltextes erfolgen?
    Templates, PHP/HTML vermischen, oder gar statische Seiten generieren?

  1. Was für Basisfunktionen/Klassen werden benötigt?
    Brauche ich einen eigenen ErrorHandler, eine Datenbankklasse, eine Funktionsbibliothek für Textformatierungen, etc?

  1. Soll die Webseite mehrsprachig sein?
    Wenn die Webseite mehr als eine Sprache »sprechen« soll, ist es eine gute Idee, dies auch in der Gestaltung des Datenbankschemas und der entsprechenden Ausgaben, die die Dateien erzeugen, von Anfang an zu berücksichtigen.

  1. Wie soll die Ordnerstruktur aussehen?
    An welche Stelle kommen Klassen, Funktionen, Include-Dateien?

  1. Namensraum — nach welchem Schema werden Funktionen, Variablen, Klassen benannt?

  2. Welche Form der Versionsverwaltung soll eingesetzt werden?

Die Liste ist mit Sicherheit noch beliebig erweiterbar, deckt aber schon einmal die gröbsten Bereiche ab.

Als nächsten Punkt lege ich meist erst einmal die Ordnerstruktur an und checke das leere Projekt in die Versionsverwaltung ein.
Danach beginne ich dann mit den ersten Entwürfen für die Datenbankstruktur. Es hilft ungemein bei der Gestaltung des Quelltextes, wenn das Datenbankschema bereits festgelegt und die Daten, die man hinterher auf jeden Fall benötigt (z. B. für die Konfiguration) schon gespeichert sind.
Nun können die ersten Dateien angelegt werden, wobei Konfigurationsdateien und die Basisklassen und -funktionen zuerst angelegt werden sollten (diese Dateien werden schließlich von einigen anderen benötigt).

Für die Erstellung der weiteren Dateien hilft es mir persönlich meist ungemein, wenn ich erst einmal die Oberfläche grob entwerfe — meist ganz »altertümlich« mit Bleistift und Papier.

Anmerkungen

Bekanntlich führen viele Wege nach Rom. Die oben genannten Vorschläge sind mit Sicherheit weder ein »Muß«, noch ein Patentrezept, sondern sollen eher eine Anregung darstellen. Es ist halt mein eigener Weg (oder eher Pfad?) zum Ziel.
Ich hoffe, dass diese Anregungen vielleicht dem Einen oder Anderen etwas helfen können.
Vielleicht bekomme ich ja auch noch die eine oder andere Anregung durch diesen Post ;)

Ich habe diesen Artikel geschrieben, weil ich selbst bei meinen ersten Projekten vor dem Problem stand, nicht zu wissen wie man an die Planung herangehen soll.
Den richtigen Ausschlag für die Idee zu diesem Post hat dann aber vor einiger Zeit ein Post in einem Forum (ich weiss leider nicht mehr, in welchem) gegeben, in dem einem Mitglied, dass vor seinem ersten Projekt stand, folgende Tipps gegeben wurden (nicht wortgenau): »Mach eine Liste, was du haben willst und dann fang an zu coden«, »Mach eine Mind-Map« und (mein Favorit) »Lerne UML«. Nichts gegen UML — ich nutze auch des Öfteren Klassendiagramme, aber man braucht es nicht unbedingt. Und für jemanden, der gerade vor dem ersten Projekt steht, ist es mit Sicherheit ein Grund, entmutigt aufzugeben.


Ähnliche Artikel

Geschrieben am
Share |

Kommentare

  1. Bertram Simon schrieb am 17.03.06:1

    Ich erstelle aus dem Interview mit dem Kunden immer eine Menüstruktur und leite aus dieser dann die notwendigen Funktionen ab.

  2. Julia schrieb am 17.03.06:2

    Das Menü ist eine gute Idee – je genauer man sich eine Seite in ihrer Struktur vorstellen kann, desto besser und schneller kommt man zum Ziel. Zumindest geht es mir so.

    Außerdem kann man auf diese Weise das Projekt besser in kleine „Teilprojekte“ gliedern.


Dein Kommentar:

Sämtliche Html-Tags werden gelöscht, der Kommentar kann mit Textile formatiert werden.
Vor dem Absenden müsst ihr euch einmal die Vorschau ansehen.