Archiv der Kategorie: code smells

Sinnlos

wiesinnvoll

CRUD – Theorie und Praxis

CRUD, dieses Vorgehen sollte eigentlich jeder kennen … falls nicht, CRUD ist die Kurzform für „Create, Read, Update and Delete“ und ist vereinfacht gesagt als Checkliste zu sehen und gilt nicht nur für PHP.

Du hast in deiner Anwendung zum Beispiel eine Liste aller User, die soll editierbar sein. Du kannst nun CRUD als Checkliste benutzen und einzeln abhaken:

  • Create: Kann ich neue User erzeugen? Check!
  • Read: Kann ich eine Liste aller User ausgeben UND kann ich im Editfall einen User darstellen? Check!
  • Update: Kann ich die Daten eines Users ändern? Check!
  • Delete: Kann ich einen User löschen? Check!

Hast du bei allen ein „Check!“, dann bist du technisch auf dem Mindestlevel angelangt. Herzlich Willkommen 😉

Soviel zu Theorie. In der Praxis sehe ich es leider oft, dass CRUD viel zu wörtlich genommen wird. Besonders das C und das U sehe ich oft als zwei Dinge in der Anwendung.

Warum nun ist das schlimm? Nun, ich arbeite mit Legacy-Anwendungen. Diese sind teilweise vor vielen Jahren begonnen und verrichten bis heute ihren Dienst. Innerhalb dieser Anwendungen gibt es immer wieder den Fall, dass eine Datensatzart die CRUD Bedingung erfüllen muss, d.h. ich habe eine Liste von (Beispiel) Usern oder Kunden, die kann man ändern, die kann man neu erzeugen, die kann man löschen usw.

Nun mein Appell an alle: Bitte, fasst C und U zusammen. Bitte!

Es gibt nichts schlimmeres, als dass man ein „create“ Script und ein „update“ Script hat, beide machen im Prinzip das gleiche (Prüfung der Daten, Normalisieren der Daten usw.), aber im Endeffekt hast du 2 Scripte. Du hast also „duplicate code“. Und das ist nicht nur „bad smell„, dies ist einfach nur „bad style“. Eine Änderung an der Logik der User (Stichwort neues Feld) und du musst beide Scripte aktualisieren. Falls deine Anwendung mehrere solcher Listen hat und das neue Feld mehrere betrifft darfst du die „2“ gern entsprechend faktorisieren.

Also, bitte, bau die ein „edit“ Script, prüfe die Variablen, normalisiere diese und mache alles fertig. Dann nur noch die Unterscheidung „neu“ oder „ändern“ und gut ist. Das sind aus meiner Erfahrung nur ein if-else (oder switch) und das entsprechende SQL-Kommando. Die Ausführung des Kommandos ist dann ja wieder das selbe und kann außerhalb der Verzweigung stehen.

Dieses eine Script läßt sich jetzt viel leichter skalieren, verstößt nicht mehr gegen den „copy paste detector“ und läßt dich einfach ruhiger schlafen.

Just my 2 cent ….

include oder require?

Was soll der PHP-Entwickler benutzen, include oder require bzw. include_once oder require_once?
Und wo liegt da eigentlich der Unterschied?

Die Frage kommt oft, deshalb an dieser Stelle mal ganz klipp und klar und kurz:

require bzw. require_once benutzen, denn: Sowohl include wie auch require binden eine Datei ein, aber, sollte ein Fehler in der includierten Dateie sein, so bricht require mit einem E_COMPILE_ERROR ab, während include fröhlich mit einer WARNING weitermacht.

Im Sinne der Vermeidung von code-smells fällt eure Wahl also auf require bzw. require_once.

Schneller in PHP und MySQL mit JOIN

