---
title: "Vielaugenprinzip: Code Reviews"
url: "https://www.intersim.ch/insights/vielaugenprinzip-code-reviews"
description: "«Sei dankbar für jedes Code Review, denn jemand hilft dir dabei besser zu werden.»"
---

# Vielaugenprinzip: Code Reviews

[Technik & Innovation](/insights/?filter=technology-innovation)

 ![Entwickler schaut sich Code an](/_astro/codereview-mit-entwickler._WbetMgo_PoMcF.jpg)

«Sei dankbar für jedes Code Review, denn jemand hilft dir dabei besser zu werden.»

Autor:in

Alexander Moser

Veröffentlicht

29\. Oktober 2019

## Vielaugenprinzip

In einem früheren Artikel hat meine ehemalige Kollegin Natalie die Technik des [Pair Programmings](/insights/pair-programming-oder-warum-zu-viele-koche-nicht-immer-den-brei-verderben) vorgestellt. Auch wenn ich persönlich ein Fan dieser Vorgehensweise bin, ist es leider in der Praxis aus verschiedenen Gründen nicht immer möglich, diese zu praktizieren. Das nächstbeste was man machen kann, sind Code Reviews. Bei Code Reviews wird sämtlicher geschriebener Code noch einmal durch eine – mehr oder wenige – unabhängige Person gesichtet. Wichtig dabei ist, dass der Code möglichst früh und möglichst oft reviewt wird. Nur so hat man noch eine Chance, eventuell während dem Review gefundene Punkte umsetzten zu können, ohne gleich das komplette Projekt auf Links drehen zu müssen.

## Ohne Review geht gar nichts

Seit ich anfangs Jahr für die Intersim arbeite habe ich am gleichen Projekt mitgewirkt. Innerhalb dieses Projektes haben wir das mit den Code Reviews konsequent durchgezogen. Keine einzelne Zeile Code, die heute auf dem Server unseres Kunden ausgeführt wird, wurde nicht durch unseren Softwarearchitekten Mark reviewt.  
Wir setzen dafür einen Prozess ein, der in Entwicklerkreisen unter dem Namen «Pull Requests» oder auch «Merge Requests» bekannt ist, zu Deutsch in etwa «Antrag auf Übernahme \[der Änderungen\]». Bei diesem Prozess haben alle Entwickler ihre eigenen Versionen der Software, an der sie nach Belieben Änderungen vornehmen können. Bevor die getätigten Änderungen allerdings in die «offizielle» Version übernommen werden, müssen sie durch Mark reviewet und abgesegnet werden. Das Versionsverwaltungssystem Git sowie die darauf aufbauenden Entwicklungsplattform GitLab unterstützen uns bei diesem Prozess. GitLab kann sogar so konfiguriert werden, den Prozess zu erzwingen.

Aus aktuellem Anlass bin ich mal unsere bisherigen Reviews durchgegangen und habe geschaut, worüber wir denn so diskutiert haben. (Ich habe also quasi unsere Code Reviews gereviewt, hö hö hö.) Wahrscheinlich häufiger als wir beide zugeben wollen, haben wir über die Benennung von Klassen, Variablen und Co. diskutiert. Aber das ist ja ein bekanntes Problem…

## Der Nutzen eines Reviews

Nebst vielen relativ unbedeutenden Sachen sind Mark aber auch manchmal Dinge aufgefallen, die Einfluss auf die Leistung und Sicherheit unseres Projektes haben. Eine Funktion in unserem Projekt ermöglicht es zum Beispiel, ein PDF zu generieren und dieses danach als E-Mail zu versenden. Das PDF-Dokument zu generieren ist eine ziemlich aufwändige Operation, allerdings habe ich erst danach überprüft, ob der Benutzer dazu überhaupt berechtigt ist. Es konnte also vorkommen, dass das Dokument unnötig generiert und verworfen wurde. Dies widerspricht dem «Fail Fast»-Prinzip.

Eine andere Funktion unseres Projektes liefert eine Liste der Namen bereits erfasster Kunden für die Auto-Vervollständigungsfunktion eines Textfeldes. Dort hat sich allerdings ein Fehler eingeschlichen, der dafür sorgte, dass die Einträge nicht gefiltert wurden. Jeder Benutzer hätte also die Namen aller Kunden und nicht nur der eigenen erhalten. – Dies wäre ein gravierender Datenschutzmangel gewesen.

![Comic zum Thema Codereview](/_astro/comic-codereview.BQsebq8g_ZjxBQu.webp)

## Verwandte Themen

Weiterführende Projekte und Inhalte zum Thema

[AI](/projects/?filter=ai) [Mobile-App](/projects/?filter=app) [Commerce](/projects/?filter=commerce) [Website](/projects/?filter=web)