Archiv für den Monat: Juni 2013

Hat YAGNI ausgedient?

2 Antworten

Ich las eben einen interessanten Artikel im phpMagain online. In „Abwärtskompatibilität vs. langfristiges Planen“ geht es über einen Blogbeitrag von Anthony Ferrara, in der dieser u.a. darüber schreibt, dass er die Optionen seiner Funktionen als array anlegt, obwohl das ja teilweise gar nicht sein müsse. In die Zukunft gesehen macht es aber Sinn, da ja bald neue Optionen hinzukommen werden, da sich jede Software weiterentwickelt und seine Funktion somit flexibel ist und ihre Signatur sich nicht weiter ändern muss.

Allerdings, und das steht ja auch im Artikel des phpMagazins, wiederspricht dies dem YAGNI Prinzip, das – vereinfacht – besagt, dass du alles, was du aktuell nicht brauchst, auch nicht entwickeln sollst.

Ich finde, dass passt dann nur auf Software, die du einmal entwickelst und die dann einfach vor sich hin altert. Software, die du vorher im Detail planst und dann nie wieder ansiehst. Kurz, Software, die hoffentlich heute in der Form nicht mehr gebaut wird.

Heute verändert sich Software stetig und ständig, „und das ist auch gut so“, denn sonst würden wir alle niemals Updates installieren müssen. Aber im Gegenteil müssen wir heutzutage so viele Updates installieren, dass manchen Hersteller gar nicht mehr nervt fragt, sondern uns ganz bequem mit „Silent updates“ auf dem neuesten Stand hält.

IMHO werden Anwendungen und Webseiten heute um ein vielfaches schneller und öfter aktualisiert wie noch vor wenigen Jahren. Und Software, die aktualisiert wird, wird oft auch erweitert. Es werden ja nicht nur Sicherheitslücken geschlossen oder Bugs gefixed, es kommen oft auch neue Features und Funktionen hinzu, altbekanntes fällt manchmal weg, kurz: Die Software verändert sich und damit auch ihr Code, ihre Funktionen und dessen Signaturen.

Was hat das nun mit YAGNI zu tun? Nun, YAGNI würde besagen, dass man eine Funktion minimalst aufbauen soll, ein Beispiel, eine Funktion liefert uns Benutzerdaten aus einer Datenbank:

public function getUser() {
//...
}

Diese Funktion würde alle User zurückliefern. Im Laufe des Lebens der Anwendung merken wir, dass ein Filter auf „getUser()“ wohl sinnvoll wäre, also ändern wir die Signatur:

public function getUser($id)

liefert nun genau einen User mit einer speziellen Id.

public function getUser($id = -1, $name)

kann nun auch einen User nach Namen liefern, wenn wir id auf -1 setzen.

public function getUser($id = -1, $name, $nameAsLike)

kann nun auch – bei $nameAsLike=true und id=-1 – einen Namen „teilweise“ liefern.

Diese Liste ließe sich nun bestimmt weiter fortsetzen, ihr kennt das sicher alle. Sicher entspricht dies dem YAGNI Prinzip, denn im Laufe der Versionen der Software kam immer nur genau so viel dazu, wie unbedingt erforderlich war. Aber war das gut so?

Vorausschauender wäre es gewesen, sich kurz Gedanken zu machen und dann zu entscheiden

public function getUser(array $options=array())

Nun kann dort auch jeder der obigen Evolutionsschritte der Software eingebracht werden, die Signatur der Funktion braucht allerdings dazu nicht geändert zu werden und damit gibt es auch weniger potentielle Fehlerquellen im Rest des Codes.

Vielleicht müssen wir vom starren YAGNI weg, hin zu einem YDNNI, einem „You Defenitly Not Need It“, einem Paradigma, dass es erlaubt, vorausschauend zu Entwicklen, dass einem aber trotzdem untersagt, völlig Sinnfreie oder sogar Kontraproduktive Dinge zu entwickeln.

Die Sache mit dem array scheint sich langsam aber sicher dank oder trotz YAGNI zur „Best Practice“ durchzusetzen. Setzt ihr Optionen auch als array um oder benutzt ihr da völlig andere Wege?

 

PHP – foreach „greift“ nicht, keine Iteration

6 Antworten

Kleiner Hinweis: Wenn bei euch eine „foreach“ Schleife nicht greift, obwohl alles richtig zu sein scheint – das array ist da, Werte sind drin, sogar die richtigen 😉 – und trotzdem keine Iteration über das array stattfindet, dann sucht mal vor Ausführung des foreachs nach array-Iterations Funktionen, die das komplette Array durchlaufen, z.B.: array_map, array_walk, usw.