Mittels einfacher Kentnisse seiner Datenbank kann der Entwickler auch aus Legacy-Anwendungen sehr viel mehr Geschwindigkeit herausholen, als er vielleicht weiß.
Der Grund ist simpel: Meist bleibt der Code gleich, aber die Server Software wird aktualisiert. Während die Erstellung noch im guten alten PHP4 + MySQL4 von Statten ging, rennt der Code heute mit PHP5 + MySQL5 zwar immer noch, könnte aber dank kleiner Kniffe sehr viel schneller sein.
Ich möchte euch einen Weg dazu zeigen, die JOINs in MySQL. Es gibt sicherlich noch mehr Möglichkeiten, aber das sind auch andere Themen. Fangen wir heute mal mit alten Querys an.

Zunächst versuchen wir eine Stelle zu finden, an der wir ansetzen. Bei den meisten Legacy Codes wurde mit solch einem oder einem ähnlichen Konstrukt die Daten für „Zeige neue Blogbeiträge mit Namen des Autors“ abgerufen, wobei „autor“ und „blog“ zwei verschiedene Tabellen sind.

$_res = mysql_query("SELECT * FROM blog ORDER BY datum DESC");
while ($row = mysql_fetch_array($_res)) {

  $_resAutor = mysql_query("SELECT * FROM autor WHERE autorid = ".$row['autorid']);
  $autor = mysql_fetch_array($_resAutor);
  // Stelle Blogbeitrag mit Autor dar
}

Das ist nicht nur in der Hinsicht des Datenabrufes schlechter Code und vor lauter „code-smells“ könnte einem glatt schlecht werden. Trotzdem gibt es sowas „da draussen“ und dummerweise funktioniert das leider immer noch.

Was kann man verbessern? Zum einen fällt auf, dass es zwei Querys sind. Das muss nicht nur nicht sein, dass ist auch noch ganz schlecht, denn jede Verbindung zur Datenbank braucht Zeit und die sollten wir uns sparen. Argumente wie „mysqli / PDO benutzen“ lasse ich ganz bewusst aussen vor, es soll um Prinzip gehen (sicher wäre die Verwendung eines PDO oder ORM wie Doctrine besser, ganz klar).

Sparen wir uns also den zusätzlichen Query:

$_res = mysql_query("SELECT b.*, a.* FROM blog b, autor a WHERE b.autorid = a.autorid ORDER BY b.datum DESC");
while ($row = mysql_fetch_array($_res)) {
  // Stelle Blogbeitrag mit Autor dar
}

Schon viel besser, aber noch nicht gut genug. Was passiert, wenn ein Blogbeitrag existiert, aber der Autor nicht? Bei so einer Legacy-Anwendung fast schon der Normalfall. Der ganze Beitrag fehlt. Doof, also brauchen wir eine Mechanik, die trotz fehlendem Autor den Blog Beitrag noch anzeigt.
Ganz kurz: Das machen JOINs – und ehe ich nun von vielen gesteinigt werde: JOINs machen noch viel mehr, aber das würde hier den Rahmen sprengen und außerdem möchte ich dazu noch mehr schreiben.

Das ganze nun mit einem LEFT JOIN:

$_res = mysql_query("SELECT b.*, a.* FROM blog b LEFT JOIN autor a ON (b.autorid = a.autorid) ORDER BY b.datum DESC");
while ($row = mysql_fetch_array($_res)) {
  // Stelle Blogbeitrag mit Autor dar
}

Es ändert sich nicht viel, aber nun erscheinen auch alle Blogbeiträge ohne Autor und als kleines Extra arbeitet der letzte Query auch noch etwas schneller als der zweite; super für Legacy-Code, der schon ähnlich wie in Beispiel Zwei aufgebaut ist, denn dort muss man nicht – oder nur wenig – an den PHP Code ran und kann sich auf die reine SQL-Optimierung konzentrieren.

Diese Art der Optimierung alter Legacy-Anwendungen macht relativ wenig Arbeit und bringt dafür recht viel. Vor allem im Bereich von SQL-Code, wo Beispiel eins mehrfach vorkommt (Grundquery, dannach werden viele Querys gestartet die Detaildaten zum Grundquery abrufen, dannach wird gerechnet und wieder neue Querys abgerufen usw.) und damit die Anwendung an dieser Stelle nur sehr langsam ist, kann ein Umstieg auf JOINs und u.a. Verlagerung von Arbeit von PHP in den Query sehr viel Geschwindigkeit herausholen.

