Im letzten Teil der Serie habe ich ja beschrieben, was ein (Symfony2)-Controller tun sollte bzw. was meine Erkenntnisse bezüglich fat Controllern ist. Ein Artikel auf test.ical.ly gibt ein paar gute Tips, wie man fat Controller verhindern kann.

Was kann man nun tun, wenn man riesige Controller hat (aus was für Gründen auch immer) und diese wieder in schlanke, verständliche, lesbare Controller refactoren will? Ich beschreibe nun eine Vorgehensweise, welche sich für mich schon einige Male bezahlt gemacht hat. Vielleicht könnt ihr auch davon profitieren.

Code studieren und grob verstehen?

Als ersten Schritt muss man versuchen im groben zu verstehen, was der Controller macht.

• Was für Logik beinhaltet der Controller?
• Welche Services / Klassen werden verwendet?
• Welche Daten werden für die HTML / JSON / XML Response aufbereitet?
• Welche Templates werden mit den Daten befüllt?

Funktionale Tests schreiben

Falls noch keine Tests vorhanden sind, sollte unbedingt versucht werden, die Controller mit funktionalen Tests abzudecken, um für das Refactoring Sicherheit zu gewinnen. Man soll schliesslich ohne Bedenken/Angst das Refactoring durchführen können. Da aktuell der Code wahrscheinlich sehr verdrahtet und abhängig voneinander ist, sind funktionale Tests die richtige Wahl. Ausserdem kann man mit funktionalen Tests auch viel Code mit verhältnismässig wenigen Tests abdecken.

Auslagern in kleine private Methoden

Nachdem die Tests geschrieben sind, kann man mit dem Auslagern des Controller-Codes in kleine private Methoden beginnen. Die privaten Methoden verbleiben hierbei noch im Controller, werden aber später in andere Klassen ausgelagert. Man sollte einfach kleine zusammenhängende Code-Blöcke finden und gute Funktionsnamen vergeben.

Ich empfehle ausserdem, dass die Code-Blöcke strikte in Integrations- oder Operations-Funktionen unterteilt werden. Der Blogpost von Ralf Westphal hat mich sehr beeindruckt und ist für mich ein sehr schlüssiges Vorgehen.

Während des Auslagerns, findet man eventuell noch weitere Testfälle, welche man dann natürlich ergänzen sollte. Ausserdem wird einem auch immer mehr klar, was der Code eigentlich genau alles tut/kann.

Klassendesign erstellen

Nachdem man nun viele kleine Methoden hat, sollte man Papier und Stift zur Hand nehmen und Klassen identifizieren, in welche die Methoden verschoben werden können. Es muss kein perfektes UML sein, eine einfach Skizze mit Kästchen und Pfeilen reicht schon. Man sollte einfach ein Gefühl für die neue Struktur erhalten. Ausserdem lohnt es sich eigentlich immer, wenn man das neue Klassendesign mit einem zweiten Entwickler kurz durchgeht/bespricht. Normalerweise kommt da immer wertvoller Input zurück.

Refactoring in die neuen Klassen

In diesem Schritt werden die Methoden in die vorher neu gebildeten Klassen verschoben. Währen dem Refactoring kann es gut sein, dass noch weitere Klassen dazu kommen oder auch wegfallen. Man sollte das ganze so lange weiterführen, bis man das Gefühl hat, dass die Methoden am richtigen Ort sind. Natürlich sollte man jeweils nach einigen kleinen Refactorings die Tests wieder laufen lassen, um zu prüfen, ob der Code noch das tut, was er vorher schon getan hat.

Codereview eines Entwicklers

Als letzten Schritt empfehle ich, dass der Code nochmals von einem anderen Entwickler angeschaut wird. Er soll vor allem darauf achten, ob er den Code versteht und falls eine Modifikation nötig wäre, das auch tun könnte, ohne den Code stundenlang studieren zu müssen.

Feedback erwünscht

Da dies ein sehr subjektives Vorgehen ist, würde mich Euer Feedback freuen.

• Sind das sinnvolle Schritte? Zu viel, zu wenig?
• Wie packt ihr (Controller)-Refactorings normalerweise an?

Beruflich arbeite ich momentan intensiv mit Symfony2. Wir hatten in den letzten 1,5 Jahren im Team immer wieder grosse Meinungsunterschiede, welchen Ansatz man für Symfony2 Controller wählen soll.

• Direkt vom Symfony2 Controller erben?
• Die Controller als Services aufsetzen und alle benötigten Services per Dependency Injection übergeben?
• Die Controller als Services instanzieren und nur den Container per Dependency Injection übergeben und die Services aus dem Container laden?

