Teilautomatisierung des Wissensmanagements beim Code-Review-Prozess

09 Aug 2023 - 17:03 | Version 3 | UnknownUser

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:

Wie oft treten solche wiederkehrenden Probleme auf?
Wie umfangreich ist die Beschreibung dieser Probleme?
Nimmt die Qualität der Beschreibungen mit der Zeit ab?
Wie sehr sind die Gutachter davon genervt, das gleiche Problem immer wieder zu erklären?
Wie gehen sie damit um?
Erklären sie es immer wieder ausführlich von Neuem?
Benennen sie das Problem irgendwann nur noch, statt es zu erläutern?
Durchsuchen sie alte Reviews, um vorhandene Erklärungen zu finden?
Führen sie eine eigene (externe) Wissensdatenbank für ihre Erklärungen?

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:

Woher weiß ein Gutachter, wie das korrekte Präfix für ein konkretes Problem lautet?
Ist das Etablieren eines gemeinsamen Vokabulars für die Wiki-Schlüsselwörter (feste Struktur, wenige Verben) ausreichend?
Wie wird mit doppelten Einträgen umgegangen?
In einigen Fällen sollen mehrere Erklärungen nebeneinanderstehen, in anderen sollen Einträge zusammengeführt werden. Wie werden diese Einträge zusammengeführt? Wem wird diese Aufgabe zugeteilt?
Steht die erhöhte Komplexität der Reviews noch im Verhältnis zur Zeiteinsparung bzw. Qualitätsverbesserung?

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.	KW	Ziele
1	KW30	Java-Webanwendung ermöglicht das Verwalten von Einträgen sowie Reviews für Editoren
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