Code-Reviews

Code-Reviews sind ein wichtiger Bestandteil der Qualitätssicherung und des Wissensaustauschs im Team. Durch Code-Reviews können Fehler frühzeitig erkannt und behoben werden, bevor sie in die Produktion gelangen. Darüber hinaus können Code-Reviews dazu beitragen, dass das Wissen im Team geteilt wird und die Qualität des Codes insgesamt verbessert wird.

Einleitung

Allen Kapiteln wurde eine eindeutige Nummerierung, der Richtliniennummer, hinzugefügt, um eine eindeutige Identifikation zu ermöglichen. Jede Richtliniennummer besteht aus dem Buchstaben GR(General Review) gefolgt von einer Nummer, die den Abschnitt identifiziert. Damit kann eine Regel eindeutig identifiziert werden, z.B. für ein Code-Review.

GR1 Domänenkenntnisse

Code-Reviews sollten von Personen durchgeführt werden, die über ausreichende Domänenkenntnisse verfügen, um den Code zu verstehen. Die Anforderungen müssen verstanden werden, um sicherzustellen, dass der Code den Anforderungen entspricht. Nur so kann er überhaupt sinnvoll überprüft werden.

GR2 Regeln

Die vereinbarten Regeln für Code-Reviews sind einzuhalten, um sicherzustellen, dass die Qualität des Codes gewährleistet ist.

Neben den hier aufgeführten Regeln sind die wichtigsten Fragen generell zu beantworten:

1. Ist der Code auch ohne Erläuterungen des Entwicklers verständlich?
2. Lässt sich der Code problemlos warten?
3. Funktioniert der Code wie erwartet?
4. Sind alle Anforderungen erfüllt?
5. Gibt es überflüssigen Code oder Kommentare?
6. Könnte die Aufgabe schon mit vorhandenen Funktionen gelöst werden?
7. Könnte der Code einfacher sein?
8. Sind die Tests ausreichend und sinnvoll?

GR3 Kommunikation

Code-Reviews funktionieren nur, wenn die Kommunikation zwischen den Teammitgliedern stimmt. Menschen machen Fehler und es ist wichtig, dass diese Fehler offen angesprochen werden können. Code-Reviews helfen daher nur, wenn sie in einer offenen und respektvollen Atmosphäre stattfinden und gute Code als gemeinsames Teamziel gesehen wird.

GR4 Zeitpunkt

• Code-Reviews sollen nicht erst am Ende eines Entwicklungsprozesses stattfinden, sondern bereits, wenn ein Teil des Codes geschrieben ist. Auf diese Weise können Reviews dazu beitragen, dass der Code bereits während der Entstehung verbessert wird und nicht erst am Ende, wenn der Großteil des Codes bereits geschrieben ist.

==[ Feature ]=============================[ Review ]==[ Merge ]

Schnelles und frühzeitiges Feedback ist wichtig, um sicherzustellen, dass nicht erst kurz vor dem Merge größere Umstrukturierungen notwendig sind.

==[ Feature ]==[ Review ]==[ Korrektur ]==[ Review ]==[ Merge ]

INFO

Insbesondere am Anfang eines Projektes ist es normal, dass viele Code-Reviews sehr groß und umfangreich sind. Das Team ist nicht nicht aufeinander eingespielt und viele Kodierregele sind noch nicht etabliert. Daher ist es wichtig, dass nicht nur Code-Reviews zeitnah, sondern auch Pair-Programming und eine gesunde Kommunikation im Team stattfindet.

GR5 Dauer

Code-Reviews sollen nicht in aller Eile durchgeführt werden, sondern mit Gewissenhaftigkeit und Sorgfalt. Daher sollte genügend Zeit für ein Code-Review eingeplant werden, um sicherzustellen, dass alle Aspekte des Codes überprüft werden können.

GR6 Ablehnung von Code-Reviews

Code Reviews sollen nicht einfach durchgewunken werden, sondern es soll auch die Möglichkeit geben, ein Code-Review abzulehnen. Andernfalls könnte es passieren, dass Code-Reviews nur noch oberflächlich durchgeführt werden, um Zeit zu sparen.

GR7 Persönliche Einstellung

Code-Reviews sollen nicht als Kritik an der eigenen Person, sondern als Verbesserungsvorschläge für den Code gesehen werden. Auf der anderen Seite ist es daher unangebracht persönliche Angriffe gegenüber dem Code-Reviewenden zu machen.

WARNING

Sollte ein Code-Review zu persönlich werden, sollte dies sofort angesprochen werden. Zu viele Korrektur-Kommentare deuten darauf hin, dass das Ziel des Reviewers und des Reviewten nicht übereinstimmen.

GR8 Gewissenhaftigkeit

Code-Reviews sollen gewissenhaft durchgeführt werden, um sicherzustellen, dass der Code den Anforderungen entspricht.

GR9 Gesamten Code prüfen

Code soll auf seine Gesamtheit geprüft werden und nicht nur die Änderungen eines Commits betrachtet werden. Andernfalls können Fehler übersehen werden, die sich aus der Interaktion verschiedener Teile des Codes ergeben.

GR10 Code lokal prüfen

Merge-Requests beinhalten oftmals nur die Änderungen, die in einem Branch vorgenommen wurden. Der Code sollte daher auch lokal geprüft und ggfs. ausgeführt werden, um sicherzustellen, dass er korrekt funktioniert.

GR11 Linting soll automatisiert sein

Linting-Regeln sollen automatisiert sein, um sicherzustellen, dass sie eingehalten werden. Code-Reviews sollen sich daher auf die Qualität des Codes konzentrieren und nicht auf die Einhaltung von Linting-Regeln.

GR12 Fehlerbehandlung

Es soll im Code geprüft werden, ob spezielle Fehlerfälle abgefangen werden. Dazu gehören z.B.:

• ob try-catch-Blöcke notwendig sind.
  • wurden alle möglichen Fehlerfälle abgefangen?
  • leere catch-Blöcke sind zu vermeiden.
  • Promise.catch-Block wird verwendet.
• Zugriffsverletzungen (Null-Pointer-Exceptions, undefined-Werte)
• Fehlerhafte Eingaben (z.B. falsche Formate)
• Fehlerhafte Ausgaben (z.B. unerwartete Werte, falsche Variablen)
• sicherheitsrelevante Fehler (z.B. SQL-Injections)
• Fehlerhafte Konfigurationen (z.B. falsche Pfade, absolute Pfade)