Table of Contents

Checklisten für Reviews

Um einen einheitlichen Qualitätsanspruch für alle Anwendungen gewährleisten zu können, werden vor dem Abschließen einer Aufgabe Code-Reviews durchgeführt. Das Auslösen eines Pull-Requests ist der Auslöser zu einem solchen Termin. Es sollte kein Code freigegeben werden, der keinem Code-Review unterzogen wurde.

Grundlage des Code Reviews ist die Entwicklungsrichtlinie. Darüber hinaus entscheidet der Reviewer über den Pull Request.

Hinweise zum Gebrauch

Ziel des Dokumentes ist es, dem Entwickler eine Hilfestellung zu geben, wie er seine Lösung auf die Anforderungen eines Code Reviews vorbereiten kann. Die aufgeführten Punkte sind in erster Linie ein Hinweis auf relevante Aspekte.

  • Selbst wenn alle Punkte berücksichtigt sind, müssen stichprobenartig Programmteile geprüft werden.
  • Punkte, die auf die jeweilige Funktionalität nicht zutreffen brauchen auch nicht berücksichtigt werden.
  • Alle Punkte zu berücksichtigen muss nicht zwangsläufig bedeuten, dass das Code Review erfolgreich verläuft.
  • Es gibt immer themenbezogene Sachverhalte, die man nicht in einer simplen Regel beschreiben kann. Für solche Fälle ist u. a. das zweite Paar Augen im Code Review gedacht.
  • Insgesamt kann eine solche Checkliste nie vollständig sein. Das bedeutet aber nicht automatisch, das andere Punkte irrelevant sind, nur weil sie nicht auf der Checkliste stehen.
  • Der Reviewer hat das letzte Wort, solange er damit die Entwicklungsrichtlinie nicht verletzt.

Checkliste

Die Kriterien sind wie folgt:

Nr. Beschreibung Prüfung ok
Grundsätzliches
0.1 Kann eine .app Datei erstellt werden
0.3 Kann die Lösung / App veröffentlicht werden
0.4 Code Analysis berücksichtigt (Warnings und Errors beheben)
0.5 Passendes Logo wird verwendet
0.6 Struktur der Extension in Ordnung
0.7 Permission Sets angelegt und in Ordnung
0.8 Kein auskommentierter Code vorhanden, kein Kommentar mit TODO, kein unerlaubter Kommentar
0.9 Tests geschrieben, wenn erforderlich
0.10 Target Branch ist korrekt
0.11 Automatische Code CleanUps (AZ AL Dev Tools) wurden ausgeführt
1 Tabellen
1.1 Felder sowie Tabelle mit Präfix benannt
1.2 DSGVO Property bei Feldern gesetzt
1.3 Fieldgroups eingetragen
1.4 DrillDownPageID gesetzt
1.5 LookupPageID gesetzt
1.7 DataClassification für alle Felder gesetzt
1.8 Keys richtig gesetzt (gibt es zusätzliche Sortierschlüssel, Keys sollen nicht doppelt vorhanden sein). Beispiel: Man Braucht keinen Key "Name" UND einen zweiten Key "Name", "Post Code".
1.9 Primärschlüssel sinnvoll und standardnah (z. B. Contact No. Und Line No. oder auch Entry No.)
1.10 Ist der Code gut strukturiert und lesbar
1.11 Sofern es Flowfelder gibt, nicht editierbar, ggf. durch Query ersetzen, nicht zu viele je Tabelle
2 Pages
2.1 Liste ggf. nicht editierbar, wenn es eine Card Page gibt (Liste mit Karte verbinden über CardPageID)
2.2 UsageCategory eingetragen
2.3 Application Areas eingetragen
2.4 Richtiger PageType für das gewünschte Vorhaben
2.5 Sind die Actions auf der Liste ebenso auf der Karte vorhanden
2.6 Karten - Sind die Fasttabs logisch und besitzen promoted fields- Sind Pflichtfelder eingerichtet- Gibt es sinnvolle Tooltipps- Additional Fields, Farben, Extended Field types etc.- Factboxen nötig?
2.7 Ribbon Bar, sind die Actions in die richtige Kategorie einsortiert (Reports, Navigate etc.)
2.8 Tool Tipps für Actions
2.9 Machen Shortcuts für bestimmte Actions Sinn
2.10 Für spezielle Pagetypen (Matrix- oder Explorerpage) prüfen wofür der Standard die einsetzt. Stichwort: Zweckentfremdung und Performance.
2.11 Usability der Page. Bei einer Kernpage gute Benutzerführung.
2.12 Setup Assistenten?
2.13 Sind für alle Elemente Captions benannt (Register, Factboxen, Actions etc.)
2.14 Actions mit 1:n Beziehung werden mit Plural bezeichnet (z. B. Mitglied -> Ehrungen, Debitor -> Bankkonten)
3 Code und Funktionsdesign
3.1 Sind Kernfunktionen als mindestens eine separate Codeunit entwickelt
3.2 Performance berücksichtigt (Find-Befehle, Schlüssel, Query etc.)
3.3 Clean Code Methoden berücksichtigt (siehe unten)
3.4 atomare Funktionen verwendet / jede Funktion löst nur eine Aufgabe
3.5 keine hart kodierten Strings genutzt (z. B. if "Source Code" = '001' then...)
3.6 Wenn wir Prozesse nachbilden, die der BC-Standard auch kennt, gehen wir nach dem gleichen Schema vor?Beispiel buchen: Gibt es eine Codeunit "Post Contribution Y/N" und eine Codeunit "Post Contribution"
3.8 Machen die Funktionen wirklich das, wonach sie benannt sind
3.9 Fehlende Einrichtungstabellen und Pflichtfelder werden mit gewolltem Error abgefangen.z. B. richtig MySetup.Get;falsch if MySetup.Get then;
3.10 Keine unerlaubten Kommentare im Quellcode
3.11 Quellcode formatiert
3.12 Es sind nur COMMIT im Quellcode die technisch sinnvoll sind
3.13 Option und Enum korrekt eingesetzt
4 Extension Technik
4.1 Sind meine Abhängigkeiten korrekt bzw. vollständig?
×
Vergrößertes Bild