Die Ursache ist: Durch den kompletten Durchlauf des Arrays steht der interne Pointer (wir erinnern uns dunkel, PHP ist in C/C++ geschrieben) immer noch auf dem letzten Element, die foreach-Schleife kann also nicht loslaufen, weil Sie – rein technisch – schon am Ende ist und „überspringt“ das foreach.

Die Lösung ist trivial: Nach der Iterationsfunktion oder direkt vor dem foreach setzt ihr

reset($myArray);

Das reset setzt euer Array intern wieder auf das erste Element und schon funktioniert eure foreach-Schleife wieder – die C/C++ und Java-Entwickler kennen das Problem 😉

Rezension: Softwarequalität in PHP-Projekten von Sebastian Bergmann und Stefan Priebsch, 2. Auflage

Eine Antwort

Man kann sich viele Bücher zum Thema Qualitätsverbesserung in IT-Projekten zulegen, manchmal kann man während der Lektüre sogar was lernen, in den wenigsten Fällen hat man es dabei mit konkreten Programmiersprachen zu tun und noch viel weniger sind in Deutsch.
Da scheint es ein wahrer Lichtblick zu sein, dass zwei der bekanntesten PHP-Experten das Standardwerk zur Qualitätsverbesserung und -sicherung noch einmal überarbeitet haben, teilweise sogar neu geschrieben haben. Herausgekommen ist ein absolutes „must-have“.

Sebastian Bergmann und Stefan Priebsch beschreiben auf circa 460 Seiten, worauf der Qualitätsbewusste PHP-Entwickler achten muss und soll. Angefangen vom „Was ist denn eigentlich Qualität und wie kann man diese Messen?“ über „und warum ist das wichtig?“ bis hin zum „Wie sag ich’s meinem Kunden“ schreiben beide in einem lockeren Stil über eines der komplexesten Themen innerhalb des Programmieralltags.

„Softwarequalität in PHP-Projekten“ ist sicherlich kein Buch zum einfachen „runter lesen“, sondern man ertappt sich öfters dabei, eine Seite nun das x-te mal gelesen und dann doch noch das Gefühl zu haben, etwas nicht richtig verstanden zu haben. Kleiner Tip: Hier hilft es sehr, die Beispiele wirklich abzutippen und das Thema mal auszuprobieren. Frei nach dem Motto „Probieren geht über Studieren“ lösen sich dann die Fragen meist in Erkenntnis auf.

Schön zu lesen sind auch die Fallbeispiele von Typo3, Zend Framework und allen weiteren. Auch die „großen“ machen Fehler und manche lassen sich hier nachlesen. Das schöne Gefühl von „die konnten es auch nicht sofort“ stellt sich ein und lässt einen etwas beruhigter zurück.

Meine Favoriten waren die Kapitel über „Legacy Code“, „Kontinuierliche Integration“ und „Bad Practices“. Ich persönlich fand ich den präsentierten Legacy Code zwar nicht legacy genug, aber das liegt sicherlich auch an mir und meinem Background. Übertragbar sind trotzdem viele der Wege und Tips auf (noch viel) älteren Code – alles schon ausprobiert 😀

Will man nun was negatives finden, man könnte anbringen, dass die Beispiele in sich manchmal nicht konsistent sind oder der eigentlich Kern, was Bergmann und Priebsch sagen wollen, nicht immer anhand der Beispiele ersichtlich wird. Hier und da hätten die Beispiele kürzer, dafür mehr auf den Kern reduziert sein können, es hätte zu etwas schnelleren „Aha!“-Momenten geführt. Aber das wäre jammern auf einem sehr hohen Niveau. Dieses Buch richtet sich definitiv nicht an Einsteiger, die sich an solchen Dingen stören würden; es richtet sich vor allem an Profis oder interessierte Fortgeschrittene, die sich noch weiter verbessern wollen, noch näher an den „perfekten Code“ kommen wollen. Und dieses Wissen zu vermitteln schafft dieses Buch locker.

Mein Tip: Kaufen, Lesen, Verstehen (nicht auswendig lernen). Ich habe selten so ein gutes (Fach-)Buch gelesen! Wenn ihr nur wenig Budget zur Verfügung habt, euch aber die Qualität eures Codes (und eures Handwerks) nicht egal ist, dann kauft dieses Buch. Ihr werdet sehr lange Lesefreude daran haben und euer Code wird es euch danken.

tl;dr: Unbedingt kaufen und verinnerlichen