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?

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.

Wie ihr vielleicht wisst, arbeite ich bei der NZZ (Neue Zürcher Zeitung).

Bei der NZZ arbeiten wir momentan mit Hochdruck an einem neuen und modernen Webauftritt. Dieser beinhaltet einige Frontend Applikationen und ein gemeinsames Backend. Ausserdem werden wir im Verlaufe des Jahres auch noch mit der Implementierung eines CMS für die Redaktion beginnen.

Wir verwenden hier einige Technologien und Frameworks wie PHP, Javascript, HTML5, CSS3, Symfony2, Jackrabbit, MySQL, Redis, Varnish usw.

Wir arbeiten nach SCRUM und haben 3 Teams. 2 Teams bestehend aus einem Mix aus Schweizern und Ukrainern. Das 3. Team besteht aus Liip Mitarbeitern.

Aktuell lerne ich sehr viel, weil wir moderne Technologien und Frameworks verwenden und super Leute in den Teams haben.

Ich möchte daher immer wieder mal über die Arbeit berichten und so vielleicht dem einen oder anderen etwas mitgeben. Das können ganz kleine Dinge, wie ein interessanter PHP Befehl sein oder auch ganze Konzepte. Auch der schnelle Wachstum des/der Teams stellt uns vor eine grosse Herausforderung. Vor 1 Jahr waren es 4 und aktuell sind es ca. 18 Entwickler.

Ich habe Thematisch noch nichts spezielles geplant, aber jeden Tag erlebe ich AHA Effekte bei der Arbeit. Daher werde ich darüber berichten und eventuell kann der ein oder andere auch davon profitieren.

Teil 1 – Mechanismen

Das Buch ist in 2 Teile aufgeteilt. Der erste Teil beschäftigt sich mit Mechanismen für produktives Programmieren. Es wird gezeigt, wie man schneller wird und den Fokus auf die wichtigen Dinge lenkt. Dieser erste Teil ist im Prinzip eine Ansammlung an Tips/Ideen, wie man schneller werden kann. Ich möchte hierzu ein paar Beispiele nennen.

• Tip: Mehrfache Zwischenablagen nutzen (schon vi/emacs kannten diese Prinzipien)
• Tip: Üben beim Programmieren immer die Tastatur gegenüber der Maus bevorzugen -> Lustiges Plugin von IntelliJ (Key Promoter) – Jedesmal, wenn man ein Menu mit der Maus anwählt, erscheint ein Popup mit dem entsprechenden Shortcut
• Tip: Die Konsole muss man beherrschen – unglaublicher Boost in der Produktivität
• Tip: Mehrere Monitore für erhöhte Produktivität
• Tip: Virtuelle Monitore nutzen, um Arbeitsgebiete zu unterteilen (z.B. Programmieren / Kommunikation / Planung)
• Tip: Alles automatisieren, was irgendwie möglich ist
• Tip: Reguläre Ausdrücke kennen/lernen

Teil 2 – Praxis

Der zweite Teil beschäftigt sich mit Themen wie TDD / Automatisierung / Statische Analyse / Softwaredesign (SOLID, YAGNI, Patterns) und Refactoring. Es werden viele unterschiedliche Themen der Praxis behandelt und in wenigen Abschnitten erklärt.

Fazit

Vor allem der erste Teil hat mir sehr gut gefallen. Der Author gibt sehr viele Tips, wie man effektiver arbeiten kann. Auch gibt er einige Tooltips für die verschiedenen Umgebungen (Linux, Mac, Windows). Ich habe mir einige Dinge zu Herzen genommen (Regex besser lernen, vi(m) lernen, mehrfache Zwischenablagen nutzen, …). Und ich muss jetzt schon sagen, dass ich einiges effizienter geworden bin.

Der zweite Teil ist ok, mehr aber nicht. Wer sich mit Softwarequalität und Softwaredesign beschäftigt hat, erfährt nicht viel Neues. Ich finde es aber immer gut, Dinge zu wiederholen und in anderer Form präsentiert zu bekommen. Die Themen im zweiten Teil sind kurz und knackig formuliert.

Ich kann das Buch also empfehlen.

In letzter Zeit habe ich mich viel mit Testing und Softwarequalität beschäftigt. Da ich von diesen Themen und Tools überzeugt bin, habe ich sie bedenkenlos eingesetzt. Im Geschäft habe ich auch Jenkins aufgesetzt und betrieben.

Überzeugungsarbeit für den Codesniffer

Ich versuchte stets die Leute in den Projekten davon zu überzeugen, dass sie phpcs (PHP Codesniffer) auf der Konsole vor dem einchecken durchlaufen lassen sollten und dann entsprechend den Fehlern die Korrekturen durchführen sollten. Als sie meine Anweisung mit einem “WARUM?” erwiderten, antwortete ich jeweils, dass der Code so halt einheitlicher und aufgeräumter wirkt.

Warum überhaupt einen Codesniffer verwenden?

Auf einmal fragte ich mich selber, warum man einen Codesniffer einsetzen sollte. Bringt es dem Kunden einen Nutzen, wenn der Code dahinter “schön” und einheitlich aussieht? Ich versuchte also herauszufinden, warum es Sinn ergibt, wenn man sich Standards bei der Formatierung hält.

Ich forschte also ein bisschen nach und bin auf zwei gute Erklärungen gestossen.

Keine Unterbrechung des Flows

Es ist allseits bekannt, dass etwas neues, unerwartetes viel mehr Energie kostet. Genauso ist es bei einem Codestyle, der die ganze Zeit wechselt. Man benötigt neben dem Lösen des Problems noch viel Energie, die verschiedenen Codestyles mental aufzuarbeiten.

Wenn man einen bestimmen Codestyle kennt, kann man sich auf die wahren Probleme konzentrieren. Die Klammern, Einrückungen usw. verschwinden und man konzentriert sich auf die Aufgabe.

Je weniger der Entwickler oder Reviewer gestört wird, desto schneller ist er mit seiner Arbeit fertig. Dies hat also einen positiven Nutzen für den Kunden.

Keine Diskussionen mehr über den Codestyle

Wenn man sich auf einen Standard einigt (z.B. Symfony2, PEAR, Zend, …), so müssen sich die Entwickler nicht mehr darüber streiten, wie Code formatiert werden soll. Dies bringt dem Kunden einen unmittelbaren nutzen, nämlich keine verschwendete Zeit mit Diskussionen über den Codestyle.

Feedback

Was haltet ihr vom Einsatz eines Codesniffers?

Warum sollte man ihn einsetzen oder warum gerade nicht?

Ich würde mich über Feedback freuen!