Risikoklassen für Änderungen: nicht jede Zeile verdient dieselbe Aufmerksamkeit
Die gleichmäßige Behandlung aller Änderungen wirkt gerecht und ist der Grund, warum Prüfung überall gleich dünn wird. Wer dieselbe Sorgfalt auf einen Tooltip und eine Zahlungsroutine verwendet, hat für keins von beidem genug.
Risikoklassen ordnen Änderungen nach Schaden: Klasse A (Geld, Personendaten, Außenwirkung, Regulatorik), Klasse B (Fachlogik ohne Außenwirkung), Klasse C (kein Verhaltenseinfluss). Alle drei durchlaufen dieselben automatischen Prüfungen; unterschiedlich ist nur, wo zusätzlich ein Mensch entscheidet. Den Schnitt machen Architektur, Sicherheit und Fachbereich gemeinsam. Umfasst Klasse A mehr als ein Viertel der Änderungen, ist der Schnitt zu vorsichtig.
Der Schnitt folgt dem Schaden
Klasse A ist alles, wo ein Fehler Geld kostet, Personendaten betrifft oder nach außen wirkt: Zahlungsverkehr, Berechtigungen, Schnittstellen zu Kunden und Partnern, alles mit regulatorischem Bezug. Klasse B ist Fachlogik ohne Außenwirkung. Klasse C ist alles, was das Verhalten des Systems nicht ändert: Tests, Texte, Formatierung, Aktualisierungen von Bibliotheken innerhalb bekannter Grenzen.
Was in allen drei Klassen gleich ist
Die automatischen Prüfungen. Alle drei Klassen durchlaufen dieselben Gates — Tests, Abhängigkeits- und Lizenzprüfung, Geheimnis-Suche, Architekturregeln. Unterschiedlich ist nur, wo zusätzlich ein Mensch entscheidet. Dieser Punkt wird regelmäßig missverstanden: Klasse C heißt nicht ungeprüft, sondern ohne zusätzliche menschliche Entscheidung.
Wer den Schnitt macht
Nicht die Entwicklung allein und nicht die Revision allein. Der tragfähige Weg ist eine gemeinsame Sitzung von Architektur, Sicherheit und Fachbereich, in der die Codebasis nach Bereichen durchgegangen wird. Das dauert einen Tag und ist die wichtigste Sitzung im ganzen Vorhaben, weil danach jede Regel eine begründete Grundlage hat.
Woran man merkt, dass der Schnitt falsch liegt
An drei Signalen. Erstens: Fehler treten überwiegend in einer Klasse auf, die als unkritisch eingestuft wurde. Zweitens: Die Zahl der Ausnahmeanträge für eine bestimmte Regel steigt. Drittens: Klasse A umfasst mehr als ein Viertel der Änderungen — dann ist der Schnitt zu vorsichtig, und die Lücke wird sich wieder öffnen.
Warum die Zuordnung im Repository liegen muss
Weil sie sich ändert. Eine Zuordnung in einer Tabelle veraltet in dem Moment, in dem ein Modul umbenannt wird. Als Datei neben dem Code, mit Pfadmustern und Review-Historie, bleibt sie aktuell und ist gleichzeitig nachvollziehbar: Man sieht, wann eine Klasse angehoben wurde und mit welcher Begründung.
Häufige Fragen
Wie viele Klassen sind sinnvoll?
Drei. Zwei sind zu grob, um Aufmerksamkeit wirklich umzuverteilen; ab vier beginnen Abgrenzungsdiskussionen, die mehr Zeit kosten als sie sparen. Wichtiger als die Zahl ist, dass jede Klasse eine klare Konsequenz hat.
Was passiert bei einer Änderung, die mehrere Bereiche berührt?
Es gilt die höchste betroffene Klasse. Das ist die einzige Regel, die ohne Diskussion funktioniert — und sie schafft nebenbei einen Anreiz, Änderungen sauber zu schneiden.
Muss die Einstufung automatisch erfolgen?
Sie sollte es. Eine Einstufung über Pfadmuster und berührte Schemata ist nachvollziehbar und nicht manipulierbar. Eine Selbsteinstufung durch die einreichende Person funktioniert im Alltag nicht zuverlässig, sobald Termindruck entsteht.
Was, wenn die Revision mit Klasse C nicht einverstanden ist?
Dann fehlt meist der Nachweis, was in Klasse C geprüft wird. Sobald sichtbar ist, dass dort dieselben Gates laufen und jede Freigabe eine Spur hinterlässt, verschiebt sich die Diskussion von „ungeprüft" zu „anders geprüft" — und die ist führbar.
Rechnen Sie Ihre Review-Lücke aus.
Vierzehn Fragen, fünf Minuten. Ihre Zahlen, kein Login.
AI Engineering Review ansehen →
