Code Review: Unterschied zwischen den Versionen

{{TOCRight}}Im Sopra werden jeden Woche ''Code Reviews'' von Studenten am Code der Studenten innerhalb einer Gruppe gemacht. Die Dozenten machen ungefähr auf der Mitte des Softwarepraktikums ein zustäztzliches Code Review am Projekt der Studenten.

Das Code Review soll jede Woche ein Task von ca. 2h sein und reihum von einem Gruppenmitglied erledigt werden. Das Code Review sollte in seinem entsprechenden Gitea-Ticket einen Kommentar mit Erkenntnissen und einen Commit mit Ergebnissen bekommen. Die Ergebnisse sollen im Sprint Review vom Reviewer vorgestellt werden.

Grudsätzlich soll ein Codreview '''die Codequalität verbessern'''. Im Allgemeinen ist das Vorgehen Code Reviews:

Die Reihenfolge die im Folgenden vorgeschlagen ist zielt darauf ab, dass jeder Student ein Code Review machen kann, unabhängig von seiner Programmiererfahrung. Deswegen beginnt das Review mit simplen syntaktischen Eigenschaften, und schreitet dann zu immer komplexeren Themen fort.

Der erste Schritt in einem Code Review ist, etwas zum Reviewen zu finden. Suche dir anhand der folgenden Prioritäten ein Stück Code (typischerweise eine Klasse) aus:

#Der Autor hat um ein Review gebeten, weil er ein interessantes Stück Code verfasst hat, z.B. das Routing, oder den Renderer

#Der Code wurde im Sprinttreffen als zu reviewen beurteilt (weil er unaufgeräumt oder verdächtig aussieht, weil er nicht richtig arbeitet, oder weil er zu kompliziert ist)

#Es ist Code der dich interessiert, und den du daher verstehen und untersuchen möchtest.

Beachte dabei, dass du nicht deinen eigenen Code reviewen kannst. Die Idee hinter einem Review ist die Codequalität durch ein zweites Paar Augen zu erhöhen. Durch das Austauschen über die Funktionsweise können dabei sowohl Reviewer als auch Autor etwas lernen. Der Code, der für das Review ausgesucht wird, sollte nicht zu groß sein, sodass man ihn auch in ca. 1h durchsprechen kann.

Bitte bleibe in deinem Review absolut sachlich. Übe Kritik am Code, nicht an der Person die den Code geschrieben hat. Versuche in deinem Review darauf einzugehen, ''was'' das Problem ist, ''wieso'' das ein Problem ist, und ''wie'' man das Problem lösen kann. Da im Softwarepraktikum die Zeit knapp und Projektfortschritt wichtig ist, können manche Probleme und Anmerkungen vielleicht auch nicht sofort repariert bzw. umgesetzt werden. Das mindert den Nutzen des Reviews aber nicht.

Beginne damit, den ausgesuchten Code zu lesen, und zu verstehen. Die folgenden Punkte führen dich nachdem du den Code gelesen und verstanden hast, durch das Code Review. Sie sind sind nach ihrer Komplexität und dem für sie benötigtem Wissen geordnet. Bei jedem Punkt finden sich außerdem Links zu zusätzlichen Informationen.

Grundsätzlich sollte der Programmcode selbst die Beste Dukumentation der genauen Details der Implementierung sein. Kommentare die einfach nur beschreiben was der Programmcode tut müssen bei jeder Änderung mit berücksichtigt werden und weichen dadurch schnell vom eigenlich Programmcode ab. Deswegen sollten Kommentare vor allem informationen geben, die nicht sofort aus dem Programmcode ersichtlich sind. Dazu gehören

*Erklärungen über ein Stück Code dessen Funktion nicht offensichtlich ist (auch wenn der Code so offeisichtlich wie möglich geschrieben werden sollte, lässt sich das machmal doch nicht vermeiden).

 

<pre>//recognises all labels of the form &quot;est:&quot; or &quot;estimate:&quot; followed by a number (not the infinite symbol)

re.compile(&quot;est(imate)*\s*:\s*(?P&lt;estimate&gt;[0-9]+((.|,)[0-9]+){0,1}).*&quot;)</pre>

*TODO Kommentare

Vermieden werden sollten auf jeden Fall Kommentare, die keine weitere Funktion haben z.B.: automatisch generierte Kommentartemplates ohne Inhalt, und Beschreibungen von offensichtlichen Dingen. Kommentare sollten so weit möglich zu Gunsten guter Namen (s.u.) gespart werden.

Zudem gibt es auch Dokumentation die in Form von Kommentaren in das Programm eingefügt werden kann. Diese sollten in erster Linie transportieren welchen Zweck ein Element erfüllt, und wie man es benutzen soll (z.B.: [https://docs.monogame.net/api/Microsoft.Xna.Framework.Quaternion.html Monogame Quaternion].