Irgendwann stand oder steht wohl jeder PHP-Entwickler einmal vor dem Problem der Auswahl eines geeigneten PHP Frameworks. Bis vor einigen Monaten habe ich mich primär mit selbst erstellten Frameworks herum geschlagen. Nicht das die Frameworks schlecht waren, jedoch verspürte ich mehr und mehr den Drang, bekannte PHP-Frameworks kennen zu lernen. Dies ist nicht zuletzt dem Umstand geschuldet, dass am Markt befindliche Ressourcen nicht kompatibel zu selbst erstellten Frameworks sind (der Aufwand und somit die Kosten sind zu hoch).

So fiel meine Wahl zunächst auf ZEND Framework – das Flaggschiff unter den PHP Frameworks. ZEND ist ein sehr mächtiges aber leider auch ein unterirdisch performantes Framework. Die eigenartige auf Grund von PHP Abwärtskompatibilität angewendete Namespace-Implementierung mit Unterstrichen sowie die Komplexität des ZEND-Monsters haben mich jedoch zunehmend abgeschreckt. Mit ZEND gehen viele Dinge, wirklich sehr viele, aber in der Regel brauche ich diese Dinge nicht. Insofern bestand tief in mir der Wunsch nach einem schlankeren, Ressourcen schonendem und gut dokumentierten Framework Ausschau zu halten. Das Framework sollte zudem einfach konfigurierbar und modular verwendbar sein. Die Möglichkeit Extensions zur Erweiterung des Frameworks einzubinden, setze ich als gegeben voraus.

Folgende Komponenten sollte das Framework unbedingt an Board haben:

• MVC
• modular erweiterbar (Module)
• i18n (Mehrsprachigkeit)
• einfache Konfiguration
• ORM einfach austauschbar (falls erforderlich)
• gut aufgestellte Community (wichtig für Extensions und Support)
• gute Dokumentation (sowie im Code als auch im User Guide)
• Access Control & Rights Management
• Unit Tests
• gute Erweiterbarkeit und somit Flexibilität in jeglicher Hinsicht
• Benutzer definiertes URL-Design (Routing)

Sicherlich erfüllen sehr viele PHP-Frameworks oben genannte Ansprüche, allerdings wollte ich nach ZEND einem noch jungen Projekt meine Aufmerksamkeit schenken. So viel mein Blick eher zufällig als gezielt auf Yii. Angestachelt durch den Yii Performance Vergleich mit diversen anderen Frameworks begann ich mich also in Yii einzulesen. Die ersten Tests verliefen zügig und funktionierten ohne Wehwechen – das kannte ich von ZEND auch anders. Module funktionieren von Haus aus, ohne das ich mich in Konfigurationsdateien tot wuseln muss. Selbst Module in Modulen in Modulen … funktionieren ohne groß Schnickschnack veranstalten zu müssen. Das hat mich dann doch sehr beeindruckt.

Das implementierte ORM (AR) ist sehr leistungsfähig, jedoch wie ich finde für Cloud Entwicklung nur bedingt geeignet. Das Problem des ORM ist schlichtweg, dass aus dem Code kein Datenbankschema generiert werden kann (zumindest nicht von Haus aus). Abgesehen davon beherrscht das ORM jedoch alles, was die tägliche Entwicklung benötigt. Mit Dcotrine2ORM, einer Extension zum Implementierung von Doctrine 2.0 in Yii, gibt es die für mich bessere Alternative, die sich ohne Probleme einbinden und nutzen lässt und diesen Missstand behebt.

Nun kann man denken was man will, die Leistungsfähigkeit und Performance eines Frameworks ist lediglich in einem realen Projekt sinnvoll einschätzbar. Von “Hello World” Tests halte ich persönlich nicht viel. Es gilt also ein Exempel zu statuieren, um über zuvor genannte Punkte eine gute Aussage treffen zu können. Ein Vergleich zu anderen Frameworks ist dadurch jedoch auch nur bedingt möglich.

Wie es der Zufall so will, holte ich also eine meiner Ideen aus der Schublade und begann zusammen einem Freund daraus ein Konzept zusammen zu tragen – zunächst alles ohne Yii . Nachdem wir festgestellt hatten, dass sich die Idee umzusetzen lohnt, haben wir sämtliche erforderliche Seiten und Masken als Prototypen Sketches entworfen und von meinem Designer auf Basis dieser Grundlage ein Layout erstellen lassen. Kosten für weitere Dienstleistungen haben wir im Budget natürlich einfließen lassen, denn wenn man etwas macht dann richtig (-> no money no honey).  genug gesülzt…

Die Landingpage zur Registrierung, zum Login, Passwort zurück setzen etc. ist fertig gestellt und ich erlaube mir an dieser Stelle ein Zwischenfazit. Die Entwicklung mit dem Yii Framework macht einem erfahrenen Entwickler wie mir nicht zuletzt wegen der ausgezeichneten Dokumentation sehr viel Spaß. Das Framework erweist sich als sehr gelungen und flexibel erweiterbar. Komponenten und Erweiterungen lassen sich nach Bedarf sehr trivial ein- beziehungsweise abschalten.

