Codequalität lehren und lernen: Erfahrungen aus 6 Jahren Programmierausbildung

Pair Programming und Mob Programming

Inhaltsverzeichnis

Wenn mehrere Entwickler*innen in einem Projekt zusammenarbeiten, ist der Drang da, die Arbeit irgendwie aufzuteilen. Naiverweise könnte man N Entwickler*innen jeweils 1/N der Funktionalität zur Implementierung geben und nach einer gewissen Zeit die Einzelteile zu einem Produkt zusammensetzen. Klassisches "Divide and Conquer" anhand definierter Schnittstellen. So ähnlich haben viele unserer Teams die Projekte bearbeitet. Leider haben die Teile nach gut einer Woche Programmierung nicht immer so zusammengepasst wie geplant. Auch wenn das Zusammenstöpseln zur Abgabe noch geklappt hat, zeigte sich bei der Prüfung, dass jeder nur den eigenen Teil gut konnte. Die Versuche der Studierenden, sich den Code gegenseitig "vorzustellen", haben oft nicht gereicht. Ganz anders war das bei denen, die den Code gemeinsam entwickelt haben.

Beim Pair Programming bedient die eine Person das Keyboard, während die andere über die nächsten Schritte nachdenkt. Diese Art, ein Programm zu entwickeln, ist für Neulinge keine leichte Sache. Sie ist aber der beste Weg, um eine hohe Codequalität zu erreichen. Nicht nur, dass vier Augen mehr sehen als zwei; um auf eine gemeinsame Lösung zu kommen, muss diskutiert und abgewogen werden. Das erfordert Übung und eine hohe Sozialkompetenz. Am Anfang ist für viele der soziale Druck hoch, wenn sie sich oft vertippen oder ihnen die Funktionsnamen der Standardbibliothek nicht mehr einfallen. Hier wollen wir nicht darauf eingehen, wie Pair Programming funktionieren kann [7], sondern dazu ermutigen, es einfach auszuprobieren.

Mob Programming [8] geht sogar noch einen Schritt weiter. Hier sitzen mindestens drei Personen vor einem Rechner und erreichen dadurch eine noch bessere Qualität. Wir haben das als didaktisches Mittel in der Lehrveranstaltung bei der Besprechung der Übungen genutzt, sprich mit allen Studierenden vor dem Beamer. Es ist ein großer Aufwand, der sich dann rechtfertigen lässt, wenn die Qualität und der Wissenstransfer maximiert werden sollen.

Studierende, die wirklich gemeinsam die Projekte bearbeitet hatten, lieferten nicht nur bessere Ergebnisse, sondern brachten auch in der mündlichen Prüfung die besseren Argumente. Unternehmen können daraus lernen, indem sie vor allem ihren neuen Entwickler*innen die Möglichkeit geben, zu zweit oder in Gruppen zu programmieren. So können diese schnell eingelernt werden und früh zum Produktivcode beitragen. Insbesondere das Pairing von Berufseinsteiger*innen mit erfahrenen Kräften maximiert den Wissenstransfer und kann ein traditionelles Onboarding größtenteils ersetzen. Die Motivation ist dank schneller Fortschritte höher, der Bildung von Wissenssilos wird entgegengewirkt. Deswegen die Empfehlung an Young Professionals: Macht so viel Pair und Mob Programming wie möglich, um von den erfahrenen Kolleg*innen zu lernen.

Codereviews sind das zentrale Element in den Lehrveranstaltungen, da wir überzeugt sind, dass die gemeinsame Diskussion das geeignete Mittel ist, um Codequalität zu erlernen. Wie eingangs beschrieben, bestanden die Lehrveranstaltung, die Korrektur der Hausaufgaben, die Sprechstunden und Tutorien und auch die Abschlussprüfung aus Codereviews. Das schult das Auge für Code-Smells und verbessert die Argumentationsfähigkeit.

Der Erfolg von einem Codereview hängt daran, dass Lernende verstehen, warum ihre Implementierungsvariante ein Problem darstellt. Denn nur wenn sie dieses einsehen, können sie eine Lösung als Verbesserung annehmen. Das bedeutet, dass man den Code nicht nur knapp kritisieren sollte, sondern durchaus die Hälfte des Texts über das Problem schreiben kann. Auf der Lösungsseite schlägt man idealerweise eine konkrete Verbesserung in Form von Code vor und beschreibt deren Vorteile knapp.

Unternehmen raten wir deshalb, Ähnliches zu tun. Einsteiger*innen brauchen Feedback, mit dem sie etwas anfangen können, um sich zu verbessern. Die Abnahme von Code wird viel einfacher, wenn sie in kleinen Häppchen passiert und früh die Kriterien für die Codequalität diskutiert werden. Hierbei ist Pairing optimal, aber auch schriftliche Codereviews in einem Pull-Review-Workflow sind wertvoll, da er üblicherweise von jemandem verfasst wird, der an der ursprünglichen Entwicklung unbeteiligt war. So bekommt man eine weitere Perspektive auf den Code. Wenn man nur begrenzte Zeit hat, sollte man ökonomisch vorgehen: zuerst die schlimmen Probleme angehen, danach die weniger gewichtigen.