Richtige Web-Development-Architektur

Hallo zusammen,

ich würde gerne mit euch über ein "kluges", "globales", "entwicklerfreundliches" und "sauberes" Programmieren sprechen.

Ich arbeite nun seit fast 2 Jahren in einer Agentur, wo ich mehrere Seiten erstellen muss (PHP, JS, CSS, HTML usw.) und Seitenbesuche logge, protokolliere usw. Das Ganze habe ich ganz allein von Anfang an aufgebaut, es gab also am Anfang nur einen leeren Ordner.

Also es ist praktisch so:
Es gibt mehrere Seiten von 4-5 Schritten, wo man Sachen eingeben muss und am Ende etwas raus kommt (ich kann/darf/möchte leider nicht detalierter beschreiben aber das müsste reichen).
Jede Seite kann mehrmals kommuniziert werden. Dafür mache ich eine Trennung in der URL mittles Parameter. Es sieht dann also so aus (dabei ist xyz unsere Hauptdomain):

Seite 1: http://www.xzy.de/product_1/index.php?page_id=XXX&partner_id=1
Seite 2: http://www.xzy.de/product_1/index.php?page_id=XXX&partner_id=2
Seite 3: http://www.xzy.de/product_2/index.php?page_id=YYY&partner_id=1
Seite 4: http://www.xzy.de/product_2/index.php?page_id=YYY&partner_id=2

usw.

also mehrere Produkte bzw. Seiten und mit verschiedene Parameter-Werte.
Jede Seite ist natürlich ein mal aufgebaut, und ich erstelle mehrmals einen Link mit den verschiedenen Parametern für jeden extra.

Dabei habe ich unheimlich sehr viele Aufgaben wie Loggen, Protokollieren, Patameter Überprüfen, falsche Eingaben Überprüfen usw.

Damit ich das so dynamisch bzw. automatisiert wie möglich haben kann, erstelle ich natürlich eine Seite dynamisch. Viele Funktionen sind global untergebracht sodass sie von allen Seiten benutzt werden können wenn nötig, da diese Funktionen für alle Seiten das gleiche machen sollen.

Ich habe nun folgende Ordnerstruktur auf dem Server:

-httpdocs

- -> src/
- - -> service/
- - -> logger/
- - - - logger.php
- - -> lib/
- - - - checkValues.php
- - - - checkInput.php
- - - - checkInput.js
- - -> ...
- - -> ...

- -> pages/
- - -> product_1/
- - - -> css/
- - - - - style.css
- - - - index.php
- - - - site_js_file.js
- - -> product_2/
- - - -> css/
- - - - - style.css
- - - - index.php
- - - - site_js_file.js
- - - ...
- - - ...

Ich hoffe das ist gut lesbar. Das ist auch nur das 1/5 oder so aber das reicht zum Verständnis.

Nun habe ich folgende Anregung. Ich habe mir so viel Mühe um wie gesagt alles so automatisiert wie möglich zu halten, z.B. so, dass ich ein Template von einer Seite habe, ein paar Änderungen in der Config-Datei, ein paar Einträge der Bildernamen und zack, die Seite ist da und auch im System eingebunden usw.
Wenn aber manchmal der Chef kommt und irgend eine Änderung im System wünscht bzw. eine neue Funktionalität dann merke ich jedes Mal dass ich da etwas nicht richtig gemacht habe, weil ich dann jedes Mal auf einem "Chaos"-Code lande und sehr viele Sachen letztendlich doch statisch mache damit ich das Ganze nicht neuschreiben muss.

Deswegen wollte ich von euch gerne ein paar Tipps vielleicht hören (bzw. lesen), was man in so einem Fall besser optimieren kann, eure Meinung nach wichtigen Punkten die man beachten sollte usw. Ich bin ja kein 23478566-Jahre-Erfahrungs-Profi, von daher fülle ich mich dass ich mich da kein Bisschen weiterbilde bei der Sache. Ich bin zwar nicht einer der über eine Abfrage 1000 if-else Abfragen schreibt sondern einer der das in einem Algorithmus bzw. in 3-4 Zeilen versucht zu machen, aber ich denke mir fehlt dennoch sehr vieles um ein 100% optimales System für meine Arbeit zu schreiben.

