Menü
Identify and avoid common anti-patterns in code, architecture, and event-driven systems
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Software architecture patterns including microservices, DDD, cloud-native, API design, security, and performance
Creative, interactive, and delightful application patterns including generative design, gamification, and sensory feedback
Modern Flutter and Dart patterns, production-grade standards, and iOS-optimized practices
Modern frontend patterns, TypeScript best practices, and production-grade standards for Vue.js and Angular
Game design principles, mechanics, architecture patterns, and prototyping workflows
Google Cloud Platform best practices for serverless, event-driven architectures
| name | anti-patterns |
| description | Identify and avoid common anti-patterns in code, architecture, and event-driven systems |
Identify and avoid common anti-patterns in code, architecture, and event-driven systems. Use this skill when reviewing, refactoring, or designing systems to prevent common mistakes.
Problem: One class that knows too much and does too much.
# ❌ Anti-pattern
class ApplicationManager:
def create_user(self): ...
def send_email(self): ...
def process_payment(self): ...
def generate_report(self): ...
def validate_input(self): ...
def connect_database(self): ...
# ✅ Fix: Single Responsibility
class UserService:
def create_user(self): ...
class EmailService:
def send_email(self): ...
class PaymentService:
def process_payment(self): ...
Problem: Using primitives instead of domain types.
# ❌ Anti-pattern
def create_order(customer_id: str, amount: float, currency: str): ...
# ✅ Fix: Value Objects
class CustomerId(BaseModel):
value: UUID
class Money(BaseModel):
amount: Decimal
currency: Currency # StrEnum
def create_order(customer_id: CustomerId, total: Money): ...
Problem: A method that uses data from another class more than its own.
# ❌ Anti-pattern
class InvoiceCalculator:
def calculate_total(self, order: Order) -> float:
total = sum(item.price * item.quantity for item in order.items)
total -= order.discount_amount
total *= (1 + order.tax_rate)
return total
# ✅ Fix: Move method to the class that owns the data
class Order:
def calculate_total(self) -> float:
subtotal = sum(item.total for item in self.items)
return (subtotal - self.discount_amount) * (1 + self.tax_rate)
Problem: A small change requires modifications in many classes.
Fix: Consolidate related behavior. Apply the "Open-Closed Principle" — extend via new code, not by modifying existing code.
# ❌ Anti-pattern
if user.age > 18:
if order.status == "COMPLETED":
discount = amount * 0.15
# ✅ Fix: Named constants
MINIMUM_AGE = 18
LOYALTY_DISCOUNT_RATE = Decimal("0.15")
class OrderStatus(StrEnum):
COMPLETED = "COMPLETED"
PENDING = "PENDING"
Problem: Microservices that must be deployed together, share databases, or have synchronous call chains.
Symptoms:
Fix:
Problem: Multiple services reading/writing the same database.
# ❌ Anti-pattern
Service A ─┐
Service B ──┤──▶ Shared PostgreSQL
Service C ─┘
# ✅ Fix: Database per service + events
Service A ──▶ DB A ──▶ Events ──▶ Service B ──▶ DB B
Problem: No clear architecture, everything depends on everything.
Fix: Introduce bounded contexts, layered architecture, dependency rules.
Problem: Building for imaginary future requirements.
Fix:
Problem: Services making many synchronous calls to each other.
# ❌ Anti-pattern: 5 sync calls for one operation
Order Service → User Service → Inventory Service → Payment Service → Notification Service
# ✅ Fix: Aggregate + async events
Order Service → Order Created Event → [User, Inventory, Payment, Notification] (parallel)
Problem: Using event sourcing for simple CRUD where it adds complexity without benefit.
When to use Event Sourcing:
When NOT to:
Problem: Processing the same event twice causes duplicate effects.
# ❌ Anti-pattern: No idempotency
async def handle_payment(event: PaymentReceived):
await credit_account(event.amount) # Doubles on retry!
# ✅ Fix: Idempotent handler
async def handle_payment(event: PaymentReceived):
if await is_already_processed(event.id):
return
await credit_account(event.amount)
await mark_processed(event.id)
Problem: Failed messages are silently dropped or retry forever.
Fix: Always configure:
Problem: Consumers break when event schema changes.
Fix:
Problem: Assuming events arrive in a specific order.
Fix:
| Anti-Pattern | How to Detect | Action |
|---|---|---|
| God Object | Class > 200 lines, 10+ methods | Split by responsibility |
| Distributed Monolith | Services deployed together | Define boundaries, use events |
| Missing Idempotency | Duplicate processing on retry | Add idempotency key check |
| Shared Database | Multiple services, one DB | Database per service |
| Chatty Services | > 3 sync calls per request | Aggregate, use events |
| Over-Engineering | Unused abstractions | Remove, simplify |
✅ Regular architecture reviews to catch anti-patterns early ✅ Use architecture fitness functions (automated checks) ✅ Code review checklist includes anti-pattern checks ✅ Document why things were done a certain way (ADRs) ✅ Refactor incrementally — don't try to fix everything at once