القائمة
Identify and avoid common anti-patterns in code, architecture, and event-driven systems
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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