Es gibt für alle 3 Positionen pro’s und kontra’s. Einige von unseren Argumenten, waren aber geprägt von der bereits bestehenden Umgebung/Applikation. Eigentlich sollte man aber von einer idealen Umgebung ausgehen und überlegen, was das beste ist und erst dann auf die bestehende Situation adaptieren.

Was ist die Aufgabe eines Controllers?

Als erstes sollte man verstehen, was die Aufgabe eines Controllers in der Webentwicklung ist.

1. Request zu einem Modelrequest konvertieren
2. Anfrage an Model
3. Fehlerhandling
4. Korrekte View auswählen
5. Model an View weiterleiten

Wie man hier schön sehen kann, macht ein Controller nicht sehr viel. Er sollte also möglichst klein sein und nur die ihm zugetragenen Aufgaben erledigen (Idealerweise zwischen 10-20 Zeilen Code).

Unsere Controller und unsere Argumente

Wir hatten fat Controller, was bedeutet, wir haben alles mögliche in die Controller gepackt (ja, ich weiss, das ist nicht gut). Natürlich war die Situation wieder einmal dem Termindruck geschuldet und wie es halt so ist, wenn einmal ein gewisses Design da ist, dann macht man halt das gleiche, wie der Kollege vorher.

Vom Symfony2 Controller vererben, Services aus Container beziehen

• + Es ist so offiziell in der Doku
• + Symfony2 Controller bietet bereits viele nützliche Funktionen und Services an
• - Es kann zu schlechtem Design führen, weil jederzeit irgendwo irgendwelche Services aus dem Container geladen werden könnten

Controller als Service + Services als Dependency Injection

• + Man weiss schon im Konstruktor, welche Services verwendet werden.
• + Es besteht nicht die Gefahr, dass irgendwo im Verlaufe des Controllers über den Container nicht existierende oder fehlerhafte Services verwendet werden
• + Man hat Code Completion in der IDE

Erkenntnisse

Ich hoffe jetzt mal, dass die Argumente im vorherigen Abschnitt Sinn für Euch machen. Es gibt sicher noch mehr. Einige der Argumente entstanden aber nur, weil wir im Controller das Single Responsibility Principle verletzten. Uns war nicht wirklich bewusst (bzw. wir haben nicht lange genug darüber nachgedacht), was ein Controller genau zu tun hat. Dadurch entstanden interessante aber falsche Argumente.

Wir haben uns nun dazu entschieden, von den Symfony2 Controllern zu vererben und die Controller sollten als Faustregel nicht länger als 20 Zeilen beinhalten. Jetzt kann man die Argumente, die für den Controller als Service sprechen leicht entkräften.

Es kann zu schlechtem Design führen, weil jederzeit irgendwo irgendwelche Services aus dem Container geladen werden könnten.
Man weiss schon im Konstruktor, welche Services verwendet werden.

Weil die Methoden jetzt klein sind, müssen generell nur wenige Services geladen werden, der Code ist/bleibt übersichtlich.

Es besteht nicht die Gefahr, dass irgendwo im Verlaufe des Controllers über den Container nicht existierende oder fehlerhafte Services verwendet werden.

Ok, die Gefahr besteht immer noch, aber mit funktionalen Tests und dem wenigen Code ist dies sehr einfach zu verhindern. In der vorherigen Situation mit riesen Controllern, war es echt heavy gute Funktionale Tests zu schreiben.

Man hat Code Completion in der IDE

Durch die kurzen Methoden, ist dies nicht mehr wirklich relevant.

Was nun mit unseren Fat Controllern?

Das klingt ja alles schön und gut, wenn man auf der grünen Wiese beginnt, aber was machen wir nun mit unseren bestehenden Controllern?

Refactoring, refactoring, refactoring. Uns bleibt nichts anderes übrig, als Schritt für Schritt Aufgaben im Controller Code zu identifieren und in Serviceklassen auszulagern.

Entscheidend ist, dass alle die gleiche Vorstellung davon haben, wie der Code bzw. die Controller in Zukunft aussehen sollen und jeder ein kleines Stück dazu beitragen kann.

Quellen

• Controller Responsibilities
• Don’t pull your dependencies
• Symfony2-doc Controller

Es kommt auch vor, dass ich immer wieder mal gefragt werde, wie man am besten ein bestimmtes Tool wie z.B. PHPUnit auf seiner Entwicklermaschine installiert.

Ich habe mich darum entschieden, einen typischen Installationsstack für einen PHP Entwickler auf Ubuntu als Beispiel zu posten.

