Fähigkeiten backend-dev-guidelines
📦

backend-dev-guidelines

Sicher

Produktionsreife Node.js-Backends mit Best Practices entwickeln

Auch verfügbar von: BrianDai22,diet103,Dimon94,DojoCodingLabs

Hören Sie auf, Backend-Architektur zu raten. Erhalten Sie umfassende Richtlinien für geschichtete Node.js-Dienste mit Express, TypeScript, Prisma-Repositories und Zod-Validierung, die zuverlässig skalieren.

Unterstützt: Claude Codex Code(CC)
📊 71 Angemessen
1

Die Skill-ZIP herunterladen

2

In Claude hochladen

Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen

3

Einschalten und loslegen

Teste es

Verwendung von "backend-dev-guidelines". Create a user registration endpoint

Erwartetes Ergebnis:

  • Generiertes Zod-Validierungsschema für Benutzereingaben
  • Erstellter UserController, der BaseController mit createUser-Methode erweitert
  • Implementierter UserService mit Geschäftslogik und Dependency Injection
  • Erstelltes UserRepository mit Prisma-Abfragen
  • Hinzugefügte Route-Registrierung mit asyncErrorWrapper
  • Inkludiertes Sentry-Fehlertracking und BFRI-Bewertung

Verwendung von "backend-dev-guidelines". Refactor inline database queries in routes

Erwartetes Ergebnis:

  • Extrahierte Geschäftslogik aus Routes in neuen UserService
  • Erstelltes UserRepository zur Kapselung von Prisma-Operationen
  • Aktualisierter UserController zur Orchestrierung von Service-Aufrufen
  • Hinzugefügte korrekte Fehlergrenzen mit BaseController
  • Geschriebene Unit-Tests für Service-Layer
  • BFRI verbessert von -2 (gefährlich) auf 8 (sicher)

Sicherheitsaudit

Sicher
v1 • 2/25/2026

Static analysis flagged 544 patterns across 12 markdown documentation files (5337 lines). All findings are FALSE POSITIVES - the detected patterns exist in markdown code examples and documentation, not executable code. This skill provides secure backend development guidelines that explicitly teach against risky patterns like direct process.env usage. Safe for publication.

12
Gescannte Dateien
5,337
Analysierte Zeilen
0
befunde
1
Gesamtzahl Audits
Keine Sicherheitsprobleme gefunden
Auditiert von: claude

Qualitätsbewertung

38
Architektur
100
Wartbarkeit
87
Inhalt
31
Community
100
Sicherheit
91
Spezifikationskonformität

Was du bauen kannst

Neuentwicklung von Microservices

Generieren Sie einen vollständigen Backend-Microservice von Grund auf nach produktionsreifen Mustern mit korrekter Schichtung, Validierung und Fehlerbehandlung.

Refactoring von Legacy-Code

Refaktorisieren Sie monolithische Route-Handler in eine korrekte geschichtete Architektur mit Controllern, Services und Repositories für verbesserte Wartbarkeit.

Team-Onboarding und Standards

Etablieren Sie einheitliche Backend-Entwicklungsstandards über Teams hinweg mit klaren Mustern für Architektur, Testing und Fehlerbehandlung.

Probiere diese Prompts

Neuen Controller erstellen
Erstellen Sie einen UserController nach dem BaseController-Muster mit Methoden für getUser, listUsers, createUser und updateUser. Integrieren Sie korrekte Fehlerbehandlung mit Sentry.
Service-Layer mit DI implementieren
Erstellen Sie einen UserService, der UserRepository über Dependency Injection erhält. Fügen Sie Methoden für findById, getAll, create, update und delete mit korrekter Geschäftslogik-Trennung hinzu.
Vollständiges Feature mit Validierung erstellen
Implementieren Sie ein vollständiges Benutzerregistrierungsfeature mit Zod-Validierungsschema, Controller, der BaseController erweitert, Service mit Geschäftslogik und Repository mit Prisma. Inklusive BFRI-Bewertung für die Implementierung.
Legacy-Code in geschichtete Architektur refaktorisieren
Refaktorisieren Sie diesen monolithischen Route-Handler in eine korrekte geschichtete Architektur. Identifizieren Sie Routes, Controller, Services und Repositories. Fügen Sie korrekte Fehlerbehandlung, Validierung und Sentry-Tracking hinzu. Berechnen Sie BFRI vorher und nachher.

Bewährte Verfahren

  • Verwenden Sie immer geschichtete Architektur: Routes delegieren an Controller, Controller rufen Services auf, Services nutzen Repositories
  • Verwenden Sie process.env niemals direkt - greifen Sie über unifiedConfig auf Konfiguration zu für Typsicherheit und Testbarkeit
  • Validieren Sie alle externen Eingaben mit Zod-Schemas vor der Verarbeitung - Request-Bodies, Query-Parameter und Route-Parameter

Vermeiden

  • Geschäftslogik in Route-Handlern - Routes sollten nur an Controller delegieren
  • Direkte Prisma-Nutzung in Controllern - immer durch Repositories abstrahieren
  • console.log für Fehler verwenden - alle Fehler müssen in Sentry erfasst werden

Häufig gestellte Fragen

Warum geschichtete Architektur statt Logik in Routes zu platzieren?
Geschichtete Architektur ermöglicht Testbarkeit, Wiederverwendbarkeit und Wartbarkeit. Services können unabhängig getestet werden, über Routes/Cron-Jobs/Scripts wiederverwendet werden, und Bugs sind leichter in isolierten Schichten zu lokalisieren.
Was ist BFRI und wie berechne ich es?
BFRI (Backend Feasibility Risk Index) = (Architektonische Passform + Testbarkeit) - (Komplexität + Datenrisiko + Betriebsrisiko). Punktzahl reicht von -10 bis +10. Werte über 3 sind sicher fortzufahren; unter 0 erfordern Neugestaltung.
Warum kann ich process.env nicht direkt in meinem Code verwenden?
Direkte process.env-Nutzung bietet keine Typsicherheit, Validierung und erschwert Tests. unifiedConfig bietet typisierten Zugriff mit Standardwerten, validiert beim Start und ermöglicht einfaches Mocking in Tests.
Muss ich BaseController für alle Controller erweitern?
Ja. BaseController bietet konsistente Fehlerbehandlung über handleError, Erfolgsantworten über handleSuccess, Sentry-Integration und Request-Tracking. Dies garantiert einheitliches Verhalten über alle Endpunkte.
Wann sollte ich Transaktionen in meinen Services verwenden?
Verwenden Sie Transaktionen, wenn mehrere Datenbankoperationen gemeinsam erfolgreich sein oder fehlen müssen. Wickeln Sie verwandte Operationen in this.withTransaction() ein, um Atomarität und korrektes Rollback bei Fehlern zu gewährleisten.
Wie teste ich Services, die Dependency Injection verwenden?
Injizieren Sie Mock-Repositories über den Service-Konstruktor in Tests. Dies ermöglicht das Testen von Geschäftslogik isoliert ohne Datenbankzugriff. Jest-Mocks oder manuelle Mock-Klassen funktionieren gut für dieses Muster.