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.
Kommentare (28)