Natürlich bin ich für Feedback oder Verbesserungsvorschläge immer offen.

Beispielinstallation: https://gist.github.com/3995789

Heute möchte ich über das Thema Code Reviews berichten.

Vorgeschichte

In der NZZ haben wir Ende des letzten Jahres unsere Code Repositories in Richtung Github gezügelt. Weil das Entwicklerteam in kurzer Zeit sehr stark gewachsen ist, mussten wir Wege finden, die Codequalität auf einem hohen Stand zu etablieren. Dies haben wir mit Code Reviews und Pull Requests auf Github versucht.

Der Prozess

Ein neues Feature/Bugfix wird in einem neuen Branch, vorzugsweise mittels Pairprogramming, entwickelt. Sind der/die Entwickler der Meinung, dass Feature sei fertig, wird auf Github ein so genannter Pull Request eröffnet. Ein Pull Request zeigt die Unterschiede zwischen 2 Branches an (z.B. zwischen dem develop und dem feature Branch). Der Reviewer (Auch ein Entwickler, aber keiner der das Feature implementiert hat), macht nun folgende Dinge.

• Unittests durchlaufen lassen
• Stylechecks durchlaufen lassen
• Reviewen der Differenzen vom Pull Request
• Feedback auf der Github Plattform bezüglich Mängeln

Ist alles ok, integriert der Reviewer den Code in den develop Branch. Gibt es Mängel, sind die Entwickler wieder in der Pflicht und müssen die Mängel beheben. Dieses Ping Pong Spiel geht so lange weiter, bis der Reviewer der Meinung ist, dass alles ok ist.

Fazit

Als wir die Idee mit den Codereviews auf Github hatten, dachten wir, dass dies eine Verbesserung der Codequalität bringen könnte.

Der Effekt war aber deutlich grösser als erwartet. Die Qualität hat sich massiv gesteigert und die Knowhowverteilung ist auch besser geworden, da nun immer 2-3 Leute den Code kennen.

Da ich selber auch Reviewer bin, kann ich folgende Dinge dazu sagen:

• Code-Reviews haben sehr positive Auswirkungen auf die innere Qualität eines Projektes
• Code reviewen ist sehr streng/anspruchsvoll
• Entwickler lernen sehr viel aus den Feedbacks
• Als Reviewer lernt man selber auch sehr viel dazu
• Knowhow verteilt sich noch besser
• Checkstylefehler, schlechte Variablennamen usw. sind einfach zu finden. Softwaredesignfehler sind aber sehr schwierig auszumachen und werden häufig zu wenig genau unter die Lupe genommen
• Wenn man es seriös macht, benötigen Code Reviews sehr viel Zeit. Wenn man also unter Zeitdruck ist, leidet häufig auch die Qualität der Reviews

Was denkt Ihr über Code Reviews? Sind diese sinnvoll und wenn ja, warum? Oder sind sie nur Arbeitsbeschaffung?

Wie ich schon im letzten Artikel erwähnt habe, sind wir aktuell 3 SCRUM Teams und haben diese auch in sehr kurzer Zeit von 4 auf 18 Entwickler hochgefahren (ca. 6 Monate).

Am Anfang gab es eine kurze Kennenlernphase zwischen den einzelnen Personen. Wir waren am gleichen Ort und arbeiteten zusammen. Danach wurden die Teams aufgeteilt und auf die Projekte losgelassen. Relativ schnell war die Kommunikation zwischen den Teams eher rar. Jedes Team hatte seine eigene Philosophie von Design, Standards usw. und über kurz oder lang, gab es kleinere Probleme. Man beschwerte sich, warum jemand das so gelöst hat und nicht so, wie es im eigenen Team geregelt war.

Wir versuchten also einen neuen Ansatz. Die zwei Teams aus Zürich und der Ukraine wurde gemischt, um die Kommunikation zwischen den beiden Standorten zu verbessern. Das Team von Liip, haben wir so belassen, weil es ein externer Partner ist.

Neu besuchen wir uns regelmässig. Leute von Kiev arbeiten 1-3 Wochen bei uns und umgekehrt. Auch die Leute vom Liip Team, arbeiten regelmässig in der NZZ.

Dieser Ansatz hat die Kommunikation zwischen den Teams extrem verbessert. Man versteht sich besser, man fühlt sich verbundener. Natürlich gibt es nach wie vor Problemchen, aber diese sind lange nicht mehr so gross wie vorher.

Was denkt ihr von dieser Lösung? Gibt es noch bessere Ansätze? Sollte man verteilte Teams generell versuchen zu vermeiden?

Ich bin gespannt auf eure Meinung.