code-smells/change-preventers

Files (1)

• SKILL.md

SKILL.md (first lines)

# Skill: Detect and Refactor Change Preventers

## Purpose

This skill enables the agent to identify "Change Preventers" — architectural flaws that hinder software evolution by requiring widespread changes for single functional updates. The agent will apply refactoring techniques to consolidate responsibilities and reduce the ripple effect of code modifications.

## Domain Knowledge: The 3 Change Preventers

1. **Divergent Change:** When you find yourself having to change many unrelated methods inside a single class every time you make a modification (e.g., changing product logic requires changing finding, displaying, and ordering methods).
2. **Shotgun Surgery:** The opposite of Divergent Change. Making a single modification requires many small changes across many different classes.
3. **Parallel Inheritance Hierarchies:** A special case where whenever you create a subclass for one class, you find yourself forced to create a subclass for another class.

## Procedural Instructions

### 1. Detection Phase

- **Monitor Change Patterns:** If one class is constantly modified for different reasons, label it as **Divergent Change**.
- **Identify "Ripples":** If a single logical change (e.g., adding a new tax rule) forces edits across five or more files, label it as **Shotgun Surgery**.
- **Spot Hierarchy Pairs:** Look for class hierarchies that mirror each other (e.g., `Triangle` → `TriangleDrawing`, `Circle` → `CircleDrawing`). This is **Parallel Inheritance**.

### 2. Treatment Phase

- **For Divergent Change:**
  - Use **Extract Class** to split unrelated behaviors into separate components.
  - If classes share behavior, use **Extract Superclass**.
- **For Shotgun Surgery:**
  - Use **Move Method** and **Move Field** to consolidate all related behaviors into a single class.
  - If the original classes become empty, use **Inline Class** to eliminate them.
- **For Parallel Inheritance:**
  - Make instances of one hierarchy refer to instances of the other.
  - Use **Move Method** and **Move Field** to eliminate the redundant hierarchy.

## TypeScript Examples

### Divergent Change

```typescript
// BAD: This class changes for DB reasons, UI reasons, and logic reasons
class ProductManager {
  getProduct(id: string) {
    /* DB Logic */
  }
  renderProductHtml() {
    /* UI Logic */
  }
  calculateDiscount() {
    /* Business Logic */
  }
}

// GOOD: Responsibilities extracted into dedicated classes (SRP)
class ProductRepository {
  getProduct(id: string) {
    /* ... */
  }
}

class ProductPresenter {
  renderHtml(product: Product) {
    /* ... */
  }
}

class DiscountCalculator {
  calculate(product: Product) {
    /* ... */
  }
}
```

### Shotgun Surgery

```typescript
// BAD: A single change to "Account" forces changes in three separate classes
class AccountTransfer {
  execute(amount: number) {
    /* ... */
  }
}
class AccountInterest {
  apply(rate: number) {
    /* ... */
  }
}
class AccountAudit {
  log(action: string) {
    /* ... */
  }
}

// GOOD: Related behaviors consolidated into one class
class Account {
  transfer(amount: number) {
    /* ... */
  }
  applyInterest(rate: number) {
    /* ... */
  }
  logAction(action: string) {
    /* ... */
  }
}
```

## Payoff

- **Reduced Maintenance Cost:** Modifications are localized to a single class or method.
- **Code Organization:** Classes become more cohesive and follow the Single Responsibility Principle.
- **Predictability:** Developers can modify features without fearing unexpected breakages in unrelated parts of the system.

From johnnystefan/test-saas-business, Apache-2.0.

More from johnnystefan/test-saas-business