Bestimmt kennt jeder von euch solche Muster, die er in seinem Code lieber nicht finden will. Heute will ich mal mit dem “Include Smell” anfangen. Wenn ich ein größeres Projekt starte, dann will ich dies objektorientiert angehen. Alle Logik ist also in Klassen verpackt und keine “losen” Aufrufe liegen irgendwo rum. Zumindest stelle ich mir das so vor. Wenn ich strikt mir Klassen arbeite, dann verwende ich include_once oder require_once, denn jede Klasse muss ich dem System gegenüber nur ein mal vorstellen und kann es dann nutzen. Ich brauche also auf keinen Fall die Möglichkeit eine Datei doppelt zu inkludieren.

Jedes vorkommen von include, das in der Business-Logik vorkommt, lässt also auf eine kaputte OOP schließen. Solche Stellen kann man also suchen und analysieren. Gerne kann man auch einen PHP_CodeSniffer Sniff verfassen, ob man aber so weit gehen muss, weiss ich nicht. Ich habe übrigens explizit diesen Smell auf die Busines Logik begrenzt, da man, glaube ich zumindest, im Templating System also der View auf solche includes nicht verzichten will. Wie seht ihr das? Ist jedes vorkommen eines includes, das nicht einfach durch ein include_once ersetzt werden kann ein schlechtes Zeichen und stinkt?

Wahrscheinlich werden diese Code Smell all denen liegen, die auch mit Metriken etwas anfangen können, weil beides in Richtung statische Code-Analyse zielt. Wer Metriken nicht aussagekräftig findet, der wird wahrscheinlich auch mit den Code Smells nicht so viel anfangen können. Auf jeden Fall werde ich in den nächsten Tagen noch was über mixed als Rückgabewert schreiben und auch ein wenig meine Aussage über Kommentare im Code von damals verfeinern. Ach ja die übermäßige Verwendung von Arrays wird auch noch ein Smell werden.

PS: Es kann übrigens sein, dass ich schon mal einen ähnlichen Artikel verfasst habe, aber ich wollte im Zuge der Code Smell Reihe noch einmal das ganze auffrischen und mir war da einfach nach.

Da aber heute der Artikel live geht, den ich gestern geschrieben habe, habe ich natürlich nicht gearbeitet (logisch?!). Deswegen dürft ihr euch noch mal eine Weisheit anhören, die eigentlich von Joel Spolsky stammt, von mir aber auf jeden Fall bestätigt werden kann. Es geht um die Installation von Software. Ich nenne es die “One-Click Installation”. Dabei geht es darum, dass eure Software ohne Probleme installiert bzw. gebaut werden kann. Stellt euch mal vor, ihr programmiert an einem bestimmten Projekt, wie zum Beispiel www.heise.de. Um das Projekt lokal auf eurem PC zu laufen zu bringen müsstet ihr jetzt alle Einstellungen, die das System benötigt von Hand einstellen. Ich tippe mal drauf, dass das eine ganze Menge sind und dass vielleicht ein oder zwei Leute auf dieser Welt dies können. Tja dumm gelaufen, wenn man es selbst machen muss und nicht zu den zwei Personen gehört.

Ich habe schon an einigen Projekten gesessen, da hat es Stunden gedauert eine Webseite aufzusetzen, bis sie tatsächlich lief. Das dumme daran war, der Ablauf war immer genau der gleiche! Und alles was immer das gleiche ist, kann man auch in Automatismen packen. Wir basteln uns also “einfach” ein build-Skript, dass den ganzen Kleinscheiß für uns erledigt und wir setzen uns danach einfach hin und tippen “ant” (kann natürlich auch make oder so etwas sein) ein. Wie immer bei automatisierten Abläufen wird die Aufzeichnung erst mal Zeit kosten, die ihr aber schnell wieder drinne haben solltet. Hier gilt es natürlich für euch zu entscheiden, wie oft ihr das System aufsetzen müsst und wie sehr ihr von dem Wissen einer Person abhängig seid. Bei den meisten Projekten, in denen ich involviert war, haben wir es zum Schluß hinbekommen uns ein ant Skript zu basteln, das die Anforderunegn erledigt hat.

Natürlich ist diese Anforderung nicht ganz so selbstlos. Im Qualitätsmanagement in der Softwareentwicklung ist der Continuous Integration Prozess meiner Meiner Meinung nach einer der wichtgsten. Nach jedem Commit wird dort das komplette System gebaut und alle Tests gegen die aktuelle Version gefahren. Auch hier spielen Automatismen eine wichtige Rolle. Müsste ich jedes mal, wenn sich was am System ändert (ein ALTER TABLE in der DB reicht ja bereits schon) meinen Continous Integration Server anfassen, würde ich ziemlich schnell einen an der Waffel bekommen (derzeit betreuen wir ca. 30 Webseiten). Das muss also alles automatisch passieren.

Mir fällt gerade ein, dass ich mal die Woche der Automatismen ausrufen könnte, aber vielleicht auch nicht. Mich würde auf jeden Fall mal interessieren, wer von euch so ein Installations Skript für sein System hat. Wie immer wartet die Kommentarfunktion also auf euch.

