Effektive Codeüberprüfungen

Codeüberprüfungen sind ein wesentlicher Bestandteil jedes Softwareentwicklungsteams. Sie helfen Ihnen, die Wahrscheinlichkeit fehlerhaften Codes zu verringern.

Ich selbst mache nun seit mehr als 6 Jahren Codeüberprüfungen und habe in dieser Zeit mehr als 600 Pull-Anfragen überprüft. Ich schreibe diesen Beitrag jetzt, um meine Erkenntnisse zu teilen, in der Hoffnung, dass er sowohl dem Rezensenten als auch dem Rezensenten helfen wird.

Bevor wir der Frage nachgehen, was bei Codeüberprüfungen zu tun ist und was nicht, möchte ich die Bedeutung von Codeüberprüfungen hervorheben.

Normalerweise denken die Leute, dass Codeüberprüfungen eine untergeordnete Aufgabe sind, die nur die Zeit zwischen „Dev Done“ und „Ready for QA“ verlängert. Die oben genannte Aussage ist „wahr“, wenn die Kodexüberprüfungen „ nicht mit den richtigen Absichten “ durchgeführt werden.

Hier sind ein paar Szenarien, die darauf hindeuten, dass eine Codeüberprüfung durchgeführt wird, aber niemandem hilft:

1. Der Prüfer führt die Codeüberprüfung nur zum Zweck der Durchführung durch. Er genehmigt Anfragen, ohne sie anzusehen oder nur einmal durchzublättern.
   Diese Art von Prüfern wird bald als „einfache Prüfer“ abgestempelt und dann ins Visier genommen, um den Code schneller durchzubringen.
2. Der Prüfer führt die Codeüberprüfung durch, ohne die Aufgabenanforderungen zu verstehen
3. Der Prüfer fügt Kommentare hinzu, ohne tatsächlich zu begründen, warum die Änderung erforderlich ist
4. Der Prüfer prüft nur die Syntax und nicht die eigentliche Logik.
   Wenn ein Rezensent denkt, dass der Rezensent mehr weiß als er, wird dies zwangsläufig passieren.
5. Der Rezensent versucht nicht, die Gründe für einen Kommentar zu verstehen. Entweder folgt er den Kommentaren einfach blind oder ignoriert sie

Warum sollte ich den Code einer anderen Person überprüfen?
Man könnte denken, dass es keine Vorteile hat, den Code einer anderen Person zu überprüfen, da diese vielleicht glauben, dass sie nichts Neues lernen. Andererseits-

1. Prüfer erhalten einen Einblick in die Aufgaben, die im Team anstehen.
2. Sie lernen die im System vorhandenen Dienste kennen. Das verbessert die Wiederverwendbarkeit
3. Sie lernen neue Syntax oder Methoden zum Codieren und Ausführen von Dingen

Allerdings würde ich dennoch einige Dinge auflisten, die den Leuten bei Codeüberprüfungen normalerweise entgehen.

Generelle Richtlinien

1. Besonderes Augenmerk sollte auf die „Lesbarkeit des Codes“ und die „Wiederverwendbarkeit des Codes“ gelegt werden.
   Variablen- und Funktionsnamen sind beschreibend und aussagekräftig. Namen wie i, asollten nicht verwendet werden.
2. Code sollte nicht redundant sein (Codequalitätstools wie „sonarlint“ sind in diesen Fällen sehr hilfreich)
3. Unit-Testfälle sind ein Muss für die Utility-Funktionen
4. Die Arbeit jeder Funktion sollte klar definiert sein und dem Prinzip der Einzelverantwortung folgen
5. Überprüfen Sie die Protokollebenen. Der Inhalt des Protokolls sollte verwertbare Informationen enthalten.
   Etwas wie „Fehler aus Cache erhalten“ enthält keine verwertbaren Informationen
6. Wir sollten überall dort, wo es erforderlich ist, über Metriken verfügen
7. Überprüfen Sie, ob der Prozess (Protokollierung, externe Aufrufe, Datenbank, Cache) synchron oder asynchron sein muss
8. Die Leute schenken Unit-Testfällen normalerweise nicht viel Aufmerksamkeit. Es sollte darüber nachgedacht werden, ob alle Szenarien abgedeckt sind oder nicht
9. Für eine entscheidende Funktion, die sich auf die User Journey auswirken könnte, sollte man immer einen Fallback haben, um zum vorherigen Ablauf zurückzukehren
10. Der Prüfer sollte versuchen, Änderungen in mehrere kleinere Komponenten aufzuteilen und für sie unabhängig und so früh wie möglich Pull-Requests zu erstellen. Dies gibt dem Prüfer nicht nur mehr Zeit, sondern stellt auch sicher, dass Probleme (falls vorhanden) oder Randszenarien frühzeitig erkannt werden
11. Traue niemandem. Hinterfrage alles. Wenn wir dem Autor vertrauen, graben wir uns manchmal nicht tief in seinen Code ein.
12. Der Rezensent sollte seine Pull-Anfrage mindestens einmal Korrektur lesen, bevor er sie zur Überprüfung freigibt. Dadurch wird sichergestellt, dass grundlegende Dinge wie kommentierter Code, ausstehende TODOs, Leerzeichenänderungen usw. bereits vor der Freigabe der PR behoben werden
13. Überprüfen Sie die Quell- und Zielzweige, ob sie korrekt sind oder nicht.