Allerdings – und das sollte ganz klar sein – kann dies keine schlechte Architektur ersetzen. Legacy Code kommt irgendwann an den Punkt, an dem ein Optimieren keinen Sinn mehr macht und man sich lieber auf die Neukonzeption konzentrieren sollte. Als Hilfsmittel, um z.B. langsame Bereiche zu beschleunigen, sollte man die Kentnisse allerdings auffrischen. Vor allem, da bei modernen Methoden (PDO, OML, …) die JOINs eine zentrale Rolle spielen.

Windows Developer System – Die Grundlagen (01)

Ich stelle euch hier vor, wie ihr Stück für Stück eine professionelle PHP-Entwicklungsumgebung unter Windows erstellt und das ganze ohne besonders viel Aufwand. Die meisten Tutorials in dieser Richtung – zumindest die, die ich kenne – gehen immer davon aus, dass ihr Linux benutzt – und wenn doch mal Windows erwähnt wird, dann meist mit dem Seitenhieb, doch mal endlich ein „richtiges“ Betriebssystem zu benutzen.

Ich selbst habe 2 Maschinen, beide mit Windows7, und dieses Tutorial basiert daher natürlich auf dem Betriebssystem Windows. Ihr könnt aber davon ausgehen, dass ihr, wenn ihr unter Windows entwickeln wollt, keine Einschränkungen gegenüber den Linux-Leuten habt, ihr habt nur andere Kommandos – auch wenn die Pinguine euch manchmal was anderes erzählen wollen. Am Ende ist doch eh nur der Code wichtig und der läuft sowohl unter Windows wie unter Linux.

Anfangen möchte ich mit einem Überblick und nötigen Grundlagen, alles weitere kommt dann Stück für Stück. In jedem Teil findet sich ein Inhaltsverzeichnis mit den jeweils anderen Folgen dieser Serie.

Auf jeden Fall wünsch ich euch viel Spaß beim lesen und viel Erfolg beim Umsetzen.

Inhaltsverzeichnis:

Windows Developer System – Die Grundlagen

Zuallererst brauchen wir natürlich ein Windows, welches auch immer. Es sollte im Prinzip auf jedem Windows ab XP funktionieren, testen kann ich – wie oben schon erwähnt – nur auf Win7; Kommentare zu anderen Windows-Varianten wie z.B. Vista, XP oder sogar Win2000 wären nett 😉

Linuxianer oder Mac-User dürfen natürlich gern mitlesen. Bei den Anleitungen zur Installation werde ich aber gnadenlos Windows-lastig sein, dafür könnte sich das Mitlesen bei der Benutzung von PEAR und den damit verbundenen Code-Analyse-Tools aber lohnen. Mein Tipp: Dabeilesen ist alles 😉

Eure Festplatte sollte noch ein paar MB oder besser GB Platz haben, natürlich vor allem für die „große“ Software wie den Webserver und die lokale Datenbank, als auch für eine professionelle IDE … die Puristen unter euch können natürlich auch weiterhin im Notepad2, Notepad++ oder dem Programmers Notepad arbeiten; viele Features einer IDE können einem Entwickler in der täglichen Arbeit allerdings sehr viel lästige Arbeit abnehmen (siehe die 10 Regeln für Entwickler – Punkt 3).

Die Frage an dieser Stelle lautet: „Warum sollte ich das machen?“. Die Antwort ist trivial: Weil es deine Arbeit verbessert und erleichtert, weil es dir viele Möglichkeiten gibt, dich selbst und deine Fähigkeiten zu verbessern. Und bestimmt noch mehrere Dutzend Antworten, die dir aber auch alle im Laufe dieses Tutorials klar werden. Darum!

Von hier aus geht es nun also nahtlos weiter zum nächsten Punkt, dem downloaden und installieren des lokalen Webservers.