Durch diverse doofe Umstände, war ich nicht in der Lage den Server selbst neu zu starten (was sich jetzt aber geändert hat). Was macht man also in den 3 Stunden voller “Panik” ohne durchzudrehen? Man überlegt sich, was man alles im Backup drinnen hat und was verloren geht, falls der Server gar nicht mehr hochfährt. Meine Sourcen habe ich noch mal zu hause, da ich ja dort entwickle. Bei der Datenbank sieht es anders aus. Die gibt es nur live und im wöchentlichen … na gut wem mache ich was vor, eher im monatlichen Rhythmus gibt es ein Backup. Nach so einem Schock ist man natürlich eine Woche lang hoch sensibel auf das Thema zu sprechen, danach nicht mehr so. So sind zumindest meine Erfahrungswerte. Was muss also her? Ein automatisches Backup und das jeden Tag.

Um ein effizientes Backup zu erstellen, muss man erst mal wissen, wie Wordpress seine Daten strukturiert. Zum Glück ist das eigentlich ganz einfach. Das “Userland” befindet genau in einem Verzeichnis “wp-content“, dass sich direkt um Hauptverzeichnis befindet. Hier landen die installieren Plugins und die Themes, die man in liebevoller Kleinarbeit mundgeklöppelt hat. Dieses Verzeichnis ist das einzige auf der Platte, welches man nicht mit einer normalen Wordpress Installation wieder herstellen kann, zumindest inhaltlich. Fast hätte ichs vergessen: Im Upload Verzeichnis liegen noch die Bilder, die ihr zu euren Artikel hochgeladen habt. Ist vielleicht auch nicht so uninteressant.

Bei der Datenbank kann man getrost alles mit ins Backup werfen, da der größte Speicherfresser eh die Artikel und die Entwürfe sind und die sollten ja auf jeden Fall täglich den Weg ins Backup finden. Bei mir sind es noch ein paar Zusatztabellen, da ich ja selbst ein wenig an meinem Wordpress rumgeschraubt habe.

Wir haben also zwei Verzeichnisse und eine Datenbank zu sichern. Wordpress wäre aber nicht Wordpress, wenn es das nicht alles schon in einem Plugin vorgefertigt geben würde. Ich habe mich gestern für zwei verschiedene entschieden. Das eine sah sehr gut aus für die Datenbank und das andere kümmert sich um die Verzeichnisse. Ich bin gespannt, ob alles klappt. Zuminbdest fühle ich mich jetzt wieder sicher.

Ich weiß, ich predige immer sauber zu arbeiten und dann mache ich kein Backup! Asche auf mein Haupt. Ich gelobe Besserung.

Kurz vorne Weg nochmal ein ganz kurzer Abriss über das Testen mit Selenium. Was wir damit prüfen sind hauptsächlich Eigenschaften von definierten HTML Elementen wie Divs oder Select Boxen. Wir können also auf das Vorhandensein eines bestimmten Textes innerhalb eines Divs prüfen. Soviel erstmal dazu.

Jetzt muss ich aber erstmal definieren, welches Element meiner Seite diesen Text beinhalten muss. Dank Selenium habe ich da diverse Möglichkeiten. Eine davon ist der XPath des DOM Dokuments, das die HTML Seite repräsentiert. Ein Pfad könnte dann wie folgt aussehen: //div[1]/div[3]/div[3]/a. Nicht wirklich aussagekräftig, aber eigentlich eine Standardmethode. Das Problem dabei ist, dass sich der Pfad bei der Entwicklung der Seite auf mitentwickelt. Falls ein neues Element in den Header der Seite eingebaut wird, dann besteht die Chance, dass sich der gesamte Pfad ein Stück verschiebt. Ein Rechtsshift sozusagen. Xpath ist also nur eine gute Idee, falls die Seite wirklich stabil bleibt. Aber das Internet ist schnelllebig und deswegen können und sollten wir uns das doch lieber abschminken, falls wir nicht bei jeder Änderungen unsere Tests anfassen wollen.

Was wir brauchen sind also stabile Ankerpunkte, an denen wir anknüpfen können. Für ein solches System eignen sich IDs hervorangend. Selenium hat nämlich die Möglichkeit Elemente über den xpath:idRelative zu identifizieren. Pfade sehen dann eben nicht mehr wie oben aus, sonder //div[@id='meineID']/div[1]/a. Der große Vorteil, den wir hiermit gewinnen ist eine erhöhte Stabilität der Tests. Jetzt kann sich die ganze Seite um mein Element verändern, solange mein Pfad von der gegebenen ID zu meinem Element stabil bleibt bin ich auf der sicheren Seite. Und wenn sich das doch verändert, muss ich nur noch einen Bruchteil meiner Tests anfassen.

Was sagt uns das also. Als vorgehensweise würde ich empfehlen bei Neuentwicklung gleich IDs zu verwenden um Inhaltsblöcke einzugrenzen. Es muss nicht jedes DIV eine id bekommen, aber die Gruppe in der es sich befindet sollte eine solche besitzen. Bei Altlasten würde ich jetzt nicht nachträglich alles mit IDs versehen. Einfach bei Bedarf nachliefern. Ich schreibe einen Regressionstest, also brauche ich auch eine neue ID. Ganz einfach.