Skip to content

Wer braucht CodeCharter?

Für welche Teams sich CodeCharter besonders auszahlt.

CodeCharter 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 CodeCharter. 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. CodeCharter 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

Bei Pull Requests von externen Beiträgen ist Konsistenz aufwendig durchzusetzen. Statt jedem Contributor manuell zu erklären, dass Async-Methoden bei euch ein Suffix tragen, lasst ihr die CI das in wenigen Sekunden für euch erledigen.

Wenn ihr unsicher seid

Startet den 7-Tage-Trial. Eine Woche reicht, um an eurer echten Codebasis zu sehen, ob das Werkzeug passt – ohne weitere Kosten als eine Email-Adresse.