Wer weiß was?

Wissensmonopole treten auch in Softwareprojekten auf. Ein Entwickler entwickelt fleißig an Teilen des Projekts. Dokumentiert er seine Arbeit nicht, bleibt das Wissen in seinem Kopf. Es bildet sich ein Wissens- oder auch Kopfmonopol. Wird der Entwickler nun krank oder kündigt, muss sich ein anderer mühsam einarbeiten. Das kostet Zeit und Geld. Wissensmonopole sollten also so früh wie möglich entdeckt und aufgelöst werden.
Wie findest du heraus, ob es in deinem Projekt Wissensmonopole gibt? Git kann dabei helfen diese aufzudecken.

Was ist Git?

git ist ein Versionskontrollsystem. Es ermöglicht Entwicklern gemeinsam an einem Projekt (in git „Repository“ genannt) zu arbeiten. Entwickler pflegen parallel Änderungen („Commits“) in das Repository ein. In einem git-Repository stecken allerdings nicht nur die Projektdaten. Denn git schreibt mit.

Git schreibt mit – Metadaten eines Gitprojekts

Zu jeder Änderung hält git auch Metadaten fest. Etwa das Änderungsdatum, den Autor oder die Anzahl veränderter Dateien. Einblick in diese Metadaten geben git-befehle wie zB. git log oder git blame.
Mithilfe dieser Metadaten können etwa folgende Fragen beantwortet werden:

• Welche Änderungen wurden in einem Zeitraum vorgenommen?
• Wie aktiv wird am Projekt entwickelt?
• Wie viele Entwickler sind (aktiv) am Projekt beteiligt?

Oder auch:

• Wo befinden sich mögliche Wissensmonopole im Projekt?

Diese Frage lässt sich mithilfe des git-Befehls git blame beantworten.
Als Beispielprojekt dient uns das Repository zu Visual Studio Code von Microsoft. Das Projekt ist öffentlich auf Github verfügbar. (Hinweis: Die Auswertung erfolgte zum 01.04.2020).

Ein paar Eckdaten zum Projekt:

• Rund 1.100 Mitwirkende (Contributors)
• 64.000 Commits
• 4.300 Dateien
• rund 900.000 Zeilen Code

Was macht git blame?

git blame zeigt für eine Datei zeilenweise in welcher Version sie von welchem Autor geändert wurde. Ein Beispiel:

#!/usr/bin/env bash

set -e

if [[ „$OSTYPE“ == „darwin“* ]]; then

realpath() { [[ $1 = /* ]] && echo "$1" || echo "$PWD/${1#./}"; }

Beispielausgabe von git blame

An der Datei wirkten 2 Autoren mit (Daniel Imms & Joao Moreno), die letzte Änderung erfolgte am 06.10.2017 (Zeile 1, rechts). Gibt es hier also ein Wissensmonopol? Vermutlich nicht. Denn: Je mehr Autoren an einer Datei mitwirken, desto unwahrscheinlicher ist ein Wissensmonopol. Dateien mit nur einem Autor hingegen deuten auf ein Wissensmonopol hin. So ließe sich jetzt jede einzelne Datei untersuchen. Doch übersichtlich ist das nicht. Die Lösung: ein Python-Script.

Das gesamte Projektverzeichnis git blamen

Mithilfe eines Python-Scripts (Link zum Projekt) führe ich automatisiert git blame auf allen Dateien unseres Projekts aus. Die Ergebnisse werden in einer .csv-Datei festgehalten. Doch die fertige .csv-Datei ist riesig. Sie besteht aus einer Zeile je Zeile Code des Projekts - also rund 900.000 Zeilen. So viele Daten lassen sich nur schwer überblicken. Wie wäre es stattdessen mit einer interaktiven Visualisierung, die Wissensmonopole farblich hervorhebt?

Visualisierung der Daten – Packed Circles

Hinweis: Die Idee zu dieser Visualisierung stammt aus dem Blogartikel „Knowledge Islands“ von feststelltaste.de
Mithilfe der Javascript-Bibliothek d3.js erstelle ich aus unseren Daten eine Packed Circles Visualisierung. Die fertige Visualisierung sieht etwa so aus:

Ausschnitt einer Packed Circles – Visualisierung (Kontrast erhöht)

Die Kreise stellen die Ordner und Dateien unseres Projekts dar. Die innersten Kreise (rot/grün/gelb eingefärbt) bilden Dateien ab. Die umschließenden Kreise stellen die Ordner dar, in denen sich die Dateien befinden.
Per Klick navigiert man in die einzelnen Ordner. Die Darstellung zoomt dann in den angeklickten Ordner hinein. Per Mouseover lassen sich weitere Informationen, wie Anzahl der Codezeilen oder die Anzahl der Autoren, anzeigen. Der Link zur fertigen Visualisierung findet sich hier.
Klick dich doch einmal durch die Visualisierung. Kannst du mögliche Wissensmonopole erkennen?

Wissensmonopole aufdecken

Die Dateien sind nach Anzahl der Autoren eingefärbt. Häufungen von Dateien mit nur einem Autor (rot eingefärbte Kreise) zeigen also mögliche Wissensmonopole.
Hier ein Beispiel:

Ein mögliches Wissensmonopol?

Im Bild lassen sich 2 Häufungen von Dateien mit nur einem Autor erkennen. Diese befinden sich zudem in unterschiedlichen Ordnern.
Werfen wir einen Blick auf eine der Dateien: en-belgian.win.ts Die zusammengefasste Änderungshistorie der Datei sieht so aus:

f90a0ab

a24d186

308686a

dc13c53

Die Änderungshistorie zeigt: 

• Die Datei hat nur einen Autor (Peng Lyu) 
• Sie wurde zuletzt vor über einem Jahr geändert (2019-06-21 12:03:26)

Auch die anderen Dateien in demselben Ordner haben nur Peng Lyu als Autor. Ein mögliches Wissensmonopol. Warum ich nur von einem „möglichen Wissensmonopol“ spreche? Nun, die Visualisierung muss mit Vorsicht interpretiert werden.
Was passiert etwa, wenn ein Autor eine leere Zeile an eine Datei anfügt? git blame zeigt dann für diese letzte Zeile den neuen Autor an. Die Datei hat jetzt 2 Autoren und ist kein rot dargestellter Kreis mehr in unserer Darstellung. Doch ist das Wissensmonopol dadurch aufgebrochen?
Trotzdem erlaubt die Visualisierung sich schnell einen Überblick über das Projekt zu verschaffen. Mögliche Wissensmonopole lassen sich rasch identifizieren. Diese sollten dann genauer geprüft werden. Gegenmaßnahmen wie Code-Reviews können dann durchgeführt werden, um diese Wissensmonopole aufzubrechen.

Oftmals reicht es aber auch schon zu wissen, wer ein Wissensmonopol hält. So auch in unserer kleinen Waffeleisen-Anekdote.
Da ich wusste, wer unser Waffeleisen verschenkt hat, hakte ich nach: „An wen hast du das Waffeleisen verschenkt?“. „An unsere Nachbarn von oben.“. Ich stiefelte also das Treppenhaus hoch, klingelte und lud unsere Nachbarn auf ein paar Waffeln aus ihrem neuen Waffeleisen ein.

Projektlink zum verwendeten Code

Den verwendeten Code samt Benutzungsanleitung gibt es auf github. Schau doch einmal in ihr github-Repository. Vielleicht entdeckst auch du mögliche Wissensmonopole in deinem Projekt.