Wie kann man besser programmieren? Zwei Experten haben ein neuartiges Lehrprogramm an der Universität Bamberg entwickelt und ziehen nun – sechs Jahre später – Bilanz. Das sind ihre vier wichtigsten Tipps und Erkenntnisse.
Guter Code ist nicht nur korrekt, er ist auch schön.
Schön bedeutet unter anderem: Er sollte gut testbar sein, lesbar und leicht zu erweitern. Schöner Code ist auch essenziell. Er tut, was er sagt und sagt, was er tut – und benötigt keine Kommentare. Man könnte auch sagen: Bei einem gut geschriebenem Code sind Form und Funktion eins.
Warum wird dann an deutschen Universitäten beim Programmieren so viel Wert auf Funktion, nicht aber auf die Form, beziehungsweise die Code-Qualität gelegt?
Im Berufsleben zu spät? Code-Qualität von Anfang an lernen
Genau das behaupten jedenfalls Linus Dietz von der TU München und Simon Harrer, Senior Consultant bei der Technologie-Beratungsfirma Innoq.
Vor gut zehn Jahren waren die beiden Doktoranden an der Universität Bamberg. Sie wurden damit beauftragt, zwei weiterführende praktische Programmierkurse zu gestalten. Die Idee dabei war klar: Sie sollten natürlich auch die Grundlagen des Programmierens lehren, aber mit einem besonderen Fokus auf Code-Qualität.
Denn insbesondere Berufseinsteiger haben meist kein Auge dafür und müssen sich dieses Wissen mühsam später in Fortbildungskursen aneignen. Genau hier wollte die Uni Bamberg ansetzen. Junge Studierende sollten nicht nur die Grundlagen von Code lernen, sondern auch die Architektur.
Nach sechs Jahren Programmier-Ausbildung haben Dietz und Harrer nun Bilanz gezogen. Diese vier Lehren lassen sich aus ihrer Erfahrung mitnehmen.
1. Schön programmieren muss Pflicht, nicht Kür sein
Dietz und Harrer sind Java-Experten. Entsprechend bestand ihre Programmier-Ausbildung an der Uni Bamberg aus fünf bis 15 Java-Klassen mit jeweils 2.000 Codezeilen und anschließender Bewertung.
Dabei war ihnen aber von Anfang an wichtig, dass der Code nicht nur auf Korrektheit, sondern auch auf die Architektur hin bewertet wurde.
Im Fokus stand dabei ein interaktiver Code-Review. Am Ende des Kurses absolvierten die Studierenden eine mündliche Prüfung, in der sie einen Code erklären und kritisch bewerten sollten sowie unbekannte Code-Beispiele in einem eigenen Code-Review bewerten sollten.
Was Dietz und Harrer schnell merkten: Schön programmieren war bislang freiwilliges Zusatzwissen gewesen. Natürlich gab es in der Bibliothek haufenweise Fachliteratur und die Studierenden wurden auch dazu angeregt, diese zu lesen. Doch nur die Top-Studierenden nahmen das Angebot wahr.
Diese, so die Erfahrung von Dietz und Harrer, waren auch im Berufsleben viel erfolgreicher. Es reichte also nicht, Code-Qualität als freiwillige Lektüre zu empfehlen. Sie mussten sie als verpflichtend in den Kurs integrieren.
Das Ergebnis: Die Diskussion der Studierenden verlief von Anfang an auf einem viel höherem Niveau.
2. Ohne Diskussion kein Lerneffekt
Besonders effektiv zeigte sich auch die interaktive Diskussion in den Kursen. Mittels Code-Review bewerteten die Studierenden die Arbeit ihrer Kommilitonen. Im ersten Schritt stand dabei das Lehren von Konzepten. Als Zweites folgte die Anwendung und als Drittes die Interaktion und die Diskussion.
Das bedeutete: Lösungsvorschläge wurden im Plenum begutachtet und so lange debattiert, bis es keine weiteren Verbesserungsvorschläge mehr gab und man alle möglichen Vor- und Nachteile besprochen hatte.
Insbesondere dieser intensive Austausch sei wichtig, um Studierenden die Qualität von Code nahezulegen, sagten Dietz und Harrer: „Die Diskussionen sind essenziell, um den Studierenden nicht nur ein Gespür für Verbesserungen zu geben, sondern auch um die Erwartungshaltung in Bezug auf Codequalität in den Programmieraufgaben zu setzen.“
3. Pair Programming statt statischer Codeanalyse
Die beiden Doktoranden experimentierten mit verschiedenen Lehrmethoden, unter anderem auch mit statischer Codeanalyse, also, vereinfacht gesagt, mit Programmen zur automatischen Fehleranalyse von Codes.
Dabei stellten sie schnell fest: Die Programme führten vor allem dazu, dass die Studierenden sich weniger mit dem Code beschäftigten und sehr viel mehr mit den Fehlermeldungen. Viele dieser Meldungen waren zudem völlig unnötig und erforderten sehr seltsame Workarounds.
Am Ende gab es zwei Ergebnisse: Studierende folgten sehr stur und ohne kritisches Nachdenken den Regelvorgaben oder sie waren überwiegend damit beschäftigt, die Fehlermeldungen auszumerzen. Um den Code an sich kümmerte sich kaum jemand.
Das passiert leider auch in vielen Unternehmen. Statische Code-Analyse kann zwar hilfreich sein, aber nicht, wenn sie nicht hinterfragt wird. Sinnvoller ist es, im Team die Regeln zu analysieren und gegebenenfalls zu überarbeiten.
Für die Lehre dagegen hatten die Dozenten sehr viel mehr Erfolg mit Pair Programming und Mob Programming. Dabei tippt ein Student den Code, während die anderen sich auf die nächsten Schritte konzentrieren. Damit werden nicht nur mehr Fehler vermieden, es wird auch mehr diskutiert.
Aus der Diskussion ergeben sich bessere und schönere Lösungen im Code. Die Studierenden konnten darüber hinaus aber auch in der Prüfung bessere Argumente für ihre Code-Lösungen vorbringen.
4. Programmieren mit Weitblick: Lernkultur schaffen
Die wichtigste Lehre, die Linus Dietz und Simon Harrer aus sechs Jahren Ausbildung gezogen haben, ist jedoch: Es ist wichtig, eine Lernkultur zu schaffen – und zwar eine, die über die Universität hinausgeht.
Denn, und das ist wahrscheinlich eine wichtige Lektion für das Programmieren insgesamt, man lernt nie aus. Der Werkzeugkasten, den man aus seiner Ausbildung mitbringt, ist wertvoll, aber bei Weitem nicht voll.
Wer also wirklich Programmieren lehren will, sollte dies mit Blick auf die Zukunft tun. Studierenden sollte klar sein, dass sie ihren Werkzeugkasten langfristig selbst mit Code-Workshops, Hackathons, Mentoring und anderen Fortbildungsmaßnahmen stetig erweitern sollten.
Denn schöner Code ist nicht etwas, das man einmalig lernt. Es ist vielmehr ein Prozess, an dem man täglich feilt.
Auch interessant:
