Checkliste für Code-Reviews #

Diese Seite ist eine Checkliste für die Prüfung einer Änderung an Exponential oder einer seiner Erweiterungen. Das Projekt macht viele Prüfrunden, bevor es eine Änderung annimmt (Upstream beitragen); eine gemeinsame Liste macht jede Runde kürzer. Kombinieren Sie sie mit der Checkliste für Sicherheitsprüfungen.

Inhalt #

1. Umfang und Historie
2. Architektur
3. Kompatibilität
4. Laufzeit
5. Tests und CI
6. Einstellungen, Templates und Gestaltung
7. Dokumentation und Release-Aufzeichnung

Umfang und Historie #

• To do: Eine Änderung je Pull-Request: eine Korrektur und ein Refactoring sind zwei.
• To do: Betreffzeilen von Commits beginnen mit Added: , Updated: , Fixed: , Removed: oder Renamed: ; der Text sagt warum und was (Git-Arbeitsablauf).
• To do: Das Produkt heißt Exponential; Kernel-Bezeichner wie eZContentObject bleiben, wie sie sind.
• To do: Keine Nennung von Werkzeugen, keine privaten Pfade, Zugangsdaten oder rechnerspezifischen Einstellungen in Commits.
• To do: Der Branch ist zu logischen Commits zusammengefasst und, solange er offen ist, auf main rebased.

Architektur #

• To do: Der Code liegt in der richtigen Schicht (Kernel, lib und Erweiterungen: die Schichtung): keine neue Abhängigkeit von lib/ auf kernel/, kein HTML, das eine Domänenklasse ausgibt.
• To do: Neuer Code verwendet das Präfix exp; nichts Vorhandenes wird umbenannt.
• To do: Ein Erweiterungspunkt wird vor einem Kernel-Override genutzt (Events, Erweiterungspunkte und Plugins).
• To do: Gemeinsame Logik ist eine Dienstklasse, nicht zwischen View, Befehl und Cronjob-Teil kopiert.
• To do: Einstellungen werden über eZINI gelesen; Debug-Ausgaben über eZDebug; Texte über ezpI18n::tr().
• To do: Für neue Klassen sind die Klassenzuordnungen neu erzeugt.

Kompatibilität #

• To do: Läuft auf PHP 8.0: keine neuere Syntax oder Funktionen ohne Absicherung; keine Typdeklarationen von PHP 7+ im Kernel-Code (Statische Analyse und Codestil).
• To do: SQL funktioniert auf jeder unterstützten Datenbank; Schemaänderungen werden für jeden Treiber ausgeliefert (Schemaänderungen und Migrationen).
• To do: Keine öffentliche Signatur, Einstellung, Template-Variable, Befehlsoption und kein Exit-Code wurde ohne Upgrade-Hinweise geändert (Richtlinie zur Rückwärtskompatibilität).
• To do: Neues Verhalten ist optional oder ein sicherer Standard, der das alte Ergebnis behält.

Laufzeit #

• To do: Korrekt in einem langlebigen Velocity-Worker: kein Zustand je Anfrage in Statics, idempotente Registrierungen, kein exit (Nebenläufigkeit, Statics und langlebige Prozesse).
• To do: Eine neue Klasse, die eine mitgelieferte INI-Datei nennt, ist mit class_exists() abgesichert.
• To do: Cache-Dateien werden über eZClusterFileHandler geschrieben; Caches haben IDs und Tags und werden invalidiert (Cache-Invalidierung und Leeren).
• To do: Befehle halten --help und Exit-Codes stabil und bieten --dry-run, wenn sie Daten ändern.
• To do: Leistung: keine Abfrage in einer Schleife, wo eine Abfrage genügt; messen Sie im Zweifel (Leistungsmessung und Benchmarks).

Tests und CI #

• To do: Ein Test schlägt ohne die Änderung fehl und besteht mit ihr.
• To do: Tests brauchen keine Datenbank, sofern sie nicht SQL testen, und lesen nichts aus der Installation eines Entwicklers.
• To do: Die Tests gehören zu einer Suite in phpunit.xml, sonst laufen sie nie.
• To do: Quality und PHPUnit sind beim Merge mit main grün (CI-Gates).
• To do: share/filelist.md5 hat die Prüfsumme jeder hinzugefügten, geänderten oder entfernten Datei (make manifest-fix).

Einstellungen, Templates und Gestaltung #

• To do: Eine neue Einstellung hat ihren Standard und einen Kommentar in settings/<file>.ini; Schalter verwenden enabled/disabled.
• To do: Templates maskieren Ausgaben und enthalten kein SQL.
• To do: Administrations-Templates folgen Gestaltung der Administration: kein <style> oder style="", gemeinsame Komponenten und Tokens, ein Wert für den Dunkelmodus je neuem Token, Modul-CSS in stylesheets/modules/.
• To do: Geänderte Seiten im hellen und dunklen Modus und bei den Breiten geprüft, die die Administration unterstützt.

Dokumentation und Release-Aufzeichnung #

• To do: Die Funktionsseite in doc/eng-us/features/6.0/ ist geschrieben oder aktualisiert.
• To do: Das Changelog führt die Änderung (Changelogs und Upgrade-Hinweise).
• To do: Eine Änderung, die von Installationen eine Handlung verlangt, hat eine Seite in doc/eng-us/bc/6.0/.
• To do: Hilfeseiten, die die Änderung berührt, bestehen exp:help check (Dokumentation als Code).

Verwandte Seiten #

• Checkliste für Design-Reviews
• Umgangsformen bei Pull-Requests
• Codierstandards
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.