Mit einem Speicherverbrauch (LAMP, inklusive Doctrine, i18n, Verwendung von Modulen, APC=on) von 3,5-5,5 MB pro Request für die bisher entstandenen nicht sonderlich komplexen Seiten ist Yii in meinen Augen sehr Ressourcen schonend. Zum (ungleichen) Vergleich – eine WordPress Installation benötigt ohne Zusatzfeatures 14 MB. Mit einigen Plugins sind 32 MB schnell geknackt. Ein Drupal langt mit 15-40MB ebenfalls üppig zu. Zu bedenken ist, dass unter anderem der Arbeitsspeicher die Anzahl synchroner Requests begrenzt. Wenn das System zum Beispiel 30GB für Apache-Prozesse einräumt (entspricht Anzahl Apache max. Connections multipliziert mit PHP memory_limit) komme ich mit meinem Messergebnis auf 30*1024 / 5,5 = 5.585 maximale mögliche Connections zur gleichen Zeit – das ist verglichen mit WordPress (14 MB, 2.194) oder Drupal (20 MB, 1.536) sehr viel. Dieser Wert ist rein rechnerisch zu betrachten und nicht praxistauglich. Hier spielen noch andere Faktoren (IO, Datenbank Connections, etc.) eine Rolle. Allerdings zeigt der Vergleich durchaus auf, dass Ressourcen für andere wichtige Dinge aufgespart werden.

Warum ich meine jungfräuliche Yii-Applikation mit WordPress/Drupal vergleiche? Weil beide geläufige und zuhauf eingesetzte Softwares sind und jeder diese Softwares kennt. Wie bereits geschrieben ist der Vergleich sehr ungleich. Meine Yii Applikation ist natürlich lange nicht so funktionell wie ein WordPress oder ein Drupal. Wenn ich allerdings bedenke, dass Doctrine schon eine fette Sau ist und die Messergebnisse im Debug Modus zu Stande kommen (Logging, Debug Toolbar, etc.), so kommt mir der Speicherverbrauch doch sehr niedrig vor.

Ich nehme dieses erste Posting zum Yii Framework zum Anlass, weiter über meine Erfahrungen mit dem Yii Framework zu berichten.

Stay tuned!

Links:
http://www.yiiframework.com - Yii Framework
http://framework.zend.com/ - Zend Framework

