DRY Standardized Process: From Identification to Refactoring

This skill guides you to systematically apply the DRY (Don't Repeat Yourself) principle to eliminate code duplication and improve code quality and maintainability through a 4-step standardized process.

When to Use This Skill

Use this skill when users request to:

Eliminate code duplication or redundancy
Refactor code with obvious copy-paste traces
Optimize codebase by applying the DRY principle
Identify and fix "code smells" (such as magic numbers, repeated logic)
Extract common logic into reusable units
Improve code maintainability

Key Trigger Words: DRY, duplicate code, code repetition, refactoring, eliminate duplication, copy-paste, magic numbers, code smells, abstraction, extract function

Core Idea

Every piece of knowledge in a system must have a single, unambiguous, authoritative representation.

This means:

Any business logic, algorithm, or configuration information should exist in only one place in the codebase
When modifications are needed, you only need to change this one place
The changes will be automatically reflected in all places using this logic

Rule of Two: When you write almost the same code block for the second time, an alarm should go off. This is a signal to start refactoring.

4-Step Standardized Process

This is a micro-cycle that can be applied at any stage of coding. Follow the steps strictly to ensure the safety and effectiveness of refactoring.

Step 1: Identify Repetition

Goal: Act like a detective, stay alert to "code smells" in the code, and find all repetitions.

1.1 Obvious Repetition

Direct Copy-Paste:

Two or more code blocks are almost identical
Only variable names or a few values are different
This is the most obvious type of repetition that needs to be eliminated

Example:

javascript

// 重复 1
function calculateOrderDiscount(orderTotal) {
  if (orderTotal > 100) {
    return orderTotal * 0.1;
  }
  return 0;
}

// 重复 2
function calculateCouponDiscount(couponTotal) {
  if (couponTotal > 100) {
    return couponTotal * 0.1;
  }
  return 0;
}

"Magic Numbers" or Strings:

The same configuration value or string appears in multiple places as literals
For example:
```
0.08
```
,
```
"http://api.example.com"
```
,
```
100
```

Example:

python

# 魔术数字重复
def calculate_tax_1(amount):
    return amount * 0.08  # ❌ 魔术数字

def calculate_tax_2(amount):
    return amount * 0.08  # ❌ 再次出现

def calculate_total(amount):
    tax = amount * 0.08   # ❌ 第三次
    return amount + tax

1.2 Semantic Repetition

Structural Repetition:

Code structures are similar, but specific variable names or values are different
Multiple if-else structures perform similar conditional judgments and assignments

Example:

typescript

// 结构性重复
function processUserData(user: User) {
  if (user.age >= 18) {
    user.status = 'adult';
  } else {
    user.status = 'minor';
  }
}

function processProductData(product: Product) {
  if (product.price >= 100) {
    product.category = 'premium';
  } else {
    product.category = 'standard';
  }
}

Logical Repetition:

Two different functions look different in code
But they achieve the same goal at the business logic level

Example:

javascript

// 逻辑重复：都在计算折扣，只是来源不同
function applyMembershipDiscount(price, memberLevel) {
  const discountRates = { gold: 0.2, silver: 0.1, bronze: 0.05 };
  return price * (1 - (discountRates[memberLevel] || 0));
}

function applySeasonalDiscount(price, season) {
  const discountRates = { winter: 0.2, spring: 0.1, summer: 0.05 };
  return price * (1 - (discountRates[season] || 0));
}

Identification Checklist

When reviewing code, check for the following signals:

Copy-pasted code blocks (identical or highly similar)
Same numbers or strings appearing in multiple places
Similar if-else or switch-case structures
Functions with similar functions but different names
Same algorithm reimplemented in different places
Same validation logic scattered in multiple places

💡 Action: Use search functions to find repeated literals and similar function name patterns. Record all locations where repetitions occur.

Step 2: Abstract the Logic

Goal: Extract repeated logic and encapsulate it into an independent, reusable unit.

2.1 Identify Variable and Invariant Parts

Invariant Parts:

This is the core repeated logic
Code that remains unchanged during each repetition
This will become the main body of your abstraction

Variable Parts:

Things that change during each repetition
Different values, variable names, configurations
These will become the parameters of functions or classes

Analysis Example:

javascript

// 原始重复代码
const userEmail = validateEmail(user.email);
const adminEmail = validateEmail(admin.email);
const supportEmail = validateEmail(support.email);

// 分析：
// 不变部分：validateEmail() 调用
// 可变部分：不同的 email 值

2.2 Choose the Right Abstraction Form

Choose the most appropriate abstraction method based on the characteristics of the repetition:

Abstraction Form	Applicable Scenarios	Example
Function	Encapsulate an algorithm or behavior	Calculate discounts, validate inputs, format data
Class	Encapsulate behavior + associated state	User manager, data processor, configuration manager
Module/Component	A set of related functions, classes, and configurations	Authentication module, logging module, API client
Configuration File/Constant	Repeated magic numbers or strings	API endpoints, tax rates, thresholds
Higher-Order Function	Repeated control flows or patterns	Retry logic, caching wrapper, error handling

2.3 Design the Abstraction Interface

Function Abstraction Example:

python

# ❌ 重复代码
def process_user_order(user_id, order_data):
    user = db.query(User).filter_by(id=user_id).first()
    if not user:
        raise ValueError("User not found")
    # 处理订单...

def process_user_payment(user_id, payment_data):
    user = db.query(User).filter_by(id=user_id).first()
    if not user:
        raise ValueError("User not found")
    # 处理支付...

# ✅ 抽象后
def get_user_or_error(user_id):
    """不变部分：获取用户并验证"""
    user = db.query(User).filter_by(id=user_id).first()
    if not user:
        raise ValueError("User not found")
    return user

def process_user_order(user_id, order_data):
    user = get_user_or_error(user_id)  # 可变部分：user_id
    # 处理订单...

def process_user_payment(user_id, payment_data):
    user = get_user_or_error(user_id)  # 可变部分：user_id
    # 处理支付...

Constant Abstraction Example:

javascript

// ❌ 魔术数字
function calculateTax(amount) {
  return amount * 0.08;
}

function displayTaxInfo(amount) {
  console.log(`Tax (8%): $${amount * 0.08}`);
}

// ✅ 抽象为常量
const TAX_RATE = 0.08;

function calculateTax(amount) {
  return amount * TAX_RATE;
}

function displayTaxInfo(amount) {
  console.log(`Tax (${TAX_RATE * 100}%): $${amount * TAX_RATE}`);
}

Class Abstraction Example:

typescript

// ❌ 重复的状态和行为
const userCache = new Map();
function getUserFromCache(id: string) { /*...*/ }
function setUserInCache(id: string, user: User) { /*...*/ }

const productCache = new Map();
function getProductFromCache(id: string) { /*...*/ }
function setProductInCache(id: string, product: Product) { /*...*/ }

// ✅ 抽象为类
class Cache<T> {
  private store = new Map<string, T>();

  get(id: string): T | undefined {
    return this.store.get(id);
  }

  set(id: string, value: T): void {
    this.store.set(id, value);
  }
}

const userCache = new Cache<User>();
const productCache = new Cache<Product>();

Abstraction Design Principles

Do:

✅ Parameterize variable parts (values, configurations, behaviors)
✅ Keep interfaces simple (number of parameters ≤ 4)
✅ Use descriptive names (explain "what it does" instead of "how it does it")
✅ Consider future extensibility (but don't over-design)

Don't:

❌ Create overly general abstractions ("one-size-fits-all functions")
❌ Abstract prematurely (don't abstract if it's only used once)
❌ Ignore performance impacts (e.g., unnecessary function call overhead)
❌ Use hard-to-understand abstractions (increase cognitive load)

💡 Action: Create a new function, class, or configuration file, put the "invariant parts" into it, and define the "variable parts" as parameters.

Step 3: Replace the Implementation

Goal: Replace all old repetitive code with the new abstraction unit.

3.1 Systematic Replacement

Steps:

Locate all repetition points: Go back to all locations recorded in Step 1
Replace one by one: Delete old code and call the new abstraction
Pass correct parameters: Ensure parameters are correctly mapped
Maintain consistent behavior: Ensure functions are exactly the same before and after replacement

Replacement Example:

Before (Duplicate Code):

python

# 位置 1: user_service.py
def create_user(data):
    if not data.get('email'):
        return {'error': 'Email is required'}, 400
    if not data.get('password'):
        return {'error': 'Password is required'}, 400
    # 创建用户...

# 位置 2: product_service.py
def create_product(data):
    if not data.get('name'):
        return {'error': 'Name is required'}, 400
    if not data.get('price'):
        return {'error': 'Price is required'}, 400
    # 创建产品...

After (Using Abstraction):

python

# 新抽象: validation_utils.py
def validate_required_fields(data, required_fields):
    """验证必填字段"""
    for field in required_fields:
        if not data.get(field):
            return {'error': f'{field.capitalize()} is required'}, 400
    return None

# 位置 1: user_service.py (已替换)
def create_user(data):
    error = validate_required_fields(data, ['email', 'password'])
    if error:
        return error
    # 创建用户...

# 位置 2: product_service.py (已替换)
def create_product(data):
    error = validate_required_fields(data, ['name', 'price'])
    if error:
        return error
    # 创建产品...

3.2 Handle Edge Cases

Sometimes there are subtle differences between duplicate code that require special handling:

Strategy 1: Add Optional Parameters

javascript

// 大部分重复，但有一个地方需要额外日志
function processData(data, options = {}) {
  // 通用处理...

  if (options.enableLogging) {
    console.log('Processing:', data);
  }

  return result;
}

// 使用
processData(data1);  // 无日志
processData(data2, { enableLogging: true });  // 有日志

Strategy 2: Callback Functions

typescript

// 核心流程相同，但中间步骤不同
function processWithCustomStep<T>(
  data: T,
  customStep: (item: T) => T
): T {
  // 前置处理
  const prepared = prepare(data);

  // 可变的自定义步骤
  const processed = customStep(prepared);

  // 后置处理
  return finalize(processed);
}

// 使用
processWithCustomStep(userData, (user) => validateUser(user));
processWithCustomStep(productData, (product) => enrichProduct(product));

Strategy 3: Keep Special Cases

python

# 如果某个重复有本质上的不同，考虑保留它
def process_standard_order(order):
    return apply_dry_abstraction(order, 'standard')

def process_vip_order(order):
    # VIP 订单有完全不同的业务逻辑，不强行抽象
    # 保留独立实现
    pass

Replacement Checklist

Confirm all repetition points have been replaced (don't miss any)
Delete old duplicate code (avoid mixing old and new methods)
Check import statements and dependencies
Ensure parameter order and types are correct
Handled all edge cases

⚠️ Warning: If you only replace part of the code, you create another type of inconsistency, which may make the situation worse. Ensure all are replaced or none are replaced.

💡 Action: Use the IDE's "Find All References" feature to ensure no repetition points are missed.

Step 4: Verify and Test

Goal: Ensure refactoring does not break any functionality, and the program behavior is exactly the same before and after refactoring.

4.1 Unit Testing

Write independent unit tests for your newly created abstraction:

Test Coverage Points:

✅ Correct output for normal inputs
✅ Boundary value tests (empty values, maximum values, minimum values)
✅ Error handling for abnormal inputs
✅ Behavior of different parameter combinations

Example:

python

# 抽象函数
def calculate_discount(price, discount_rate):
    """计算折扣后价格"""
    if not 0 <= discount_rate <= 1:
        raise ValueError("Discount rate must be between 0 and 1")
    return price * (1 - discount_rate)

# 单元测试
def test_calculate_discount():
    # 正常情况
    assert calculate_discount(100, 0.1) == 90
    assert calculate_discount(100, 0) == 100

    # 边界情况
    assert calculate_discount(0, 0.5) == 0
    assert calculate_discount(100, 1) == 0

    # 异常情况
    with pytest.raises(ValueError):
        calculate_discount(100, 1.5)
    with pytest.raises(ValueError):
        calculate_discount(100, -0.1)

4.2 Integration Testing

Run integration tests that cover the modified code areas:

bash

# 运行特定模块的测试
pytest tests/test_user_service.py
pytest tests/test_product_service.py

# 或运行整个测试套件
npm test
pytest

Checklist:

All tests pass
No new failures or errors
Performance has not significantly degraded
Coverage has not decreased

4.3 Manual Verification

If there are no automated tests (or test coverage is insufficient), perform manual verification:

Verification Checklist:

Start the application and check if it runs normally
Test the modified functionality (via UI or API)
Check if log output is normal
Test error scenarios (invalid inputs, boundary conditions)
Test in different environments (development, testing, pre-release)

4.4 Performance Verification

Ensure abstraction does not introduce performance issues:

python

import time

# 性能测试
def benchmark_function(func, *args, iterations=1000):
    start = time.time()
    for _ in range(iterations):
        func(*args)
    end = time.time()
    return (end - start) / iterations

# 对比重构前后
old_time = benchmark_function(old_implementation, test_data)
new_time = benchmark_function(new_implementation, test_data)

print(f"Old: {old_time:.6f}s, New: {new_time:.6f}s")
print(f"Difference: {((new_time - old_time) / old_time * 100):.2f}%")

4.5 Code Review

If working in a team, conduct code review:

Review Points:

Is the abstraction reasonable and easy to understand?
Are names clear and consistent with conventions?
Are there any missed repetition points?
Is it over-abstracted or overly complex?
Are documentation and comments sufficient?

💡 Action: Run all relevant tests to ensure the external behavior of the program is exactly the same before and after refactoring. No tests? Now is the best time to write them.

Complete Example: From Start to Finish

Scenario: Discount Calculation in E-Commerce System

Original Code (With Duplication)

javascript

// order_service.js
function calculateOrderTotal(order) {
  let total = 0;
  for (const item of order.items) {
    total += item.price * item.quantity;
  }

  // 会员折扣
  if (order.memberLevel === 'gold') {
    total = total * 0.8;  // ❌ 魔术数字
  } else if (order.memberLevel === 'silver') {
    total = total * 0.9;  // ❌ 魔术数字
  }

  return total;
}

// cart_service.js
function calculateCartTotal(cart) {
  let total = 0;
  for (const item of cart.items) {
    total += item.price * item.quantity;  // ❌ 重复计算逻辑
  }

  // 优惠券折扣
  if (cart.couponType === 'premium') {
    total = total * 0.8;  // ❌ 重复的折扣计算
  } else if (cart.couponType === 'standard') {
    total = total * 0.9;  // ❌ 重复的折扣计算
  }

  return total;
}

Step 1: Identify Repetition

Identified Repetitions:

Loop logic for calculating total item price (structural repetition)
Discount calculation logic (logical repetition)
Magic numbers
```
0.8
```
and
```
0.9
```
(obvious repetition)

Step 2: Abstract the Logic

javascript

// pricing_utils.js (新建)

// 抽象 1：商品总价计算
function calculateItemsTotal(items) {
  return items.reduce((total, item) => {
    return total + (item.price * item.quantity);
  }, 0);
}

// 抽象 2：折扣配置（消除魔术数字）
const DISCOUNT_RATES = {
  membership: {
    gold: 0.2,    // 20% off
    silver: 0.1,  // 10% off
    bronze: 0.05  // 5% off
  },
  coupon: {
    premium: 0.2,   // 20% off
    standard: 0.1,  // 10% off
    basic: 0.05     // 5% off
  }
};

// 抽象 3：应用折扣
function applyDiscount(amount, discountRate) {
  if (discountRate < 0 || discountRate > 1) {
    throw new Error('Invalid discount rate');
  }
  return amount * (1 - discountRate);
}

// 抽象 4：获取折扣率
function getDiscountRate(category, level) {
  return DISCOUNT_RATES[category]?.[level] || 0;
}

export { calculateItemsTotal, applyDiscount, getDiscountRate };

Step 3: Replace the Implementation

javascript

// order_service.js (重构后)
import { calculateItemsTotal, applyDiscount, getDiscountRate } from './pricing_utils.js';

function calculateOrderTotal(order) {
  const subtotal = calculateItemsTotal(order.items);
  const discountRate = getDiscountRate('membership', order.memberLevel);
  return applyDiscount(subtotal, discountRate);
}

// cart_service.js (重构后)
import { calculateItemsTotal, applyDiscount, getDiscountRate } from './pricing_utils.js';

function calculateCartTotal(cart) {
  const subtotal = calculateItemsTotal(cart.items);
  const discountRate = getDiscountRate('coupon', cart.couponType);
  return applyDiscount(subtotal, discountRate);
}

Step 4: Verify and Test

javascript

// pricing_utils.test.js
import { calculateItemsTotal, applyDiscount, getDiscountRate } from './pricing_utils.js';

describe('Pricing Utils', () => {
  describe('calculateItemsTotal', () => {
    it('should calculate total for multiple items', () => {
      const items = [
        { price: 10, quantity: 2 },
        { price: 5, quantity: 3 }
      ];
      expect(calculateItemsTotal(items)).toBe(35);
    });

    it('should return 0 for empty items', () => {
      expect(calculateItemsTotal([])).toBe(0);
    });
  });

  describe('applyDiscount', () => {
    it('should apply 20% discount correctly', () => {
      expect(applyDiscount(100, 0.2)).toBe(80);
    });

    it('should throw error for invalid discount rate', () => {
      expect(() => applyDiscount(100, 1.5)).toThrow('Invalid discount rate');
    });
  });

  describe('getDiscountRate', () => {
    it('should return correct membership discount', () => {
      expect(getDiscountRate('membership', 'gold')).toBe(0.2);
    });

    it('should return 0 for unknown level', () => {
      expect(getDiscountRate('membership', 'unknown')).toBe(0);
    });
  });
});

// 运行测试
// npm test pricing_utils.test.js

Refactoring Results:

✅ Eliminated all duplicate code
✅ Magic numbers are centrally managed
✅ Each function has a single responsibility
✅ Easy to test and maintain
✅ If new membership levels or discount types need to be added, only modify
```
DISCOUNT_RATES
```

Common Pitfalls and Solutions

Pitfall 1: Over-Abstraction

Symptoms: Created overly general, hard-to-understand abstractions.

Example:

javascript

// ❌ 过度抽象
function universalProcessor(data, options, callbacks, config, meta) {
  // 100 行通用处理逻辑...
}

// ✅ 合理抽象
function processUserData(user) {
  return validate(user) && transform(user);
}

Solutions:

Only abstract when there is clear repetition
Keep abstractions simple and clear
If there are more than 4 parameters, consider redesigning

Pitfall 2: Incomplete Replacement

Symptoms: Only replaced part of the repetition points, leaving some old code.

Consequences:

Both old and new implementations exist in the codebase
Easy to miss during future modifications
Causes new inconsistencies

Solutions:

Use global search to ensure all repetitions are found
Complete all replacements at once
Use linters or static analysis tools to detect unused code

Pitfall 3: Ignoring Performance Impacts

Symptoms: Abstraction introduces unnecessary performance overhead.

Example:

python

# ❌ 每次调用都重新编译正则表达式
def validate_email(email):
    return re.match(r'^[\w\.-]+@[\w\.-]+\.\w+$', email)

# ✅ 复用编译后的正则表达式
EMAIL_PATTERN = re.compile(r'^[\w\.-]+@[\w\.-]+\.\w+$')

def validate_email(email):
    return EMAIL_PATTERN.match(email)

Solutions:

Benchmark performance-sensitive code
Use optimization techniques like caching and memoization
Use performance analysis tools when necessary

Pitfall 4: Breaking Encapsulation

Symptoms: Abstraction exposes too many internal implementation details.

Example:

typescript

// ❌ 暴露内部状态
class UserManager {
  public users: Map<string, User>;  // 直接暴露内部数据结构

  getUser(id: string) {
    return this.users.get(id);
  }
}

// ✅ 隐藏内部实现
class UserManager {
  private users: Map<string, User>;

  getUser(id: string): User | undefined {
    return this.users.get(id);
  }

  addUser(user: User): void {
    this.users.set(user.id, user);
  }
}

Solutions:

Use access control (private, protected)
Provide clear public interfaces
Hide implementation details

Best Practices

1. Incremental Refactoring

Don't try to refactor the entire codebase at once:

Strategies:

✅ Refactor one small repetitive area at a time
✅ Test immediately after refactoring
✅ Commit small, atomic changes
✅ Gradually expand the refactoring scope

Example Workflow:

bash

# 1. 创建特性分支
git checkout -b refactor/dry-pricing-logic

# 2. 重构一个模块
# 编辑 pricing_utils.js

# 3. 测试
npm test

# 4. 提交
git add pricing_utils.js
git commit -m "Extract pricing calculation to reusable utility"

# 5. 重构使用该模块的文件
# 编辑 order_service.js

# 6. 再次测试和提交
npm test
git add order_service.js
git commit -m "Refactor order service to use pricing utility"

# 7. 继续其他模块...

2. Document Your Abstractions

Good abstractions require good documentation:

typescript

/**
 * Calculates the discounted price of a product
 *
 * @param price - Original price (must be >= 0)
 * @param discountRate - Discount rate (between 0 and 1, 0.2 means 20% off)
 * @returns Discounted price
 * @throws {Error} If discountRate is not within the valid range
 *
 * @example
 * applyDiscount(100, 0.2) // Returns 80
 * applyDiscount(50, 0) // Returns 50 (no discount)
 */
function applyDiscount(price: number, discountRate: number): number {
  if (discountRate < 0 || discountRate > 1) {
    throw new Error(`Invalid discount rate: ${discountRate}. Must be between 0 and 1.`);
  }
  return price * (1 - discountRate);
}

3. Use Type Systems

Leverage type systems to prevent misuse:

typescript

// 使用类型别名增强可读性
type DiscountRate = number; // Between 0 and 1
type Price = number;        // >= 0

// Better: Use branded types to ensure type safety
type DiscountRate = number & { __brand: 'DiscountRate' };

function createDiscountRate(value: number): DiscountRate {
  if (value < 0 || value > 1) {
    throw new Error('Discount rate must be between 0 and 1');
  }
  return value as DiscountRate;
}

function applyDiscount(price: Price, discountRate: DiscountRate): Price {
  return (price * (1 - discountRate)) as Price;
}

// 使用
const rate = createDiscountRate(0.2); // Type check passes
applyDiscount(100, rate);

// applyDiscount(100, 0.2); // ❌ Type error! Must use createDiscountRate

4. Write Tests Before Refactoring

If there are no tests, write tests first before refactoring:

javascript

// Step 1: Write tests for existing (duplicate) code
describe('Original Implementation', () => {
  it('should calculate order total correctly', () => {
    const order = {
      items: [{ price: 10, quantity: 2 }],
      memberLevel: 'gold'
    };
    expect(calculateOrderTotal(order)).toBe(16); // 20 * 0.8
  });
});

// Step 2: Refactor the code

// Step 3: Ensure tests still pass
// npm test

Checklist

After completing DRY refactoring, verify the following:

Identification Phase

Found all obvious code repetitions
Identified magic numbers and hard-coded strings
Discovered structural and logical repetitions
Recorded all locations where repetitions occur

Abstraction Phase

Clearly distinguished between variable and invariant parts
Chose the appropriate abstraction form (function/class/configuration)
Abstractions have clear, descriptive names
Number of parameters is reasonable (≤ 4)
No over-abstraction

Replacement Phase

All repetition points have been replaced
No old code left
Imports and dependencies are correct
All edge cases are handled

Verification Phase

Written unit tests
All existing tests still pass
Performed manual verification (if applicable)
Performance has not significantly degraded
Code review completed (if working in a team)

Overall Quality

Code is more readable and maintainable
Single Responsibility Principle is followed
Modifications only need to be made in one place
Sufficient documentation and comments

Summary

The DRY principle is one of the cornerstones of software engineering. By systematically applying this 4-step process, you can:

Identify Repetition: Cultivate sensitivity to code smells
Abstract Logic: Create reusable, maintainable code units
Replace Implementation: Eliminate repetition and unify implementations
Verify and Test: Ensure the safety of refactoring

Remember:

Don't abstract prematurely (wait until there is clear repetition)
Don't over-abstract (keep it simple and clear)
Move forward in small steps (incremental refactoring is safer than one-time large-scale refactoring)
Tests are your safety net (write tests before refactoring)

Final Goal:

Let every piece of knowledge have a unique, authoritative representation in the system. When modifications are needed, you only change one place, and all places using this knowledge are automatically updated.

This is the power of DRY.

dry-refactoring

NPX Install

Tags

SKILL.md Content (Chinese)

DRY Standardized Process: From Identification to Refactoring

When to Use This Skill

Core Idea

4-Step Standardized Process

Step 1: Identify Repetition

1.1 Obvious Repetition

1.2 Semantic Repetition

Identification Checklist

Step 2: Abstract the Logic

2.1 Identify Variable and Invariant Parts

2.2 Choose the Right Abstraction Form

2.3 Design the Abstraction Interface

Abstraction Design Principles

Step 3: Replace the Implementation

3.1 Systematic Replacement

3.2 Handle Edge Cases

Replacement Checklist

Step 4: Verify and Test

4.1 Unit Testing

4.2 Integration Testing

4.3 Manual Verification

4.4 Performance Verification

4.5 Code Review

Complete Example: From Start to Finish

Scenario: Discount Calculation in E-Commerce System

Original Code (With Duplication)

Step 1: Identify Repetition

Step 2: Abstract the Logic

Step 3: Replace the Implementation

Step 4: Verify and Test

Common Pitfalls and Solutions

Pitfall 1: Over-Abstraction

Pitfall 2: Incomplete Replacement

Pitfall 3: Ignoring Performance Impacts

Pitfall 4: Breaking Encapsulation

Best Practices

1. Incremental Refactoring

2. Document Your Abstractions

3. Use Type Systems

4. Write Tests Before Refactoring

Checklist

Identification Phase

Abstraction Phase

Replacement Phase

Verification Phase

Overall Quality

Summary