Auch im März hatten wir wieder einen Experten für einen Workshop eingeladen.
Manuel Pichler von Qafoo hat uns die Ehre Erwiesen und sich mit einigen unserer eigenen Experten einen Tag zum Thema Continuous Integration zusammengesetzt.
Für uns die Möglichkeit, unsere CI-Strategien und die Tool-Landschaft rund um unseren
Software Development Cycle zu validieren und zu optimieren.
Anschließend gab es noch eine 2-stündige Präsentation für die gesamte IT-Abteilung mit dem Thema “Quality Assurance and Continuous Integration”.
Wie gewohnt eine gute Gelegenheit für ein “kleines” Interview, auch wenn dieses aufgrund voller Terminkalender ein paar Wochen auf sich hat warten lassen.
Manuel, stell Dich und Qafoo doch in ein paar Sätzen vor:
Hallo To
m, erst einmal möchte ich mich herzlich bei dir bedanken, dass du uns zur ICANS eingeladen und uns die möglich gegeben hast, deinem Team die Themen Quality Assurance und Continuous Integration näher zu bringen.
Zu meiner Person gibt es eigentlich nicht viel zu sagen. Beruflich würde man mich wohl als einen Voll-Techie bezeichnen, der sein Steckenpferd in dem, in letzter Zeit immer mehr an Interesse gewinnenden, Thema Qualitätssicherung gefunden hat und nun seit gut fünf Jahren damit beschäftigt ist das Thema in die PHP-Gemeinde zu tragen. Im Privatleben versuche ich die letzten 2,5 Jahren ein qualitativ hochwertiger Papa zu sein.
Die Qafoo GmbH habe ich vergangenen Sommer zusammen mit Tobias Schlitt und
Kore Nordmann gegründet.
Wir drei kennen uns jetzt schon seit einer kleinen Ewigkeit aus der PHP-Usergroup Dortmund, wo wir schon immer heiß und hitzig über Themen wie Softwarequalität und Softwarearchitekturen diskutiert und gestritten haben. Aus diesen Diskussionen heraus hat sich dann irgendwann die Idee entwickelt ein eigenes Unternehmen zu gründen, in dem wir Tobys und Kores jahrelange, praktische Erfahrung im Bereich Softwarearchitektur und -design aus dem eZ Components Projekt und mein Wissen über Qualitätssicherung kombinieren.
Damit war Qafoo ins Leben gerufen, ein Unternehmen das Menschen dabei unterstützt, durch saubere Prozesse und fundiertes Wissen über Softwareengineering, hochwertige, wartbare Software zu entwickeln.
Warum hast du Dich gegen eine klassische Entwicklerlaufbahn entschieden und zusammen mit Kore und Tobias eine Consulting-Firma ins Leben gerufen?
Eigentlich haben wir uns ja gar nicht gegen eine Entwicklerlaufbahn entschieden, denn nur wenn wir weiter aktiv Software entwickeln, können wir Andere dabei auch gut beraten.
Ansonsten ist die Gefahr recht groß, dass man
den Sinn für die Projektrealität verliert und dann ist man keinem Entwickler mehr eine große Hilfe. Um aber auf den Punkt zu kommen: Kore, Toby und ich haben alle lange Jahre in Projekten gearbeitet und die klassische Laufbahn so schon kennengelernt. Das reine Engineering reicht uns allerdings nicht, wir arbeiten
auch gerne mit Menschen, haben Spaß daran Wissen zu vermitteln und ständig
neues dazu zu lernen. Diese Punkte erfüllt der Consulting-Job sehr gut.
Wie differenziert Ihr Euch von anderen Consulting-Unternehmen wie Mayflower oder thePHP.cc?
Hehe, solche Abgrenzungen sind immer recht waghalsig aus eigener Sicht zu
beschreiben, daher sage ich einfach mal, was wir machen und was wir
gegebenenfalls auch nicht machen.
Zunächst konzentrieren wir uns auf reine Beratung, verkaufen also nicht an erster Stelle Manpower für Entwicklung und Management. Wir helfen Menschen sich selbst zu helfen. Unsere Beratungen und Schulungen sind sehr stark auf die Menschen fokussiert
mit denen wir arbeiten. Wir sprechen vorab viel mit unseren Kunden und
versuchen in Zusammenarbeit mit Ihnen die optimale Leistung für sie zu
entwickeln.
Vor Ort zählt dann der praktische Nutzen für das Team, so dass wir auch mal, natürlich in enger Absprache mit dem Kunden, unseren vorbereiteten Schulungsplan über den Haufen werfen um ganz gezielt auf die Bedürfnisse der Menschen einzugehen.
Das Ziel ist es, dem Kunden langfristig und nachhaltig zu helfen. Obwohl unsere Einsätze meist recht kurz sind, bemühen wir uns mit unseren Kunden eine langfristige Kooperation, eine Art Coaching-Beziehung aufzubauen.
Mit einer Schulung oder einem Consulting-Einsatz können Verbesserungen gut angestoßen werden. Leider passiert es aber zu oft, dass diese sich im Sande verlaufen, wenn es an die praktische Umsetzung einer Veränderung im Projekt-Alltag geht. Hier stehen wir unseren Kunden als zuverlässiger Partner zur Seite um einen langfristigen Erfolg zu sichern.
Was sind Eure Top-Empfehlungen an Firmen im Kontext Eurer Beratungsarbeit?
Was ein Team vor Ort am meisten voran bringt ist von Kunde zu Kunde sehr
individuell. Deshalb ist es schwierig, Top-Empfehlungen aufzuzählen.
Was wir sehr häufig erleben ist, dass die Kombination verschiedener Leistungen für sehr viele Kunden Sinn ergibt. Beispielsweise ist es eigentlich immer sinnvoll, einen Unit-Testing-Workshop mit dem Thema Objektorientiertes Softwaredesign zu verbinden. Die beiden Themen und besonders ihre Effekte sind einfach so eng verzahnt.
Automatisierung ist ein Punkt den viele Kunden nicht auf dem Schirm haben,
der im Nachhinein aber immer sehr gut ankommt und vor allem sehr viel
bringt.
Ich spreche hier absichtlich nicht schon von Continuous Integration oder ähnlichen Konzepten, denn häufig hört man “das bringt bei uns noch nichts, dafür sind wir noch nicht weit genug”. Das stimmt so nicht, jedes Team profitiert eigentlich sofort davon, möglichst stark wiederkehrende Prozesse zu automatisieren. Sei es das Paketieren und Installieren von Releases, der automatische Check der Coding-Guidelines oder ein Pre-Commit-Hook der Parser-Fehler aufdeckt.
Ein weiteres Thema, was oft verkannt wird, ist Code-Review. Ein gut auf die
Menschen angepasster Code-Review-Prozess steigert nicht nur die Qualität des
Codes, sondern setzt einen immensen Wissenstransfer zwischen den
Team-Mitgliedern oder auch zwischen Teams in Gang.
Warum der Fokus auf PHP? Sind Eure Strategien nicht unabhängig von der
Sprache anwendbar?
Ja, nahezu alle Konzepte bei deren Realisierung wir unseren Kunden helfen sind so oder ähnlich auch auf andere Sprachen übertragbar. Dass wir uns bisher auf PHP konzentrieren hat verschiedene Gründe:
Als erstes haben wir alle drei in den letzten Jahren am meisten mit PHP gearbeitet. Wir mögen die Sprache, das Web-Umfeld, aber insbesondere auch die Community. Wir kennen die verfügbaren Tools bis ins letzte Detail und arbeiten an vielen selbst mit.
Das bringt mit sich, dass wir Teams im PHP-Bereich viel mehr bieten können, als theoretische Konzepte zu predigen. Wir verstehen die kleinen und großen
Probleme mit denen die Entwickler täglich kämpfen und können gezielt darauf eingehen. Desweiteren können wir praktische Beispiele zeigen, mit denen sich Entwickler identifizieren können und die direkten praktischen Impact haben. Auch wenn die Konzepte sich überall ähneln, hat PHP seine ganz persönlichen Eigenheiten und auch das Web-Umfeld ist auf verschiedensten Ebenen ganz anders als die Entwicklung von beispielsweise Desktop-Anwendungen.
Daneben ist im PHP-Bereich das Potential für das große Thema Softwarequalität aktuell sehr hoch. Die Professionalisierung nimmt in den letzten Jahren immer weiter zu, steckt aber immer noch vielerorts in den Kinderschuhen. Es gibt also hier noch jede Menge zu tun.
Wenn du Deine Karriere heute erst starten würdest. Welche Sprache würdest du für den Bereich Webentwicklung wählen?
Da erwischt du genau den Richtigen von uns Dreien, denn ich liebäugele auch
immer mal wieder mit Java und in letzter Zeit auch immer häufiger mit C#. ;)
Aber Spaß bei Seite, ich glaube das PHP für den Web-Bereich eine sehr gute Basis bereitstellt.
Klar, aus verschiedensten Gründen muss man sich als Entwickler wirklich gut im Griff haben um anständige Software zu entwickeln. Wenn dieser Punkt aber erreicht ist, bietet PHP mit seiner Shared-Nothing-Architektur und den vielen praktischen Goodies im Web-Bereich eine hervorragende Plattform.
Daher würde ich heute vermutlich genau so starten wie es der Fall war:
Mit Java anfangen, zur Webentwicklung dann bei PHP landen, aber immer mal wieder die Augen bei Java und in anderen Bereichen offen halten, um neue Konzepte kennen zu lernen.
Welche spannenden Entwicklungen erwartest Du in die nächsten Jahren in der PHP-Welt?
Ich glaube nicht, dass wir bei PHP selbst noch mit hochgradig spannenden Entwicklungen zu rechnen haben, wie es vor ein paar Jahren noch der Fall war.
Wie Johann und Pierre es einmal gesagt haben, “der Hype ist vorbei” und ich schließe mich dem an. PHP ist zur Mainstream-Sprache avanciert.
Natürlich werden auch die kommenden PHP-Versionen ein paar neue Sprachfeatures mitbringen, Traits stehen hier ja beispielsweise immer noch recht hoch im Kurs. Das ist aber eigentlich nur Zucker: Die Sprache PHP ist an sich fertig und wird höchstens weiter ausgefeilt.
Etwas anders sieht es dagegen im Userland aus. Hier ist noch großes Innovationspotential, beispielsweise in den Bereichen Infrastruktur, Tools und Frameworks. Ein schönes Beispiel in dieser Richtung ist Symfony2: Viele dachten schon dass mit Zend Framework das, vielleicht nicht schönste, Ende der Fahnenstange erreicht ist. Doch Sympfony2 hat es geschafft ganze Massen von PHP-Entwicklern zu bewegen, wie selten ein Projekt zuvor. Auch die aktuelle NoSQL-Bewegung hat viel Einfluss auf das PHP-Userland.
In unserem Kernbereich, der Softwarequalität, wird sich auch noch einiges
tun. Hier gibt es noch sehr viel Potential sich aus anderen Bereichen inspirieren zu lassen und ich hoffe das wird der Fall sein.
Ich bin mir allerdings recht sicher, dass die Innovation nur noch sehr schwach in der Sprache PHP selbst stattfinden wird, sondern eher im Ecosystem drumherum.
Welche Tools sind aus Deinem Arbeitsalltag nicht mehr wegzudenken?
Das ist schwer zu sagen, da ich an sehr unterschiedlichen Baustellenarbeite. Ein wesentliches Tool ist Ant, welches ich derzeit als Build-System präferiere. Als großer Fan von Automatisierung setze ich Ant eigentlich in jedem unserer Projekt ein.
Daneben sind natürlich die Klassiker immer mit im Spiel: Xdebug und die Shellzauberstäbe wie grep, sed und Konsorten. Die verschiedensten
Metriken-Tools kommen häufig zum Einsatz, wenn ich mich in fremdem Sourcecode einarbeite.
Würdest Du jedem Entwickler-(Team) empfehlen eine CI-Lösung einzusetzen, oder gibt es Fälle wo es wenig Sinn macht?
Die Frage stellst du jetzt natürlich auch dem Richtigen. ;)
Aber im Ernst:
Grundsätzlich halte ich den Einsatz einer geeigneten Continuous-Integration Umgebung in jedem Projekt für sinnvoll, an dem mehr als ein einziger Entwickler beteiligt ist und das den Proof-Of-Concept- bzw. “läuft eh nur für ein paar Tage”-Status verlässt.
Aber da sind wir auch schon bei einem Standardproblem. Wer von uns kenntnicht das Phänomen: Ein Proof-Of-Concept oder ein Widget soll eh nur fürkurze Zeit, zum Beispiel für ein Event, geschaltet werden. Es wird als “maleben hin gehackt”. Ehe man sich versieht entsteht daraus aber ein langfristiges Projekt, dass noch über Jahre gewartet und weiterentwickelt wird.
Somit sollte mein Antwort auf deine Frage wohl lauten: Ja, sobald man mit
der Entwicklung eines Projektes beginnt sollte man auch den Einsatz eines
Continuous-Integration-Servers einplanen.
Hilft ein CI Server bei der Entwicklung an Legacy-Code?
Die Frage kann ich ganz klar mit “Ja” beantworten.
Wir vertreten die Meinung, dass wirklich jedes Projekt vom Einsatz eines CI-Systems
profitieren kann, selbst die allgegenwärtigen Legacy-Systeme.
Auch wenn diese Systeme nicht über automatisierte Tests verfügen und die Einführung von Unit-Tests mit der aktuellen Codebasis nur sehr schwer möglich ist, bietet mir ein solches System unzählige Möglichkeiten die Qualität zu messen und kontinuierlich zu verbessern. Das fängt zum Beispiel bei sehr breit aufgestellten Integrationstests an, die ich mittels JMeter, Selenium oder einem anderen Werkzeug implementiere und damit einen möglichst großen Teil meiner Software automatisiert testen kann. Natürlich sind hier
auch die diversen statischen Analysewerkzeuge zu nennen, die man gegen jede
Codebasis laufen lassen kann.
Zu guter Letzt der wahrscheinlich wichtigste Punkt: Durch die Einführung eines CI-Systems bin ich dazu gezwungen mir Gedanken über den
Deploymentprozess meiner Software zu machen und diesen zu automatisieren, um kontinuierlich eine aktuelle Version meiner Software bauen zu können.
Wenn man diesen Punkt einmal überschritten hat, nehmen unserer Erfahrung nach die Dinge fast von selbst ihren Lauf.
Eines Deiner Steckenpferde sind Softwaremetriken. Was motiviert Dich, sich
mit diesem Thema so intensiv auseinander zu setzen?
Anfänglich war es auf jeden Fall der Reiz des Unbekannten, frei nach dem Motto:
Da gibt es irgendwelche Werkzeuge, die berechnen diverse Kennzahlen für deinen Quelltext und sagen dir dann wie gut oder schlecht deine Software ist.
Mit der Zeit hat sich mir dann aber gezeigt, wie hilfreich Metriken sind um die Qualität einer Software zu beurteilen und vor allem auch die qualitative Entwicklung eines Projekts über die Zeit messen und kontrollieren zu können. Ein weiterer wichtiger Punkt bei Softwaremetriken ist der, dass sie theoretisch beliebig skalieren und mit dem Projekt wachsen, wo man mit menschlichen Mitteln irgendwann an die Grenzen des Möglichen stößt.
Siehst Du aktuell spannende Entwicklungen hinsichtlich grundsätzlich neuer Ansätze in diesem Bereich?
Viele Leute halten Softwaremetriken ja für ein sehr modernes Thema in der Softwareentwicklung, dabei gibt es diese Technik eigentlich schon genauso lange, wie auch Software entwickelt wird. Daher sind viele der Metriken die von meinen Tools berechnet werden auch schon 20 oder 30 Jahre alt. Andere Metriken die sich speziell mit objektorientierter Software beschäftigen haben auch schon 10 oder mehr Jahre auf dem Buckel. Trotzdem gibt es auf diesem Gebiet auch heute noch den einen oder anderen sehr interessanten, innovativen Ansatz, der in diversen wissenschaftlichen Ausarbeitung
veröffentlicht wird. Ein Beispiel hierfür ist die CodeRank-Metrik, die sich das Prinzip hinter Googles Suche zu Nutze macht, um die existierenden Abhängigkeiten und den damit verbundenen Wartungsaufwand in einem Softwaresystem wesentlich präziser ermitteln zu können.
Welchen Relevanz haben statische Code-Analysen in der professionellen
Softwareentwicklung?
Hm, ob ich dir jetzt auf diese Frage ehrlich antworte? Schließlich ist das ja genau mein Thema ;-)
Aber mal ernsthaft, ich denke das statische Analyse neben vielen anderen Dingen einen festen Platz in der professionellen Softwareentwicklung hat. Der Stellenwert ist vielleicht nicht ganz so hoch wie der für saubere, definierte Entwicklungsprozesse und die Existenz
automatisierter Tests, aber es kann einem eigentlich niemand glaubhaft versichern, dass er die Qualität und vor allem die qualitative Entwicklung einer sich ständig ändernden Software vollständig im Blick hat.
Genau an diesem Punkt setzen Softwaremetriken und die statische
Code-Analyse an, denn durch die kontinuierliche Messung und Aufzeichnung diverser Qualitätskennzahlen habe ich zu jedem Zeitpunkt die Möglichkeit mir ein Bild über den aktuellen Stand einer Software zu machen. Außerdem ist die statische Code-Analyse ein wichtiges Hilfsmittel bei der Vorbereitung von Code-Reviews, da man ab einer gewissen Projektgröße nur so noch mit vertretbarem Aufwand die Stellen im Quelltext identifizieren kann, die ein detailliertes Review erfordern.
Bis zu welchem Grad kann man Resultate statischer Analysen bei Legacy-Code sinnvoll anwenden?
Bei den meisten Legacy-Projekten die wir so während unserer täglichen Arbeit sehen sind Tests gar nicht vorhanden oder, falls doch Tests existieren, dann meistens für die falschen, nicht fehleranfälligen Teile der Software. An dieser Stelle ist dann häufig die statische Code-Analyse das einzig probate Mittel, um für die vorhandene Codebasis die potentiellen
Gefahrenstellen zu ermitteln, die dringend beim nächsten Housekeeping mit Tests versehen und anschließend refactored werden sollten. Kombiniert man dieses Vorgehen noch mit der Best-Practice: “Für jeden auftretenden Bug wird auch ein Test erstellt”, dann erreicht man bei vertretbarem Aufwand und in relativ überschaubarer Zeit auch bei Legacy-Code eine deutlich spürbare Verbesserung.
Deswegen kann mein Fazit auf diese Frage auch nur lauten, dass die statische
Code-Analyse gerade auch in Legacy-Projekten eine sehr hohe Relevanz hat, da
sie meistens erst den Weg für weitere Prozesse zur Qualitätsverbesserung bereitet.
Was sind die für Dich interessantesten Konferenzen, Blogs, Online-Magazine
und Bücher?
Bei Konfernzen gewinnt für mich in den letzten Jahren immer mehr das Unconference- bzw. Barcamp-Format an Bedeutung. Sprich, ein wenig weg vom klassischen Vortrag, stärker hin zu einem interaktiven Event, bei dem jeder Teilnehmer etwas zum Thema beisteuern kann.
Eine weitere spannende Sache für mich ist der Besuch von Konferenzen und Events außerhalb des eignen PHP-Umfeldes. Meiner Meinung nach lernt man beim Blick über den Tellerrand sehr viel. Da im professionellen Umfeld doch viele Parallelen existieren bekommt man so Lösungsansätze und Ideen aus einem völlig anderen technologischen Hintergrund mit.
Wenn ich in letzter Zeit wirklich mal dazu komme Blogs zu lesen, dann handelt es sich dabei meist nicht um PHP-Blogs wie sie auf Planet-PHP gelistet sind. Ich lese eher die üblichen Verdächtigen in den Bereichen Softwarearchitektur, Agilität und Prozesse wie Fowler, Beck und Uncle Bob, aber auch das Google-Testing-Blog oder das deutschsprachige Blog von Ralf Westphal.
Die letzten Bücher die ich gelesen habe beschäftigten sich fast alle mit den Themen Dokumentation, Kommunikation und Entwurf von Softwarearchitekturen. Beispiele sind “Agile Modelling” von Scott Ambler oder “Effektive Software-Architekturen” von Dr. Gernot Starke. Beides Bücher, die ich jedem technisch Verantwortlichem nur empfehlen kann.
Besten Dank Manuel für den sehr produktiven Tag bei der ICANS und deine ausführlichen Antworten in diesem Interview. Bis zum nächstem Mal!