Bevor man sich nun die Arbeit macht, jedes im Quellcode eingebettetes Bild (<img src=”" … >) an das auserwählte Plugin anzupassen, macht ein regulärer Ausdruck hier viel mehr Sinn.

Beim Einsatz von PHP genügt folgender regulärer Ausdruck, um alle Bilder eines Quelltextes für Lightbox beziehungsweise Slimbox anzupassen:

PHP-Snippet

$str = preg_replace (
	"#()#siU",
	"$1",
	$str
);

Worauf kommt es bei einem guten Quelltext an?

Nun zunächst einmal sollte das Dokument möglichst nicht mehrere 1000 Zeilen groß sein. Quelltexte dieser Größe lassen sich nur schwer überblicken. Mehrere kleine Dokumente lassen sich. Nach meiner Erfahrung in Hinsicht auf Teamarbeit und Dokumentation hat es sich oft gezeigt, dass sich das Aufdröseln unterm Strich gelohnt hat. Allerdings trifft das nicht immer zu!

Sinnvolle Benennung von Variablen

Weiterhin sollte ein Programmierer sich bei der Benennung von Variablen lieber 10 Minuten zeit nehmen, anstatt die Programmierung mit Sinn entleerten Variablen Bezeichnungen fort zu setzen. Nehmen wir zum Beispiel an, eine Variable für die Gesamtsumme eines Warenkorbes deklariert werden muss.

PHP-Snippet

$b = 999999.99;

Nehmen wir uns doch etwas mehr Zeit bei der Findung des Variablennamens:
Welchen Wert enthält die Variable? Die Gesamtsumme aller Waren im Warenkorbes…
Inklusive oder exklusive Mehrwertsteuer? inklusive Mehrwertsteuer…

Demzufolge ist es doch ein Einfaches die Variable schlüssig zu benennen oder?

sprechende Variablennamen

$basketSumBrutto = 999999.99;

Einrückung Einrückung und nochmal Einrückung

In vielen Programmiersprachen hat es sich durchgesetzt, mittels Tabulator einzurücken. Das hat den Vorteil, dass ein TAB vom Programmierer in der Regel in seiner Entwicklungsumgebung frei konfigurierbar ist. So kann ein TAB bei einem Programmierer, welche auf Quetschkommode steht, 2 Leerzeichen entsprechen und bei den meisten anderen wird der TAB genau 4 Leerzeichen entsprechen. Es ist jedoch zu beachten, dass der Editor die Entwicklungsumgebung die Tabs beim Speichern nicht in Leerzeichen konvertiert. Denn das wäre dann fatal! Einige Unix Programmierer werden mich jetzt schlagen, aber ich lege mich nachfolgend auf die Einrückung mittels TAB fest.

Betrachten wir uns folgendes Snippet:

unübersichtlicher Quellcode

$sprache="deutsch";
$vorname="Max";
$nachname="Mustermann";
$strasse="Musterstraße";
$hausnr="10";
$plz="01234";
$ort="Musterstadt";

übersichtlicher Quellcode

$sprache  = "deutsch";
$vorname  = "Max";
$nachname = "Mustermann";
$strasse  = "Musterstraße";
$hausnr	  = "10";
$plz	  = "01234";
$ort	  = "Musterstadt";

Und was liest sich jetzt besser? Klar macht es etwas Arbeit, den Code wie eben gezeigt etwas schöner zu gestalten, aber eins ist sicher: Nachfolgend über den Code blickende Dritte haben sehr viel mehr Vergnügen beim Lesen. Und auch der Autor des Quelltextes wird selbst nach Jahren noch sagen – super übersichtlich! Für Entwickler, die innerhalb eines größeren Teams arbeiten, sollte dieser Stil zu guten Pflicht gehören.

Kommentare

Mit dem Kommentaren haben es die wenigsten Programmierer. Die meisten setzen der Einfachheit gar keine Kommentare. Autsch! Viele Programmierer, die dann doch Kommentare setzen, meinen es mit dem Kommentieren aber leider zu gut. Zum Beispiel sind solche Kommentare hier völliger Blödsinn und können getrost weg gelassen werden.

unsinnige Kommentare

// Sprache des Clienten
$sprache  = "deutsch";
// Vorname des Clienten
$vorname  = "Max";
// Nachname des Clienten
$nachname = "Mustermann";
// Straße des Clienten
$strasse  = "Musterstraße";
// Hausnummer des Clienten
$hausnr      = "10";
// Postleitzahl des Clienten
$plz      = "01234";
// Ort des Clienten
$ort      = "Musterstadt";

Kommentar für gesamten Block

// Clientendaten für Musterdatensatz
$sprache  = "deutsch";
$vorname  = "Max";
$nachname = "Mustermann";
$strasse  = "Musterstraße";
$hausnr	  = "10";
$plz	  = "01234";
$ort	  = "Musterstadt";

Doch wo machen Kommentare eigentlich Sinn?

Ganz einfach. Kommentare sollten Codestrukturen beschreiben, die nicht selbsterklärend sind. Das können zum Beispiel Funktionen, Klassen oder größere Codeblöcke sein. Hier bietet es sich jedoch an, die Kommentare zu konsolidieren beziehungsweise zu bündeln (der Code und der Kommentar sind examplarisch zu sehen).

Beispiel sinnvoller Kommentare

// Berechnung der Gesamtsumme aller Waren innerhalb des Warenkorbs
// Die Beträge in Array $basketItems liegen netto vor! Das Array
// $basketItems enhält folgende Struktur:
// 	[][item] =>
//		[
//			[id] 	=> int,
//			[menge] => int,
//			[preis] => double
//		]
$basketSumNetto  = 0;
$basketSumBrutto = 0;
foreach ($basketItems as $key => $item_x)
{
$basketSumNetto += $item_x ['menge'] * $item_x ['preis'];
}
$basketSumBrutto = $basketSumNetto * 1.19;

• PHPDoc für PHP
• Javadoc für Java
• Rubydoc für Ruby
• PythonDoc für Python

Es gibt quasi für nahezu jede Programmiersprache ein passendes Pendant. Der Vorteil dieser Tools ist neben der Standardisierung die entstehende Quelltext Dokumentation in Form einer übersichtlichen Ansammlung von sämtlichen dokumentierten Quellcode. Beispiel für PHPDoc

Was wir gelernt haben

Es ist nicht entscheidend, eine Quellcode möglichst schnell zu programmieren, sondern möglichst gut lesbar, dokumentiert, durchdacht und fehlerfrei. Die Zeit, die man zur Optimierung des Quelltextes verwendet, spart man sich später beim Debugging oder bei anstehenden Erweiterungen am Quelltext. Man sollte sich als Programmierer einen programmierten Quellcode nach etwas längerer Zeit mit etwas Abstand nochmals ansehen und nach dokumentieren. Das Problem ist nämlich eine Betriebsblindheit. Seinen eigenen Quellcode kennt man zum Zeitpunkt des Schreibens immer. Daher erscheinen viele Dinge logisch, sind es jedoch ganz und gar nicht.

Ich habe mir all diese kleinen Dinge in einem tollen Team angelernt. Natürlich sollten beim gemeinsamen Arbeiten innerhalb eines Teams viele weitere kleine Details schriftlich fixiert und als Style Guide oder wie auch immer man dieses Dokument bezeichnen mag zur Verfügung gestellt werden. Ansatzpunkte könnten hier sein:

• Variablen Buckelschreibweise oder Unterstrichschreibweise
• Festlegung der zu verwendenden Kommentarsyntax (z.B. PHPDoc)
• Codestruktur (z.B. oben Logik unten Ausgabe)
• Instanzen von Objekten mit großen ANfangsbuchstaben

Ein Brainstorming innerhalb eines lockeren Teammeetings wird noch viele weitere Punkte auf die Liste bringen.