Repository-Metriken

Engineering-Praktiken

Wie inspect.software grundlegende Engineering-Hygiene misst — CI, Tests, Linting, Pre-commit-Hooks und editorconfig. 12% des gesamten Gesundheitsindex.

Methodik v1.13.0Aktualisiert 2026-07-13

Engineering-Praktiken misst grundlegende Engineering-Hygiene: die Infrastruktur, die Änderungen sicher macht. Continuous Integration und eine automatisierte Testsuite sind die beiden Praktiken mit dem am besten dokumentierten Zusammenhang zu nachhaltiger Qualität; zusammen tragen sie den Großteil dieser Metrik.

  • Kategorie: Engineering-Qualität (60% innerhalb der Kategorie)
  • Gewicht im Gesamtindex: 12% — die zweitschwerste Repository-Metrik
  • Metrikschlüssel: engineering_practices

Wie der Wert berechnet wird

Eine gewichtete Checkliste sichtbarer Praxisbelege:

KomponenteGewichtEvidenz
CI-Workflows24Continuous-Integration-Konfiguration vorhanden
Tests vorhanden24eine Testsuite existiert im Repository
Linter-Konfiguration16Lint-/Format-Konfiguration eingecheckt
Pre-commit-Hooks9,6Pre-commit-Konfiguration vorhanden
.editorconfig6,4Editor-Konventionen eingecheckt
OpenSSF Scorecard: CI-Tests20Scorecard-Ergebnis 0–10, skaliert auf 20 Punkte

Warum diese fünf

  • CI plus Tests bilden die Verifikationsschleife: Jede Änderung wird gegen die Suite geprüft, bevor sie landet. Ihr kombiniertes Gewicht von 60 spiegelt wider, dass keine andere sichtbare Praktik sie ersetzt.
  • Linting erzwingt Konsistenz mechanisch und hält die Aufmerksamkeit im Review beim Inhalt.
  • Pre-commit-Hooks und .editorconfig sind kleinere Signale eines Projekts, das in die Ergonomie für Beitragende investiert hat — Änderungen kommen vorgeprüft und einheitlich formatiert an, unabhängig davon, wer sie geschrieben hat.

Dieselbe Evidenz speist die KI-Verifikationsschleife: Die Infrastruktur, mit der ein menschlicher Beitragender eine Änderung verifiziert, ist genau die, mit der ein KI-Coding-Agent sie verifiziert.

Scorecards CI-Tests ist geteilte Evidenz: Anders als die lokalen Vorhandenseinsprüfungen fragt es, ob gemergte Pull Requests von CI geprüft wurden. Es bleibt zugleich eine vollwertige Sicherheitskomponente. n/a oder nicht verfügbare Scorecard-Evidenz wird ausgeschlossen.

Das Ergebnis lesen

  • Dies sind Vorhandenseinssignale — sie bestätigen, dass das Gerüst existiert, nicht, wie rigoros es ist. Coverage-Prozentsätze und CI-Erfolgsraten stehen auf der Methodik-Roadmap.
  • Eine fehlende Testsuite ist eines der verlässlichsten Negativsignale der gesamten Methodik; nur sehr wenige disziplinierte Projekte kommen ohne aus.

Den Wert verbessern

  • Einen CI-Workflow hinzufügen, der die Testsuite bei jedem Push und Pull Request ausführt — die zwei schwersten Komponenten, oft an einem einzigen Nachmittag erreichbar.
  • Die Linter- und Formatter-Konfiguration einchecken, die das Projekt lokal ohnehin verwendet.
  • Für die verbleibenden Punkte eine Pre-commit-Konfiguration und eine .editorconfig ergänzen.

Verwandt: Dokumentation · KI-Verifikationsschleife

Von inspect.software veröffentlichte Ergebnisse sind Signale, keine Garantien — siehe wie sie zu lesen sind. Die vollständige Methodik ist versioniert und öffentlich: Methodik v1.13.0.