Teilautomatisierung des Wissensmanagements beim Code-Review-Prozess

bearbeitet von: Dennis Ventzke

Einleitung

Ein wichtiger Aspekt der Softwareentwicklung sind Code-Reviews. Sobald mehrere Entwickler zusammen an einem Projekt arbeiten, sollte es eine Form der Bewertung von geschriebenem Code geben, unter anderem um Fehler zu finden und die Codequalität aufrecht zu erhalten. Unabdingbar wird dies bei Open-Source-Projekten. Hier kann und soll grundsätzlich jeder Code beisteuern. Dementsprechend kann der Wissensstand der Beitragenden stark variieren - sowohl in Bezug auf allgemeine Programmierkenntnisse, als auch auf das Projekt an sich. Weiterhin kann die Vertrauenswürdigkeit des Beitragenden, die grundsätzlich bei einem festen Entwicklerteam jedem Mitglied entgegengebracht wird, nicht implizit angenommen werden.

Problemstellung

Code-Reviews sind jedoch auch sehr aufwändig. Nachdem ein (möglicherweise anonymer) Patch-Autor ein Problem im Projekt durch seinen geschriebenen Code gelöst hat und diesen einreicht, muss ein vertrauenswürdiger Gutachter diesen Code komplett nachvollziehen und evtl. testen, um bestätigen zu können, dass dieser Patch das Problem auch tatsächlich löst, keine schädlichen Nebeneffekte besitzt und keine Code-Konventionen des Projekts verletzt. Fällt dem Gutachter hierbei ein Problem auf, so sollte er dem Patch-Autor erklären, worin das Problem besteht, damit dieser den Patch nachbessern kann oder sie gegebenenfalls darüber diskutieren können. Handelt es sich hierbei um ein spezifisches Problem, das lediglich im Kontext des konkreten Patches relevant ist, so erscheint dieser Ablauf notwendig. Anders ist es bei wiederkehrenden Problemen, die auch außerhalb des Patches in regelmäßigen Abständen auftauchen, bzw. verletzten Prinzipien. Diese wurden bereits mehrmals vom Gutachter selbst oder von anderen Gutachtern beschrieben und müssten eigentlich nicht immer wieder neu erklärt werden. Konkret

Ziele der Arbeit

Um diesen Mehraufwand zu vermeiden, soll nun eine Wissensdatenbank erstellt werden, in der all diese wiederkehrenden Probleme aufgenommen werden können. Im Rahmen dieser Arbeit soll solch eine Wissensdatenbank für das Saros-Projekt entwickelt werden. Wenn einem Gutachter nun ein solches Problem auffällt, muss er nur noch auf den entsprechenden Eintrag in der Wissensdatenbank verweisen. Daraus ergeben sich jedoch eine ganze Reihe von Problemen bzw. Fragen, die im geklärt werden müssen.

Fragen zum Bedarf

Zunächst stellt sich die Frage, wie groß der Bedarf an solch einer Einsparung überhaupt ist. Konkrete Fragen:

Fragen zur Implementierung

Ebenfalls unklar ist die Implementierung der Wissensdatenbank. Eine Möglichkeit besteht darin, dass die Gutachter bei der erstmaligen Erklärung eines Problems ein Präfix in Wiki-Syntax einfügen, wodurch dann automatisch ein Eintrag in der Wissensdatenbank generiert wird (der über eine URL erreichbar ist). Bei späteren Durchsichten kann dann über dieses Präfix auf den Eintrag verlinkt werden. Auch hier treten mehrere Fragen auf:

Ablauf der Arbeit

Zunächst müssen die Fragen zum Bedarf geklärt werden. Hier entscheidet sich, ob sich eine Erstellung und Integration einer Wissensdatenbank überhaupt lohnt. Ist dies der Fall, muss untersucht werden, wie der derzeitige „state of the art“ ist. Gibt es bereits Lösungen für dieses Problem? Was sind deren Vor- und Nachteile? Gibt es noch andere Ansätze, die bereits verfolgt wurden? In diesem Kontext muss sich mit allen anderen oben genannten Fragen auseinandergesetzt werden. Aus diesen Erkenntnissen kann dann eine Lösung entwickelt und implementiert werden, die auf die Anforderungen des Code-Review-Prozesses im Saros-Umfeld abgestimmt ist.

Aufbau der Wissensdatenbank

Die Wissensdatenbank sollte eine eigenständige Webanwendung sein, die beispielsweise in Java implementiert werden kann und durch ein Gerrit-Plugin in den Saros-Code-Review-Prozess integriert wird.

Meilensteine

Meilenstein Nr. vergangen days KW Ziele target erreicht wrench
1   KW30 Java-Webanwendung ermöglicht das Verwalten von Einträgen sowie Reviews für Editoren DONE
2   KW32 Gerrit-Plugin ermöglicht Laden von Einträgen aus KB und Einreichen von Kommentaren
3   KW35 Grundsätzlicher Inhalt der Bachelorarbeit niedergeschrieben
4   KW38 Abgabe Bacheloarbeit

Wöchentlicher Fortschritt

Woche 1 (KW XX)

Aktivitäten

Ergebnisse

Nächste Schritte

Probleme