Dies ist ein neues Blog, geschrieben von Christian Meesters, Computational Scientist in Mainz:
Wegen eines Rechenfehlers wird die Sanierung des Burgbergtunnels bei Bernkastel-Kues deutlich teurer. Bei der Berechnung des benötigten Betons wurde zuerst Quadrat- statt Kubikmeter verwendet.
Ui, sind die doof!
Diese Meldung hat mich an etwas denken und mich meinen Erstlingstext komplett überarbeiten lassen. Denn mir kam eine Anekdote in den Sinn, die meine Kollegen und Kolleginnen vielleicht zum Überdruß kennen: Während meiner Promotion habe ich eine Software zur Modellierung der Konformation von Proteinkomplexen gegen Röntgenstreudaten geschrieben. Kurz gesagt: Damit konnte die Gestaltsänderungen von großen Eiweißen nachvollzogen werden. Zwei Wochen lang habe ich mich mit einem Problem herumgeschlagen: Was auch immer ich änderte – meine Moleküle “explodierten”. Nach langem Suchen bin ich schließlich auf die Ursache gekommen: Ich hatte Radius und Durchmesser der Atome verwechselt!
Auch ich mache – ehrlich gesagt – kleine, vermeidbare Fehler bei Schreiben von wissenschaftlichem Code. Ich kann nicht sagen, warum den Verantwortlichen besagter Tunnelsanierung dieser Fehler unterlaufen ist. Wichtig ist: Niemand ist vor solchen Fehlern sicher!
Bekannt ist, dass in so ziemlich jedem Softwarecode Fehler schlummern und die Zahl der Fehler pro Codezeilen unabhängig ist von der gewählten Programmiersprache.
Anfänger machen andere Fehler
Ab und an unterrichte ich Programmierung. Und das ist nicht leicht, weil jedem Programmierunterricht einige Schwierigkeiten innewohnen – aber darüber möchte ich ein anderes Mal mehr schreiben. Wichtig ist: Anfänger machen immer wieder bestimmte Fehler. Da muss ich tolerant sein, ich war auch mal Anfänger. Und ich bin überzeugt: Die gute Verwendung einer Programmiersprache lernt man nicht in einem Kurs, sondern durch Anwendung. Das ist ganz ähnlich wie beim Lernen von natürlichen Sprachen (in der Schule habe ich bestenfalls Grundlagen gelernt).
In meinem aktuellen Job habe ich täglich mit dem Code anderer Leute zu tun. Ich arbeite nämlich als “Computational Scientist” und betreue an einem Großrechner MedizinerInnen und BiologInnen, die bei uns rechnen möchten.
Oh, keine Angst, dies wird nicht noch ein Blog über Bioinformatik. Doch: Wenn von “Code” die Rede ist, dann eben von Zeilen eines Programms in einer Programmiersprache.
Mich treibt das Verhältnis von Lehre und Wissenschaft um. Und auch darüber wie Lehre Umsetzung findet, wie man also Lehre gestalten kann bzw. sollte. Und ich finde zu guter Lehre in der (Bio-)Informatik, jedenfalls dort, wo Programme geschrieben werden, gehört “Code Review”.
Und was ist Code Review?
Na ja, wie der Name sagt geht es um einen Prozess bei dem ein Stück Computercode untersucht wird. Im Allgemeinen soll sichergestellt werden, dass das fragliche Programm funktioniert. Und natürlich möchte man verbessern wo möglich. Das ist zwar eine etwas verkürzte Darstellung, aber auch an den Universitäten wird Code Review praktiziert. Meist schauen sich die Erfahrenen einer Arbeitsgruppe ihre Änderungen untereinander und die der “Neuen” an, suchen nach Fehlern, geben Tipps zur Struktur etc..
Warum ist das wichtig? Schließlich sind alle Beiteiligten kompetent und wissen was sie tun, oder? Sicherlich kann man Programme veröffentlichen ohne das ständig jemand über die Schulter guckt. In der Praxis gibt es eine Reihe von Gründen, warum die Kontrolle durch Dritte zur Kultur gehören sollte:
– Fehlerrisiken werden limitiert – Das ist der wohl wichtigste Grund. Das Vieraugenprinzip schadet selten und die Gefahr übersehener Fehler sinkt einfach. Auch gute EntwicklerInnen leiden ab und zu unter dem Tunnelblick.
– Code Qualität verbessern – Hierzu vorweg: Es geht nicht um Standards und Korinthenkackerei. Es geht darum, Code effizienter zu machen: In einem Team wo jeder einen bestimmten Hintergrund und eigene Stärken hat, schadet es einfach nicht nach Vorschlägen zu fragen. Es ist immer eine gute Idee. Irgendjemand wird fast sicher eine elegantere Lösung in petto haben, ein geeigneteres Lösungsmuster, eine schlichtere Lösung oder auch nur den Code schneller machen.
– Alle profitieren – Wenn man zusammenarbeitet, können alle im Team dazulernen und besser werden. Wer den Code beiträgt bekommt Feedback, wird darauf hingewiesen, wo mögliche Probleme sind. Auch die Reviewer profitieren, lernen vielleicht etwas für ihre Aufgaben, lernen bestimmt etwas durch das Lesen der Arbeit der KollegInnen.
– Die Persönlichkeit profitiert – Man lernt ganz schnell Kritik so zu formulieren, dass sie sachlich bleibt. Sonst …
– Man kennt das Projekt besser – Wenn ein Team an einem Projekt arbeitet, ist es verdammt unwahrscheinlich, dass alle EntwicklerInnen auf dem selben Stand sind. Manchmal arbeiten einige fokussiert auf bestimmte Teilfragen. Jemand anderer arbeitet auf einem ganz anderen Teil des Projektes.
Wie geht Code Review?
Viele Wege führe nach Rom. Und es gibt verschiedene Ansätze zum Code Review . Nehmen wir an, dass das fragliche Projekt einen Aufbewahrungsort hat, auf den alle Teammitglieder Zugriff haben. Wer ein Stück Arbeit erledigt hat, fragt an dieses Stück dem Projekt zuzufügen (häufig ein sog. “Pull Request”) und einem Kollegen wird die Aufgabe zugewiesen sich das Stück Programmcode durchzulesen. Eine gute Versionsverwaltung lässt dann zu genau diesem Codestück einen Unterhaltungthread zu, ähnlich den Threads hier in Scienceblogs.
Was es braucht ist vor allem Zeit, bzw. das Wissen das Code Review Zeit und Ressourcen spart. Wenn jedes Teammitglied sagt “keine Zeit!” auf die Bitte “schau’ auf meinen Code”, dann läuft etwas verkehrt. (Natürlich kann man mal keine Zeit haben, aber nicht immer.) Man kommt auf andere Gedanken, kann miteinander reden – hinterher gibt es weniger Wartungsaufwand oder hektisches Korrigieren von Fehler (wodurch meist neue Fehler entstehen). Ihr versteht schon … Und es braucht Kontext. Wie gesagt, jedes Teammitglied arbeitet an bestimmten Aufgaben. Also müssen EntwicklerInnen kurz beschreiben, worum es in ihrem Beitrag geht.
Natürlich hängt der Prozess vor allem von der Gruppengröße ab. Vier Leute in einem Raum können ganz anders miteinander handeln als ein Dutzend verteilt über Kontinente. Wenn die Angst vor Fragen dem Wissen um den Mehrwert gewichen ist und man sich kennt, können verschiedene Hilfsmittel gut den Review-Prozess erleichtern.
Zu guter Letzt
Das klingt jetzt nach Werbung für agile Softwareentwicklung, oder? Nein, darum geht es mir nicht. Sondern darum, dass Anfänger auch Designentscheidungen treffen, die sich kaum korrigieren lassen: Wie oft habe ich schon veröffentlichte Software gesehen, die mir mit der Frage vorgestellt wurde: “Wie geht das schneller?” Und meine Antwort musste sein: “Gar nicht.” Ganz einfach, weil selbstverständlich langsame Software schneller gemacht werden kann (fast immer), aber es muss jemand tun. Und wenn das Projekt schon (fast) abgeschlossen ist, gibt es einfach praktische Grenzen.
Überall zwischen Design und Radius/Durchmesser-Verwechseln kann Code-Review helfen. Und auch Nicht-ProgrammiererInnen unter Euch können das hoffentlich sofort nachvollziehen: Mal ehrlich, wer hat nicht einen Fehler in der Kategorie Quadratmeter mit Kubikmeter-Verwechseln schon mal selber gemacht?
Ich kenne wenige Projekte, bei denen im akademischem Umfeld Code Review und eine gute Gruppenkultur gelebt werden und viele bei denen das nicht der Fall ist. Hier geht es um vertane Chancen zur Ausbildung. Und um die Chancen auf dem Arbeitsmarkt anzukommen. Deshalb ist Code-Review in Unternehmen UND Unis relevant.
Kommentare (28)