Code Refactoring Prompt Templates

## Code Smells Identified

### 1. Long Method (Critical)
**The smell:** `processCheckout()` is 200 lines handling validation, inventory, payment, shipping, and email.

**Why it's a problem:** Impossible to test individual behaviors, hard to understand, changes risk breaking unrelated features.

**Refactoring: Extract Method**
```javascript
// Before: one massive function
async function processCheckout(order) {
 // 200 lines of mixed concerns...
}

// After: composed of focused functions
async function processCheckout(order) {
 const validatedOrder = await validateOrder(order);
 await reserveInventory(validatedOrder);
 const payment = await processPayment(validatedOrder);
 const shipment = await createShipment(validatedOrder);
 await sendConfirmationEmail(validatedOrder, payment, shipment);
 return { order: validatedOrder, payment, shipment };
}
```

### 2. Feature Envy (High)
**The smell:** Lines 45-78 are all manipulating `order.customer` properties.

**Refactoring: Move Method**
```javascript
// Before: checkout function knows too much about Customer
const fullName = order.customer.firstName + ' ' + order.customer.lastName;
const address = formatAddress(order.customer.address);

// After: Customer handles its own formatting
const fullName = order.customer.getFullName();
const address = order.customer.getFormattedAddress();
```

### Priority Order
1. Extract Method (enables testing)
2. Move Method for Customer logic
3. Extract shipping calculation to strategy pattern (you mentioned adding new carriers)

```python
# BEFORE: Deeply nested conditionals
def process_order(order):
 if order:
 if order.items:
 if order.customer:
 if order.customer.active:
 if order.payment_method:
 # actual logic buried 5 levels deep
...

# AFTER: Guard clauses flatten the structure
def process_order(order):
 # Early returns for invalid states (guard clauses)
 if not order:
 raise ValueError("Order is required")
 if not order.items:
 raise ValueError("Order must have items")
 if not order.customer:
 raise ValueError("Order must have a customer")
 if not order.customer.active:
 raise InactiveCustomerError(order.customer.id)
 if not order.payment_method:
 raise ValueError("Payment method is required")
 
 # Main logic at the top level, easy to read
 return self._execute_order(order)

def _execute_order(self, order):
 """Handles the actual order processing. Extracted for testability."""
 validated = self._validate_inventory(order)
 charged = self._charge_payment(validated)
 return self._create_shipment(charged)
```

**Changes made:**
1. Replaced nested ifs with guard clauses (early returns)
2. Extracted core logic to `_execute_order()` for easier testing
3. Each step is now a separate method that can be tested/mocked independently

## Recommended Pattern: Strategy + Factory

**Why it fits:** You have multiple algorithms (report generators) that need to be selected at runtime, and you want teams to add new ones without modifying central code.

### Before: Switch Statement
```typescript
function generateReport(type: string, data: ReportData): Report {
 switch (type) {
 case 'sales':
 return generateSalesReport(data);
 case 'inventory':
 return generateInventoryReport(data);
 case 'financial':
 // 10 more cases...
 }
}
```

### After: Strategy Pattern
```typescript
// 1. Define the strategy interface
interface ReportGenerator {
 type: string;
 generate(data: ReportData): Report;
}

// 2. Each team implements their own generator
class SalesReportGenerator implements ReportGenerator {
 type = 'sales';
 generate(data: ReportData): Report {
 // Sales team owns this implementation
 }
}

// 3. Registry allows adding generators without modifying core code
class ReportRegistry {
 private generators = new Map<string, ReportGenerator>();

 register(generator: ReportGenerator) {
 this.generators.set(generator.type, generator);
 }

 generate(type: string, data: ReportData): Report {
 const generator = this.generators.get(type);
 if (!generator) throw new Error(`Unknown report type: ${type}`);
 return generator.generate(data);
 }
}

// 4. Registration (can be in separate files per team)
const registry = new ReportRegistry();
registry.register(new SalesReportGenerator());
registry.register(new InventoryReportGenerator());
```

### Tradeoffs
**Use this when:** You have 5+ variants, different teams/people own different variants, or variants change frequently.

**Don't use when:** You have 2-3 simple variants that rarely change, a switch statement is fine and simpler.

## Incremental Refactoring Plan

### Phase 1: Stabilize (Week 1-2)
**Goal:** Establish safety net before making changes

**Step 1.1:** Add characterization tests
- Write tests that capture current behavior (even if messy)
- Target: Cover the 10 most critical code paths
- Deliverable: 50% coverage on OrderService

**Step 1.2:** Add integration test for main flows
- End-to-end test: create order → payment → fulfillment
- This catches breaks that unit tests miss

### Phase 2: Extract Vertical Slices (Week 3-6)
**Goal:** Pull out self-contained functionality

**Step 2.1:** Extract PaymentProcessor
- Lines 450-680 all handle payment logic
- Create PaymentProcessor class
- OrderService delegates to it (no behavior change)
- Add focused tests for PaymentProcessor
- Deploy, monitor for 1 week

**Step 2.2:** Extract InventoryManager
- Lines 800-950 handle inventory
- Same pattern: extract, delegate, test, deploy

**Step 2.3:** Extract ShippingService
- Lines 1100-1400

### Phase 3: Clean Core (Week 7-8)
**Goal:** Simplify remaining OrderService

**Step 3.1:** Replace direct database calls with repository
**Step 3.2:** Remove dead code (now safe with test coverage)
**Step 3.3:** Simplify public API methods

### Rollback Strategy
Each extracted service:
1. Lives behind a feature flag initially
2. Old code path preserved for 2 weeks
3. Flag enables gradual rollout (10% → 50% → 100%)

### Success Metrics
- [ ] Test coverage: 30% → 80%
- [ ] OrderService lines: 2000 → <500
- [ ] Zero production incidents during refactor