CodeGuard

Wer braucht CodeGuard?

Für welche Teams sich CodeGuard besonders auszahlt.

Wer braucht CodeGuard?

CodeGuard zahlt sich an drei klar abgrenzbaren Stellen besonders aus.

Teams ab drei Entwicklern mit gemeinsamem Codebesitz

Sobald zwei oder drei Devs zusammenarbeiten, wird jeder PR zur Verhandlungssache: War das jetzt die Naming-Convention oder nicht? Dürfen Controller direkt auf EF zugreifen? Was war nochmal der Architektur-Entscheid?

Genau dafür ist CodeGuard. Die Regeln stehen in einer Datei, gehören zum Repo und werden beim Build durchgesetzt. Diskussionen in PRs verschieben sich von "ist das jetzt richtig" zu "wollen wir die Regel ändern".

.NET-Teams die Architektur durchsetzen wollen

Layering, Coupling, Dependency-Richtungen. CodeGuard verifiziert diese Eigenschaften kontinuierlich.

@name "Domain layer must not reference Web layer"
@severity error
@category "Architecture"

from t in Types
where t.Namespace.StartsWith("Acme.Domain")
where t.UsedTypes.Any(u => u.Namespace.StartsWith("Acme.Web"))
select t

Open-Source-Maintainer mit Contributors

Wenn fremde PRs reinkommen, ist Konsistenz teuer. Statt jedem Contributor manuell zu erklären, dass Async-Methoden bei euch ein Suffix tragen, lässt du die CI das in wenigen Sekunden für dich erledigen.

Wenn du unsicher bist

Starte den 7-Tage-Trial. Eine Woche reicht, um auf eurer echten Codebasis zu sehen, ob das Tooling trägt, und kostet ausser einer Email-Adresse nichts.