Artikelformat

„Softwarequalität in PHP Projekten“ – eine Rezension

Letzte Woche gab es leider keinen Artikel. Dies war mein Tribut an das herbstliche Wetter und ich habe die jährliche Erkältung gut überstanden. Diese Woche gibt es daher auch besonders leichte Kost, zumindest für euch Leser. Aktuell lese ich das relativ neue Buch „Softwarequalität in PHP Projekten“ von Bergmann und Priebsch und hier sind meine Eindrücke dazu.

Erstmal die grobe Kennzahlen. Das Buch hat ca 480 Seiten und ist in 16 Kapitel unterteilt. Neben den beiden Hauptautoren gibt es noch viele Größen aus der PHP Welt, die in diesem Buch zu Wort kommen. Dadurch hat man einen recht guten Überblick und vielfältige Ansichten zu den verschiedenen Hauptthemen.

Ein sehr großer Bereich wird vom Thema Testing eingenommen. Neben den üblichen Unittests findet man auch Informationen wie man ein ganzes Framework testet und im speziellen dann auch Webservices und Serveranbindungen und Datenbankanbindung und Grafikausgaben. In diesem Bereich ist vor allem das Kapitel über Bad Practices interessant. Sehr umfangreich fällt das Kapitel zum DB Layer Test aus – was auch ein nicht-triviales Thema ist.

Weiter gibt es natürlich auch Informationen zur Continuous Integration. In diesem Bereich plaudern studiVZ und swoodoo aus dem Nähkästchen. Wer hier fleißig liest, weiß ja schon einiges zum Thema CI und wird nicht vollkommen von der Thematik überrascht. Da das Thema CI an den Beispielen erläutert wird, erfährt man automatisch über deren Vorgehensmodelle und Themen wie KISS und YAGNI werden auch noch angesprochen. Insgesamt ein sehr runder Abschnitt.

Unter der Überschrift der NFA (Nicht funktionale Anforderungen) findet man natürlich Performanz und Sicherheit aber auch die „Gebrauchstauglichkeit“. Diese Themen sind üblicherweise Anforderungen die der Kunde implizit stellt. Eine Software soll natürlich schnell und sicher sein, und gut benutzen muss man sie auch noch können – ist doch klar, oder?

Besonders interessant fand ich beim Lesen die Verweise zu den verschiedenen Werkzeugen und Tools, die die verschiedenen Autoren erwähnen. Hier werde ich wohl noch etwas Zeit aufwenden, um mir diese genauer anzuschauen. In diesem analogen Medium sind die Links als Fußnoten hinterlegt. So erübrigt sich das Googeln und man landet gleich bei dem richtigen Tool.

Das Buch hat umfasst auch einen Download Code für eine eBook-Version, die man mit Adobe Digital Editions lesen kann.

Fazit:
„Softwarequalität in PHP Projekten“ ist ein solides Buch, dass neben dem Haupthema Software Testing durch die zusätzlichen Informationen (NFA, CI etc.) und den „real-life“ Beispielen eine besondere Authenzität versprüht. Dieses Buch sollte bei jedem guten PHP Entwickler neben „PHP Design Patterns“ stehen.

