M15 Anti Pattern

Identify and remediate M15 architectural anti-patterns through automated analysis

M15 Anti-Pattern is an AI skill that identifies and remedies common software development anti-patterns that degrade code quality, performance, and maintainability. It covers code smell detection, architectural anti-pattern recognition, performance pitfalls, testing anti-patterns, and refactoring strategies that transform problematic patterns into clean, efficient solutions.

What Is This?

Overview

M15 Anti-Pattern provides detection and remediation guidance for the most damaging patterns found in software codebases. It addresses code-level anti-patterns like god classes, shotgun surgery, and feature envy, architectural anti-patterns including distributed monoliths and circular dependencies, performance anti-patterns such as N+1 queries and premature optimization, testing anti-patterns like flaky tests and testing implementation details, dependency anti-patterns including dependency hell and version conflicts, and process anti-patterns like golden hammer and cargo cult programming.

Who Should Use This

This skill serves developers reviewing code for quality improvement opportunities, architects evaluating system designs for structural weaknesses, team leads establishing code quality standards, and engineers refactoring codebases that have accumulated problematic patterns.

Why Use It?

Problems It Solves

Anti-patterns accumulate silently in codebases, increasing the cost of every future change. Developers may not recognize patterns as problematic because they appear to work. God classes and tight coupling make changes risky because modifications in one area break unrelated features. Performance anti-patterns cause scalability issues that only appear under production load.

Core Highlights

The skill identifies anti-patterns with concrete code examples showing both the problem and the solution. Each anti-pattern includes a severity assessment based on its impact on maintainability and performance. Refactoring steps are broken into incremental changes that can be made safely. Detection can be partially automated through static analysis rules.

How to Use It?

Basic Usage

class UserManager:
    def create_user(self, data): pass
    def authenticate(self, credentials): pass
    def send_email(self, user, template): pass
    def generate_report(self, user_ids): pass
    def export_to_csv(self, users): pass
    def validate_address(self, address): pass
    def calculate_subscription(self, user): pass

class UserService:
    def create_user(self, data): pass
    def get_user(self, user_id): pass

class AuthService:
    def authenticate(self, credentials): pass
    def refresh_token(self, token): pass

class NotificationService:
    def send_email(self, recipient, template): pass

class ReportService:
    def generate_report(self, user_ids): pass
    def export_to_csv(self, data): pass

Real-World Examples

def get_orders_with_items_bad(customer_id):
    orders = db.query("SELECT * FROM orders WHERE customer_id = %s", customer_id)
    for order in orders:
        order["items"] = db.query(
            "SELECT * FROM order_items WHERE order_id = %s", order["id"])
    return orders

def get_orders_with_items_good(customer_id):
    return db.query("""
        SELECT o.*, json_agg(oi.*) as items
        FROM orders o
        LEFT JOIN order_items oi ON oi.order_id = o.id
        WHERE o.customer_id = %s
        GROUP BY o.id
    """, customer_id)

class BaseProcessor:
    def validate(self): raise NotImplementedError
    def transform(self): raise NotImplementedError
    def save(self): raise NotImplementedError

class OrderProcessor(BaseProcessor):  # Only implementation
    def validate(self): pass
    def transform(self): pass
    def save(self): pass

class OrderProcessor:
    def process(self, order):
        self.validate(order)
        transformed = self.transform(order)
        self.save(transformed)

Advanced Tips

Create a team anti-pattern catalog documenting patterns specific to your codebase with before/after examples from actual code. Use static analysis custom rules to detect your most common anti-patterns automatically. Track anti-pattern resolution in tech debt sprints to measure progress over time.

When to Use It?

Use Cases

Use M15 Anti-Pattern when reviewing code quality during refactoring sprints, when investigating why a codebase is difficult to modify, when training developers to recognize and avoid common pitfalls, or when establishing code review criteria that include anti-pattern detection.

Related Topics

Code refactoring techniques, design patterns, SOLID principles, static code analysis, and code review practices all complement anti-pattern detection and remediation.

Important Notes

Requirements

Access to the codebase for pattern analysis. Understanding of clean code principles to evaluate alternatives. Static analysis tools for automated detection of common anti-patterns.

Usage Recommendations

Do: refactor anti-patterns incrementally with test coverage to prevent regressions. Document the anti-pattern and its fix in code review comments to educate the team. Prioritize anti-patterns that cause the most maintenance pain based on change frequency data.

Don't: refactor multiple anti-patterns simultaneously in the same pull request. Label every imperfect code pattern as an anti-pattern, as some complexity is genuinely necessary. Introduce new abstractions solely to eliminate an anti-pattern if the abstraction adds more complexity than it removes.

Limitations

Anti-pattern detection is context-dependent, and what is an anti-pattern in one situation may be acceptable in another. Automated detection catches structural anti-patterns but misses design-level issues. Refactoring anti-patterns in production code carries risk and requires adequate test coverage.