1. Ob der externe Aufruf stark gekoppelt ist oder nicht (hoch gekoppelt bedeutet – ein Fehler im externen Aufruf führt zu einem Fehler in diesem Ablauf)
2. Zeitüberschreitungen und Wiederholungsmechanismen
3. Anforderungen an Probenahme und Ratenbegrenzung
4. Metriken für externe Anrufe (Latenz, Erfolgsquote)

1. Überprüfen Sie die Standard-TTL- und Cache-Aktualisierungslogik
2. Beim Hinzufügen eines Caches sollten wir auch die Anzahl neuer Einträge und die Cache-Trefferquote schätzen
3. Was passiert, wenn ein Fehler im Cache auftritt?
4. Im Falle eines neuen Cache-Clusters – ob Konnektivität vom Server zur Cache-Instanz besteht
5. Metriken für die Cache-Trefferquote
6. Eine Schätzung der Anzahl der Cache-Schlüssel, der durchschnittlichen Größe des Werts und der Sicherstellung, dass Infra über genügend Kapazität verfügt.

1. Überprüfen Sie, ob in der Datenbank ein korrekter Index für die neue Abfrage vorhanden ist
2. Im Falle einer neuen Datenbank – unabhängig davon, ob Konnektivität besteht oder nicht
3. Richtlinien zur Tabellenbereinigung, um im Falle von Dateneinfügungen im Laufe der Zeit große Tabellen zu vermeiden
4. Metriken für die neuen Abfragen

1. Entfernen Sie Leerraumänderungen aus der Pull-Anfrage.
   Wie? Darauf können Sie sich beziehen
2. Wenn mir die Anforderung nicht bekannt ist, überprüfe ich normalerweise die Aufgabe oder synchronisiere mich einmal mit dem Entwickler, um die Anforderung zu verstehen
3. Öffnen Sie Pull Request gleichzeitig auf GitHub/BitBucket und im lokalen Code-Editor.
   Den Code lokal zu haben hat mehrere Vorteile:
   - Sie können statische Code-Scan-Tools verwenden, um einige der häufigsten Probleme zu finden.
   - Die Code-Navigation ist viel einfacher
   . - Bei Bedarf können Sie den Code ausführen, um zu sehen, wie er sich verhält
4. Beginnen Sie an der Stelle, an der der Geschäftsablauf beeinträchtigt wird, und gehen Sie dann den Code von dort aus durch. Wenn ich zu einer anderen Datei wechsle, überprüfe im Pull-Request auf Github, ob sich diese Datei geändert hat oder nicht.
5. Fügen Sie im Falle eines Problems diesen Kommentar im GitHub hinzu und erwähnen Sie dabei, was geändert werden muss und warum. Zusammen mit etwas Referenzmaterial
6. Falls Sie mit der Überprüfung einer Datei fertig sind, markieren Sie sie als angezeigt, damit Sie auch Klarheit über den Fortschritt der Überprüfung erhalten und die Datei während der zweiten Codeüberprüfung vermeiden können (sofern keine Änderungen vorgenommen wurden) .
7. Wenn die Änderungen im Diff gering sind, überprüfe ich sie in einem Durchgang. Ansonsten unterteile ich die Rezension in kleine Phasen. Dadurch wird sichergestellt, dass die Qualität der Bewertung nicht beeinträchtigt wird. Wenn der Unterschied groß ist, beginnen wir im Allgemeinen nach einem bestimmten Punkt damit, die Änderungen zu akzeptieren, ohne groß darüber nachzudenken

Ich hoffe, dass Sie daraus zumindest eines gelernt haben. Wenn ja, stimmen Sie zu und erwähnen Sie auch Punkte, die ich möglicherweise übersehen habe. Ich werde sie auch dem Beitrag hinzufügen.

Prost und viel Spaß beim Bewerten!