Dieses Grundprinzip ist das, was Ruby eigentlich so bekannt gemacht hat. Was dafür gesorgt hat, dass man eine Applikation mit Rails in wenigen Minuten aufbauen kann (Scaffolding) und nur noch der Feinschliff gemacht werden muss. Aber was bedeutet conventions over configuration genau und wie kann man es auf PHP anwenden?

Ruby abstrahiert bei der Webentwicklung ständig auftretende Probleme und löst diese Eiheitlich. Auf eine MVC-Struktur bezogen hätten wir folgenden Fall: Wie haben es ständig mit Modellen zu tun, die eigene Controller bekommen. Diese Modelle werden in der Datenbank gespeichert und sollen über den controller aufgelistet, angelegt und einzeln editiert werden können. Statt das also für jedes Modell immer und immer wieder von Hand zu machen, gibt es in Rails ein Script, dem man den Namen und die Properties für das Model übergibt und das alles selbst anlegt.

Hierbei kommt dann obiges Prinzip zum Einsatz: Convetions over configuration. Statt also in der Modellklasse anzugeben, in welcher Tabelle die Daten für dieses Modell liegen (configuration), nimmt die Modellklasse an, dass die Daten in einer Tabelle liegen, die dem Plural des Modells entspricht (convention). Das Modell “article” wird seine Daten also in der Tabelle “articles” finden.

Dieses Prinzip setzt sich natürlich weiter fort. Ich möchte gar nicht weiter auf das konkrete Rails-Beispiel eingehen. Ich habe das Buch noch gar nicht zuende gelesen und laufe Gefahr, hier Lösungen für Probleme vorzuschlagen, die Rails wesentlich besser gelöst hat. Viel interessanter ist die Frage: Wie führe ich das in PHP ein?

Obiges Beispiel ist noch sehr einfach. Die Umsetzung sollte jeder, der seine Brötchen mit PHP verdient hinbekommen. Es gibt aber meiner Meinung nach eine ganze Reihe von Fällen, in denen solche Konventionen abgelehnt werden, da sie die Applikation ihrer Flexibilität rauben: Prominentes Beispiel sind Benamungen von Tabellenspalten in Datenbanken. In der Vergangenheit musste ich häufiger erleben, dass eine Benamung von Fremdschlüsseln im Sinne von “<zieltabelle>_<zielfeld>” zzgl. evtl. führender Zieldatenbank abgelehnt wurde. Konkrete Argumente fehlten oder beruhten auf mythischen “Ich meine mal gehört zu haben … ” und “da hatte ich mal Probleme mit, die ich jetzt aber nicht mehr erklären kann … ” Argumenten.

Ich sehe leider auch immer wieder, dass Methodenparameter so angeordnet sind, dass man um häufig genutzte Parameter zu erreichen andere übergeben muss, obwohl diese sich selten Ändern oder ermittelbar wären. Um das zu vermeiden, wird hier dann häufiger auf ein Array zurückgegriffen, in dem nur die Parameter, die man setzen will übergeben werden. Das ist augenscheinlich eine gute Lösung, leider kann einem die IDE dann keine Unterstützung mehr bzgl. der Typen oder generell der DocSyntax mitgeben. Sinnvoller wäre hier aber, dass man so wenig Parameter wie möglich übergeben muss. Lediglich wenn etwas mal nicht mehr der Konvetion entspricht, sollte man auf Konfiguration zurückgreifen.

Das beißt sich jetzt auch alles ein bisschen mit Nils’ Assert Null Artikel

Hiermit möchte ich heute eine neue regelmäßige Kategorie eröffnen: Meine Buchtipps. Als Bahnfahrer bin ich jemand, der viel liest. Nach dem ich morgens also meinen Newsreader zum Schweigen gebracht habe, sind Bücher oder Magazine dran (erwähnte ich eigentlich schon, dass ich zu viele Abos habe? ). Da dann auch des öfteren Fachliteratur darunter ist, dachte ich mir: Warum nicht hier ein paar Buchtipps präsentieren? Beginnen möchte ich mit einer Leihgabe meines Arbeitskollegen Mario: Produktiv programmieren von Neal Ford.

Neil Ford: Produktiv programmieren

Diese Fundgrube an Optimierungstipps und geballter Erfahrung hat sich mein Arbeitskollege in der Mittagspause geholt, ich habe es auf seinem Schreibtisch entdeckt, warf einen Blick in das Inhaktsverzeichnis und war direkt vom Kapitel “böse Affen” fasziniert. Kurz aufgeschlagen und gelesen. Wow. Das liest sich gut, ist wie aus dem Alltag gegriffen und darüber hinaus auch noch amüsant. Ähnliches dachte sich mein Arbeitskollege, der das 270 Seiten starke Werk schon nach ein paar Tagen wieder mitbrachte – und ich es mir krallen konnte.

Die ersten Kapitel lesen sich wie aus einem GTD-Werk, handeln sie von Shortcuts, wie man sich auf seinem Rechner besser und schneller zurechtfindet und einer ganzen Reihe von Anekdoten. Ford erklärt, wie man Mechanismen automatisieren kann (Ford nutzt Selenium übrigens wie ich nicht nur zum testen). Mehr und mehr wird einem jedoch bewusst, dass die Dinge, die dort beschrieben werden, einem täglich einen beträchtlichen Konzentration rauben.

Verhaltens-, Konzeptions- und auch praktische Programmierszenarien werden erstellt und praktisch sowie effizient gelöst. Dabei hinterfragt Ford sich selbst ständig.

Alles in allem ein Buch, dass ich jedem Entwickler nur empfehlen kann. Man wird sofort eine Reihe von Tipps in seinen Alltag mitnehmen und zu schätzen lernen. Damit hätten wir einen zweiten Meister der Effizienz, der den Nachnamen Ford trägt.