8 Kommentare

  1. Kann deinem Fazit ganz und gar nicht zustimmen. In meinen Augen ist das Buch für jeden professionellen PHP-Entwickler absolut nutzlos. Es gibt keinerlei besondere Informationen, die man nicht schon haben sollte. Keinerlei Tricks oder besondere Kniffe.

    Besonders enttäuscht war ich, als ich das Kapitel zum Thema CI gelesen habe. Ich wollte es mal so aufsetzen, wie es dort „erklärt“ wurde. Es wird immer von einer „Case Study“ gesprochen, die man verwendet. Aber den Code dazu haben sie vergessen.
    Wenn man schon die Konfiguration eines CI-Systems aufgreift, dann sollte das auch komplett sein und nicht lückenhaft nach dem Motte „You got the idea…“ runtergeschrieben sein.

    Wer sich grundsätzlich über die Themen informieren will, keinerlei Anleitung erwartet und diese lieber im Internet sucht oder einfach drauf loslegen will, für den ist das Buch genau das richtige. Oder wer einen Vorgesetzten hat, der Sinn und Zweck von Unit-Testing, CI etc. nicht einsieht: dem kann man das Buch auch schenken.

    Ich war echt sauer, als ich das Buch überflogen habe und wirklich gar nichts an neuen Informationen gefunden habe. Für das, was dort aufgeschrieben wurde, ist der Preis VIEL zu hoch. Sowas hätte ich von den Autoren echt nicht erwartet.
    In meinen Augen ist es reine Geldmacherei ohne wirklichen Nutzen für die vermeintlichen Profis bzw. die, die es werden wollen.

    Antworten
    • Deine Kritik zur „Case Study“ kann ich nicht so ganz nachvollziehen. Ab Seite 353ff findest du die einzelnen Codefragmente. Natürlich ist die build.xml nicht als eine riesen Datei abgedruckt, sondern jedes build-Target einzeln mit einer entsprechenden Erklärung. Ich muss aber auch gestehen, dass ich dieses Kapitel eher überflogen habe, da ich – wie man in einigen Artikeln hier lesen kann – den Hudson CI mehr mag als CruiseControl.

      Wenn du keine neuen Informationen finden konntest, ist das für deine Expertise ein gutes Zeichen. Welches Buch erachtest du denn als must-have für einen professionellen Entwickler?

  2. Jan Markmann

    17/11/2010 @ 22:22

    Ich kann die Kritik am Buch auch nicht nachvollziehen. Es wird nirgends als Howto oder Anleitung angepriesen und das habe ich davon auch nicht erwartet. Viel mehr die ganzen Themen zu QA aus der PHP-Perspektive mal zusammengefaßt vorzufinden. Es wird alles erklärt was es zu QA zu sagen gibt. Ich lese auch seit Jahren was ich im Web dazu finde und habe auch wenig neue Begriffe im Buch entdeckt, aber so einige habe ich nun erst mal so richtig oder noch viel Besser verstanden. So gründlich und umfassend wie dieses Buch ist kein Blogpost noch sonstiger Artikel geschrieben. Ich find den Preis mehr als fair.
    Wie man zu so einer Kritik kommen kann kann ich mir wirklich nur erklären wenn man sowohl das Buch als auch was so im Web dazu gepostet wird nur oberflächlich studiert und sich mit einer ungefähren Ahnung von den neuen Buzzwords zufrieden gibt statt es wirklich verstehen und beherzigen zu wollen. Dann freilich wird man in dem Buch oberflächlich nichts neues finden.

    Antworten
  3. @Norbert: Da hast du wohl Recht. Ich habe einfach etwas anderes erwartet. Ist wohl definitiv mein Fehler, dass ich das Buch einfach blind gekauft habe, ohne mich näher zu informieren, was denn tatsächlich in welcher Form abgehandelt wird.
    Mit fehlernder „Case Study“ meine ich den Projektcode, auf den das Cruise Control losgelassen wird. Meiner Meinung nach kann man nur über das Spielen mit den verschiedenen Parametern wirklich verstehen, wie man was anzuwenden hat. Ohne den Projektcode bringt einem die Demo-Config recht wenig.

    @Jan Hast ebenfalls Recht: im Web findet sich nichts derartig gebündeltes zu dem Thema. Von daher ist sowas für eine Einführung schon OK. Aber ich habe Software Engineering studiert und bin mit dem Kram bestens vertraut. Jedoch nicht im speziellen wenn es um QA in PHP-Projekten geht. Leider scheint es auch immer noch so zu sein, als würde genau das noch mehr in den Kinderschuhen stecken (bezogen auf CI).

    Antworten
    • Wenn du mit Projekt-Code den PHP-Code meinst, so braucht man da nichts abzudrucken, denn PHP Code, der in einem SVN Repository liegt, kann direkt als Beispiel genutzt werden. Da man nur lesend zugreift, passiert da ja auch nichts.
      Der interessante Punkt ist wirklich nur das ant Buildskript. Wir nutzen bspw eine Art Master-Buildskript für unsere PHP Projekte und importieren dieses in das eigentliche Projekt-Buildskript. Außer in ein paar wenigen Ausnahmen steht in dem Projektbuildskript eigentlich nichts drin und es wird nur genutzt um einen anderen Projektnamen zu definieren. Unterscheiden muss man auch nur den Zugang zu den Unittests, den man aber auch vereinheitlichen kann, sodass man selbst hier keine Parameter braucht.

      Vielleicht muss die Erkenntnis, das dieses in Mühen zusammengebaute Buildskript bei fast allen PHP Projekten gleich ist, erst einmal wachsen.

      Richtig spannend kann ich mir ein Buildskript vorstellen, dass Komponenten nach PEAR exportiert und ein PHP Projekt, das aus PEAR Modulen besteht für ein Deployment vorbereitet, aber da ist man dann doch schon einen guten Schritt weiter, als die Probleme, die in dem Buch gelöst werden.

  4. Jan Markmann

    18/11/2010 @ 21:28

    @Christian: Ich denke ich erkenne was Dir fehlt, die Übersicht wie QA nun gerade speziell in PHP realisiert werden kann. Quasi: „Ich kann QA aber nicht in PHP, nun sag mir womit ihr das in PHP realisiert.“
    Da wird wirklich ein Missverständnis vorliegen. Allerdings hast Du Dir dann wirklich keine Rezension oder dem Umschlagtext angeschaut 😉
    Es geht halt eher um QA und wie und wozu und wie nicht und warum und für viele ist das wirklich sinnvoll, da sich einiges in den letzten Jahren getan hat auf dem Sektor bzw das Studium noch in der Pre-JUnit-Zeit lag. Bei mir gabs zwar schon JUnit aber nach JUnit zeigen und Unterschied zwischen Blackbox- und Whitebox-Tests war mit dem Thema schon wieder Schluss. Und auch heute noch kommen ne Menge Leute aus der Uni ohne wirklich gerafft zu haben was QA wirklich bedeutet bzw wie wichtig es ist.
    Nochmal zu Deiner Kritik: Ich hätte mir auch etwas mehr Details und Überblick zu den QA-Werkzeugen für PHP gewünscht. Die meisten finden sich zwar im Kontext erwähnt und z.T. ansatzweise erklärt, aber nicht im Detail erklärt. Das vorletzte Kapitel „Performanz“ bietet eine Übersicht aber nur über die Tools zu genau diesem Thema. Für mich hätte man an den Case Studies ruhig sparen können und mehr Tools-Überblick und -Howtos einbauen können. Andererseits gibt es Howtos mehr als genug im Netz und Sebastian hat für den Überblick eine Seite mit Linkliste (finde sie grad nid auf Anhieb, hat er meistens ganz hinten auf seinen Vortragsfolien die man im Netz findet). Auch seine Folien selbst sind da nicht schlecht, siehe slideshare.
    Also ich würde das PHP-QA-Referenzbuch auch noch kaufen, aber das hab ich nicht wirklich erwartet von diesem Buch. Ich find in diesem Buch auch nur auf jeder 10.-20. Seite was zu lernen, aber ich habs die Firma auch eher kaufen lassen weil ich mir erhoffe das es anderen die Augen öffnet bzw sie auf den Pfad des Lichtes zurück bringt. Vor allem die halb richtig Ansätze find ich nämlich teilweise erschreckend. Stichworte trügerisches Gefühl von Sicherheit.

    Antworten

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.