tderoussel/codebase-audit

Was macht codebase-audit?

Der Wert eines Audits liegt in der Priorisierung und der Evidenz, nicht in der Länge. Eine Erkenntnis ohne Dateipfad, Abfrageergebnis, PR-Nummer oder Zeilenanzahl ist eine Hypothese – kennzeichnen Sie sie als solche.

Verankern Sie das Audit im Code und in der Produktion, nicht in Dokumenten

Projektnotizen, Pläne und Statusdokumente sind Kontrollpunkte, keine Autorität. Beginnen Sie mit ihnen, um zu erfahren, was behauptet wurde, und überprüfen Sie dann gegen die Realität: den aktuellen Commit, den Datenbankzustand, PR-Prüfungen, Branches.

Wenn Dokumente und Code widersprechen, ist dieser Widerspruch selbst eine Erkenntnis – oft die wertvollste im Audit.

Eine Behauptung über die Produktion erfordert eine Abfrage gegen die Produktion. Kombinieren Sie dies mit einem Skill zur Verifikations-Gate für die technische Umsetzung.

Struktur

# <Umfang>-Audit (JJJJ-MM-TT)

## TL;DR
<Die drei wichtigsten Dinge und was Sie zuerst tun würden.>

## Teil 1 – Was Sie nicht sehen (blinde Flecken, priorisiert)
## Teil 2 – Fehlende Fähigkeiten (priorisiert, jeweils mit grobem Aufwandsschätzung)
## Teil 3 – Bestehende Fähigkeiten, die verbessert werden müssen (priorisiert)
## Teil 4 – Architekturänderungen (priorisiert, in einfacher Sprache)
## Teil 5 – Wenn ich die nächsten 30 Tage leiten würde
## Überprüfungsliste (während des Audits gefundene Abweichungen)

Priorisieren Sie alles. Eine unsortierte Liste mit 40 Ergebnissen ist eine nicht handhabbare Liste mit 40 Ergebnissen.

Prüfen Sie auf ruhende Funktionsgerüste, bevor Sie Aufwand schätzen

Fügen Sie jeder Lücke eine grobe Aufwandsschätzung bei und erklären Sie, was sie günstig oder teuer macht.

Die einzelne wertvollste Erkenntnis eines Audits ist normalerweise diese: Die meisten der hochwertigen „Lücken“ sind Tage Arbeit, nicht Wochen, weil die Gerüste bereits im Repository existieren, aber keine Aufrufer haben. Ein Feature, das bereits zu 80% gebaut ist, ist eine völlig andere Entscheidung als eines, das nicht existiert.

Durchsuchen Sie die Codebasis mit grep, bevor Sie etwas als fehlend erklären. Eine Funktion ohne Aufrufer ist der kanonische Fall – der Code ist vorhanden, nichts ruft ihn auf, und jedes Statusdokument beschreibt das Feature als abwesend.

Die Überprüfungsliste

Jedes Audit endet mit den Abweichungen, die es nicht auflösen konnte. Jeder Eintrag benennt:

• was behauptet wurde
• was beobachtet wurde
• welche Abfrage oder Prüfung es klären würde

Dieser Abschnitt ist der, den die nächste Sitzung tatsächlich verwendet. Schreiben Sie ihn, auch wenn er kurz ist.

Der Abschnitt „Ausdrücklich nicht lohnenswert“

Nennen Sie, was Sie geprüft und bewusst abgelehnt haben, zusammen mit dem Grund.

Audits, die nur das Backlog vergrößern, machen das Backlog nutzlos. Eine Erkenntnis, die Sie geprüft und verworfen haben, ist mehr wert als eine, die Sie nie erwähnen, weil sie verhindert, dass das nächste Audit sie erneut aufwirft.

Zurückgestellte Elemente sind keine Lücken

Alles, was als bewusst zurückgestellt oder für eine explizite menschliche Entscheidung zurückgehalten markiert ist, ist absichtlich zurückgestellt. Listen Sie es nicht als Lücke auf.

Ein bewusst zurückgestelltes Element als Erkenntnis wieder aufzugreifen, ist der Weg, wie zurückgestellte Entscheidungen versehentlich ausgeführt werden.

Ausgabe

Schreiben Sie das Audit dort, wo das Projekt es aufbewahrt. Wenn es ein vorheriges Audit ersetzt, geben Sie an, welches und was sich geändert hat – ein Ordner mit Audits sollte als Sequenz lesbar bleiben, nicht als Haufen.