Vielen Dank für jeden Antwort und dass ihr diesen langen Text zu Ende gelesen habt (falls ja )

ich kann dir leider keine genauen angaben geben, weil ich in dem Bereich nicht tätig bin, aber ich möchte dir ein paar Schlüsselwörter mit auf den Weg geben:

PHP CORE Framework z.B. http://codeigniter.com/
Modularer Aufbau der Funktionen

halte dir im Hintergrund z.B. mit NetbeansIDE oder Eclipse, eine gute Anzeige der Datenherkunft (http://code.google.com/p/epdv/), damit du weißt welche Verbindungen relevant sind.

als Beispiel kannst du dir das Contao CMS anschaun. Es ist Modular aufgebaut und wird immer mit neuen Funktionen erweitert.

benutze ein framework (spontan fällt mir noch symfony ein) und schau dir das mvc-konzept an.

2-3 Begriffe von euch beiden und schon lande ich mittles Google auf 1 Mil. Seiten
Danke.

Ich habe den Begriff "MVC" vor langer Zeit gesehen, wo ich im VS 2010 anfangen wollte Programme mit ASP/C# zu entwickeln. Irgendwie habe ich das dann nur damit verbunden.
Also könnte ihr euch vorstellen (wegen der stressigen vielen Arbeit) wie weit hinten ich so bei manchen Sachen liege.

Diese Programme sehen gut aus, ich werde sie mir 100% näher angucken. Das was mir jetzt noch fehlt ist, wie ich es AM BESTEN und halt effizienter mache, mein System hier zu schreiben, sodass ich gar keine Probleme haben werden später, irgend eine Funktion oder eine Zwischenseiten zu schreiben und direkt in das System einbinden, sodass sie von allen anderen Dateien "akzeptiert" wird, und ich nicht anfangen muss entweder viele if-else Abfragen zu schreiben oder diese neue Funktion für jede Seite extra schreiben muss.

Gibt es da vielleicht ein paar generellen Tipps bzw. Sachen die ich UNBEDINGT achten sollte wenn ich eine "so automatisiert wie möglich" PHP-Anwendung von mehreren globalen und lokalen Dateien schreiben will?

Nochmals Danke.

Dazu können schon ganz abstrakte Punkte, die man eigentlich sowieso beachten sollte, enorm beitragen:
- gut und genau dokumentieren (außerhalb des Codes)
- Benennung von Klassen, Funktionen, Dateien & -Struktur, ... auch eindeutig und nachvollziehbar durchführen
- gute Planung vorher schon, dabei auch gleich Konventionen vereinbaren (Namensvergabe, etc.) und das Gesamt-Ziel & mögliche kommende Erweiterungen immer im Auge behalten
- gut mitloggen was wo passiert, dabei die log-ausgaben so gestalten dass Du evtl. Fehler- oder auch Info- / Debug-Meldungen schnell ausfindig machen kannst; das hilft auch beim Ändern/Erweitern von bestehender Funktionalität wirklich weiter
- strickte Trennung von Logik und Grafik (btw. fällt mir bei Deiner Ordnerstruktur auf, dass Du in jedem 'product' immer ein eigenes css hast; das würde ich vermutlich zentralisieren und die files mit 'styles.product_xyz.css' o.ä. benennen | je nach ähnlichkeit der produkte kann man sogar dieselbe index.jsp und mehr verwenden und muss nur die styles und evtl. ein paar divs austauschen, das liese sich auch generisch lösen)

Das ist erstmal das A und O das man sowieso überall liest und hört. Wie wertvoll das aber ist wird immer wieder unterschätzt.

Bin aber auch kein 23,5-Moi.-Jahre-Erfahrungs-Entwickler.

Du erinnerst mich jetzt an den Anfang wo ich das Ganze aufstellen wollte. Da habe ich eine Projektplannung gemacht bei der ich schon nach 6 Monaten feststellen musste dass ich da etwas nicht richtig gemacht habe. Ich habe es damals neu geschrieben mit Verbesserungen. Ich möchte es gerne noch ein mal machen aber dann auch richtig, da es sich mittlerweile sehr viele 'Produkte' gesammelt haben und der 'src/' Ordner an sich schon mehr als 60 Dateien enthält. Dazu habe ich noch einen von mir benannten URLCreator erstellt, dass all die Links automatisch zum klicken bereit stellt. Dann kommt noch die Testumgebung hinzu, wo alles getestet wird bevor es frei gegeben wird. Und das alles möchte ich zusammen in einem Ordner als sagen wir mal ein Programm haben. Das ist also ziemlich viel, deswegen machte ich auch dieses Thema auf.

Sitze heute die ganze Zeit und sehe mir Frameworks und MVC an. Ein guter Beitrag ist hier:
http://www.net-developers.de/blog/2008/09/23/mein-eigenes-mvc-framework-artikelubersicht/
Das Konzept an sich kenne ich bereits, aber ist ist immer gut etwas neues zu lesen. Vielleicht stehen da Sachen die man noch nicht kennt.

Über Trennung von Logik und Grafik kann ich echt nur zustimmen. Das ist sehr sehr wichtig. Das mit den CSS-Dateien klingt gut, muss mal gucken ob das in meinem Fall auch was bringt. Die verschiedene Browser und ihre Versionen nerven auch, sodass ich für jeden Produkt mehrere CSS-Dateien habe (vor allem IE killt mich) aber das ist ja ein anderes Thema.

Dokumentieren und vor allem SEHR AUSFÜHRLICHE NAMENSGEBUNGEN sind für mich das wichtigste. Weil bei so vielen Dateien weiß man bald nicht mehr was man selbst geschrieben hat!

zum dokumentieren schau dir mal uml an. beim implementieren kommst du um design-pattern nicht herum... hsat du schon ein lastenheft?

Ja habe ich. UML Programm habe ich auch, das entsprechende Model besteht bereits, allerdings habe ich es mir (unverständlich wieso und wie) abgewöhnt mir das anzuschauen. Also irgendwann ein mal gemacht und dann schon vergessen, da ich das ganze System eh im Kopf habe und immer direkt in die Dateien rein gehe.

Jetzt habe ich schon so vieles über "Framework benutzen oder nicht" gelesen dass ich nicht weiter weiß Ich meine ok, es geht mir mehr darum WIE ich das aufbaue und nicht WOMIT, aber ein guter Start ist halt ein guter Start. Deswegen überlege ich noch ob ich ein Framework einsetze, da ich ein Fanatiker der Selbstkontrolle bin und über jede Zeile Code bescheid wissen möchte!

MVC kommt jetzt bei mir 10000% zum einsatz. Die Frage wäre noch, wie man genau anfängt wenn man sowas aufbauen möchte. Die Schichten separat aufbauen? Oder Stück für Stück parallel mit einer Testseite zusammen? Ich glaube eher das 2. So kann man jeden entstandenen Fehler bzw. Denkfehler direkt verarbeiten. Hier besteht aber die Gefahr dass man sich in einem Labyrinth von Funktionen usw. verwirren kann, sodass man am Ende gar keinen Fehler entdecken kann obwohl da einer ist. Browserausgaben (mit Zeilen-Angabe) sind eine Rettung, ja, aber das kostet unheimlich viel Zeit.

Was meint ihr?

UML würde ich eher empfehlen wenn ein ganzes Team am Projekt arbeitet. Oder zur Übergabe an weitere Entwickler, bzw. zum Verständnis für Nicht-Entwickler.
Für mich selbst wäre mir das einfach zuviel Arbeit und zu unübersichtlich.

Du hast die richtigen Worte für mich gefunden. Das meinte ich auch vorhin mit "habe es mir gar nicht mehr angeguckt bzw. beschäftige ich mich nicht mehr damit". Ich arbeite ja alleine an das Ganze hier, aber später soll/könnte eine Aushilfe kommen. Da wäre es gut wenn man so ein paar Sachen zeigen kann, die man so wie sie jetzt sind nicht verstehen kann.
Von daher ist es von der einen Seite gut ein UML Diagramm präsentieren zu können oder wenigstens ein Dokument mit dem Ablauf und dem Aufbau des Systems. Vor allem das Zweite ist eine Sache für den Chef. Er hat kein Bock dass ich im auch nur eine Zeile Code zeige. Er möchte einfach nur "klaren Text" hören.

Ja, aber sowas ist am Flipchart in 15 Minuten auch skizziert. (je nach detailanspruch)

Lambo-Benni schrieb:

Ja, aber sowas ist am Flipchart in 15 Minuten auch skizziert. (je nach detailanspruch)

Zum Vergrößern anklicken....

mit anderen worten, du hast das alles im kopf? dann mal viel spass, nach dem urlaub, wenn du das jemandem direkt erklären musst.

Welches UML-Diagramm meint ihr denn? UML definiert mehrere Diagramme.

Hier gehts zwar um PHP, aber um das mal zur zu skizzieren, wie das bei Ruby on Rails abläuft: Das verwendet auch die MVC-Architektur, aber ist nach noch mehr Designprinzipien entworfen, u.a. Don't repeat yourself - es gibt also immer (exakt) eine Stelle, wo die gesuchte Information abgelegt ist. Von daher ist dort eine Dokumentation relativ überflüssig, sofern man sich an die Konventionen hält und seine Klassen eindeutig benennt. Der Nachteil einer Dokumentation ist, dass sie auch immer aktuell gehalten werden muss - hast du Zeit für diesen Mehraufwand? Es gibt nur eine Sache die schlechter ist, als keine Dokumentation: Eine falsche Dokumentation.

Bei Ruby on Rails ist das kein Problem, jemand anderen auch nach dem Urlaub noch in die Anwendung einzuführen. Das ist alles anhand der Quellcodes schnell geschehen. Wo welcher Code abgelegt wird ist in der Konvention geregelt, wie die Klassen und Datenbanktabellen und -spalten benannt werden ist geregelt, wie Verknüpfungen zwischen Tabellen erstellt werden ist geregelt, ...

Für PHP schau dir mal FLOW3 an, das ist ein modernes Framework was erst in letzter Zeit entwickelt wurde, und vom Funktionsumfang die anderen Frameworks bei weitem schlägt. Setzt auch die MVC-Architektur um.

Freundliche Grüße

Stefan

Also wegen Dokumentation:
Man kann z.B. phpDocumentor mittels einem cron job laufen lassen. Der kompiliert dann (zu den Zeitabständen die man im cron job definiert hat) den Code. So ist die Doku immer aktuell ohne sich Gedanken machen zu müssen. Ist auch recht einfach so was zu machen.

Und wegen FLOW3:
Das habe ich auch gesehen im Netz, habe auch vieles über positive und negative Aspekte darüber gelesen (müsste sie nochmal lesen um sie hier auf zu listen). Wie ich bereits sagte bin ich ein Fanatiker des "Den ganzen Code lieber komplett selbst schreiben". Von daher bin ich bereits dabei das MVC Konzept so richtig zu erlernen, was mich auch zu PEAR geführt hat usw. Schon interessant was man alles noch nicht kennt. Mit anderen Frameworks will ich mich erstmals beschäftigen wenn ich das MVC-Prinzip gut kenne und wenn ich mir sicher bin es bestehen keine Sicherheitslücken.
Es sei denn man überzeugt mich so richtig davon

rohamis schrieb:

Wie ich bereits sagte bin ich ein Fanatiker des "Den ganzen Code lieber komplett selbst schreiben". Von daher bin ich bereits dabei das MVC Konzept so richtig zu erlernen,

Zum Vergrößern anklicken....

Wenn du Spaß daran hast, monatelang dich auf niedrigster Ebene mit den Eigenheiten der verwendeten Systeme auseinanderzusetzen, du tiefe Kenntnisse über Angriffsszenarien und deren Verhinderung hast, dich perfekt mit HTML, CSS und den neuesten JavaScript Technologien auskennst, dann will ich dich nicht daran hindern, das zu tun.

Wenn du allerdings in akzeptabler Geschwindigkeit einen brauchbaren, logisch strukturierten und auch für andere Leute einfach verständlichen Code produzieren willst, dann solltest du auf allgemein verwendete Tools zurückgreifen.

Dich auf niederer Ebene bewegen kannst du in deiner privaten Freizeit gerne machen - aber gerade hier, wo es um berufliche Projekte geht, solltest du zwischen Idealismus und Pragmatismus abwägen. Was bringt es, wenn du deinem Idealismus nacheiferst, und du damit deinem Arbeitgeber am Ende eine schlechtere Lösung (v.a. in Hinsicht auf Funktionalität, Sicherheit und Verständlichkeit des Codes) servierst? Schließlich zahlt er dich nicht für Idealismus, sondern für das Ergebnis deiner Arbeit.

Meines Erachtens kannst du nur davon profitieren, wenn du der Arbeit von hunderten bis tausenden anderen Webentwicklern mit wesentlich mehr Kenntnissen und Erfahrungen vertraust, und deren Framework verwendest, als wenn du alles selbst Bit für Bit selbst zusammensetzt.
Natürlich will das Framework gut ausgewählt werden, und die Entwicklungsparadigmen des Frameworks hinterfragt werden - aber die dort hinein investierte Zeit ist es Wert, denn dadurch hast du am Ende ein viel besseres Ergebnis.

rohamis schrieb:

Mit anderen Frameworks will ich mich erstmals beschäftigen wenn ich das MVC-Prinzip gut kenne und wenn ich mir sicher bin es bestehen keine Sicherheitslücken.

Zum Vergrößern anklicken....

Das MVC Architekturmuster dient zum Programmentwurf und sagt per se nichts über Sicherheitslücken aus. Um die Sicherheit deiner Anwendung musst du dich selbst kümmern - unabhängig vom Architekturmuster. MVC ist halt in der Webentwicklung stark verbreitet, da es perfekt in die "Lücke" zwischen den verwendeten Systemen passt. Es ist möglich, ohne MVC eine sichere Webanwendung zu schreiben, und es ist auch mit MVC möglich, eine unsicher Webanwendung zu schreiben - da ist kein Unterschied.
Da musst du halt auch die entsprechenden Frameworks darauf abklopfen - Ruby on Rails ist von Anfang an drauf ausgelegt, dass das Framework sicher ist. Wenn dort Sicherheitslücken eingebaut werden, dann (mehr oder weniger) bewusst vom Programmierer - aber diesem soll es einfach gemacht werden, eine sichere Anwendung zu programmieren, und keine unsichere.

Das mag sein, ich verneine ja auch nicht das was du sagst. Ich mache mir nur Sorgen wenn ich mich mit fertigen Sachen anfange zu beschäftige, dass ich den Sinn dahinter nicht verstehen werde oder so ähnlich. Ich bin bei dem Ganzen nun weiter gekommen, ich habe die ganez Systematic schon umgesetzt, wo ich auch sehr viele (für mich) neue Funktionen, Methoden, Techniken etc. benutzt habe dir mir jetzt sehr viel weiter helfen, die Anwendung richtig aufzubauen. Es hat sich leider (oder vielleicht auch "zum Glück") anders ergeben. Über MVC wollte ich mich informieren, aber über sehr viele andere Dinge habe ich auch noch dazu gelernt. Was den Code hier bei der Arbeit nun sehr viel leichter macht.

Und wegen den fertigen Tools:
Es ist ja nicht so dass ich nie etwas benutzen werde, aber wenn ich so etwas mache dann erst Mal bei mir privat, sodass ich damit einigermassen vertraut bin, und erst dann bei der Arbeit. Wie du schon sagtest, ich werde fürs Ergebnis (und wenn möglich nicht all zu lange dauernd) bezahlt und nicht weil ich zu neuen Erkenntnissen gekommen bin.