Seite 2: Erfahrungen bei der Fachliteratur

Inhaltsverzeichnis

Wie an einer Universität üblich haben wir Fachbücher wie "Clean Code" [3] oder "Effective Java" [4] in großzügiger Anzahl über die Bibliothek angeschafft, in der Lehrveranstaltung empfohlen und in deren Verlauf immer wieder darauf verwiesen. Ausgeliehen haben sie allerdings nur wenige. Über die Jahre war klar: Nur die Besten haben die Fachliteratur freiwillig studiert, der Rest gab sich mit den Vortragsinhalten zufrieden. Aus Dozentensicht war das trotz des geringen Aufwands unbefriedigend, da wir ja auch die Breite erreichen wollten.

In der Industrie sind unsere Erfahrungen ähnlich: Die Besten bilden sich freiwillig, oft auch in der Freizeit, selbstständig weiter. Diejenigen, die dazu nicht bereit sind oder es aus privaten Gründen einfach nicht möglich machen können, fallen zurück. Das bedeutet, dass die Anschaffung von Büchern in der Abteilungsbibliothek, die Bereitstellung von E-Books im Intranet oder das Abo einer Online-Lernplattform eben nicht ausreichen.

In unseren Kursen hatten wir auch die Möglichkeit, Pflichtlektüren als Hausaufgabe zu geben, die dann gemeinsam im Plenum besprochen wurden – zum Beispiel ein Kapitel aus Martin Fowlers Refactoring-Buch [5] oder ein Artikel zum Thema Concurrency [6]. Dadurch dass die Inhalte von überschaubarem Umfang waren und zudem genau zum Stoff passten, haben die meisten sie gelesen und die fachliche Diskussion war dementsprechend direkt von Anfang an auf einem hohen Niveau. In der Ausbildung ist eine solche Pflichtlektüre mit Nachbesprechung in der Veranstaltung ein geeignetes Mittel, um ein wichtiges Thema voranzutreiben. Das ist auch eine Empfehlung, die in Unternehmen funktionieren kann, wenn es gelingt, sowohl für das Vorbereiten als auch für die Besprechung Arbeitszeit vorzusehen.

Statische Codeanalyse

Statische Codeanalyse verspricht ein unvoreingenommenes, vollständiges und vor allem günstiges Codereview, das Code-Smells automatisch und zuverlässig aufdeckt. Sie verhindert, dass unausgereifter Code in den Produktivbetrieb kommt. Von diesen Versprechungen geleitet haben sich entsprechende Werkzeuge stark verbreitet.

In der Lehre haben wir das auch ausprobiert. Wir stellten den Studierenden die einschlägigen Open-Source-Werkzeuge vor und erklärten die Einbindung in die IDEs. Das kostete Zeit, die wir in der Hoffnung auf weniger Korrekturaufwand gerne investierten. Das Ergebnis blieb weit hinter den Erfahrungen zurück. Zum einen zeigte sich, dass viele sowohl die Codeanalysewerkzeuge als auch die Standardwarnungen der IDE komplett ignorierten. Zum anderen stieg der Betreuungsaufwand während der Programmieraufgaben, da immer wieder Rückfragen kamen, wie denn Meldung "X" zu beseitigen wäre. Bei näherer Betrachtung waren das meist false-positives beziehungsweise komplett irrelevante Regeln, die getrost hätten deaktiviert werden können. Im schlimmsten Fall sahen wir obskure Workarounds für relativ einfache Funktionen, um die Warnungen loszuwerden.

Die Einführung statischer Codeanalysewerkzeuge war also mit einem mittleren Aufwand verbunden, brachte aber kaum etwas. Teils wurden die Werkzeuge ignoriert, teils gingen insbesondere die motivierten Studierenden über große Längen, um alle Hinweise systematisch zu eliminieren, was wiederum nicht förderlich für den Lernprozess war. Hier greift das Goodhart'sche Gesetz: "Wenn eine Metrik zum Ziel wird, ist sie keine gute Metrik mehr."

Im Unternehmenskontext gibt es häufig folgendes Muster: Jemand, dem Codequalität wichtig ist, stellt stichprobenhaft fest, dass sie nicht ausreichend ist. Da die Person nicht die Zeit hat, alles selbst zu reviewen, sorgt sie für die Einführung von Codeanalysewerkzeugen. Um alle Fehlerquellen abzudecken, werden dann viele der im Werkzeug vorhandenen Regeln aktiviert und als Vorgabe ausgegeben. Infolgedessen geht die Produktivität des Teams nach unten: Es wird etwa der Getter des Feldes "firstname" mit "Gets the firstname" dokumentiert. Nur hat das nichts mit Codequalität zu tun, sondern ist eine Arbeitsbeschaffungsmaßname.

Dass Unternehmen statische Codeanalyse "erfolgreich" einsetzen, möchten wir nicht in Abrede stellen. Aus unserer Erfahrung ist sie allerdings kein geeignetes Mittel, um ein Gespür für hochqualitativen Code zu erlernen. Für Studierende, aber auch für Berufseinsteiger*innen läuft der Einsatz statischer Codeanalyse zumeist auf das unreflektierte Befolgen von Regeln hinaus, statt die Dinge zu hinterfragen. Selbst bei einer sinnvoll konfigurierten Regelauswahl tritt oftmals ein ähnlicher Effekt wie bei der Fachbuchanschaffung ein: Den Guten hilft es, noch einen Flüchtigkeitsfehler zu tilgen, die Schwächeren werden frustriert und ignorieren die Werkzeuge in Gänze. Hilfe könnte sein, die Regeln gemeinsam im Team zu besprechen und zu diskutieren – und dabei eben ein Gespür zu schaffen, wann man nach Benedikt von Nursia eher die Regel beugen soll als den Menschen.